Session Date/Time: 20 Jul 2026 07:00
[00:00:19] Reshad Rahman: Good morning, everyone. So today, the first session is nmop, and we are our co chairs. I'm Reshad. And I'm Benoit. So, note well. Everybody should be aware of this. I'm just going to let the slide sit there for a few seconds. It talks about how you're supposed to be conducting yourself in a professional manner in terms of patents and all that. I won't be reading the whole thing, but if there's any new participant who's not aware of this, as it says at the bottom, you know, you can come talk to the working group chairs or the EDs. Those are meeting tips. Just a reminder, you know, we just realized that we need a reminder. We can work out the clicker. So everybody, even if you work in the room, please join. Join the on-site tool preferably. Whatever you do, please mute yourself and turn the video off. We have remote participants. I don't think we have any remote presenter. But for, you know, if people have a headset, it goes way better. Even people in the room, please join the mic queue if you have questions. It makes managing the questions much easier. And, also, if we have a show of hands, Paul, you know, you need to be logged in. If there's any other we have note takers. Thank you, Lucia. Thank you, also, Thomas. But if anybody else wants to participate, you're welcome. The more people, the better. And here's the link for the notes. Okay. Just warm welcome to Lucia and Jefferson, our new secretaries. Lucia is at the front. Jefferson has to be elsewhere right now. And, again, a big thank you to Thomas who's been our secretary for a long time. Yes. Just a small note. If you look in the meet echo, you see Thomas as NMOP delegate too. But, you know, you just got demoted, we took that out. We forgot to take that out. Here's the agenda for session one. As most of you know, nmop usually meets for two sessions. And at the various IETFs, we've had different ways of splitting the two sessions depending on the presentations and the work which is going on. This this IETf, session one is concentrates on the working group documents. You should be familiar with those documents you see at the at the beginning, the message broker, message keys, network incident management, and all that. Then we're going to be talking about some SIMAP-, Yang-, okay, related stuff. So there's going to be there's two documents authors from each will present, then I'll be talking a bit about leading the discussions about what the next step should be. Jefferson will Jefferson, who's the new secretary, is also the cochair of NMRG. So he'll be mentioning about NMOP and NMRG. And that's pretty much it for session one. Session two will have share your incident and surprise some AI related drafts. Any questions on on the agenda? Okay. Document status. So we have our first RFC. I think that happened sometime in April. Congratulations to the authors, contributors, and the working group. That's the terminology document. And we have the SIMAP concept, which has cleared the AD review, and I believe is now waiting for directorate reviews before moving to the ISG. Okay. Let's look at our milestone. So if you start at at the top, you know, we had June 2025 to submit the SIMAP concept to the to the ISG. That's going to be happening soon soonish. That's that's the first one. Number two and number three, the message broker architecture and then the Anomaly management to the ISG. There's question marks there. We're going to talk about that in the next slides. And then network incident management, we put in November at the end of of the year. And at the bottom, you see the milestones which have been achieved.
[00:05:41] Ahmed Elhassany: Okay. I sent an email about a
[00:05:44] Reshad Rahman: month ago about the dependencies between the documents. So the documents which are in nmop and the documents which are not in nmop. As you can see on the right, there's the eight documents in yellow are normative references that nmop documents have on them, and those documents are either in NetConf, in NetMod, and ops AWG. And if you can read the fine print, it tells you at what state it is, what the action holders is, or etcetera. So now if you look at the three circled documents, which are rfc3535-20years-later, etcetera, they've got right now no normative references on any of the nmop docs or documents outside of the working group. So those we can proceed without having to worry about dependencies. So that group to the right is going at it at its own own pace. So as those I mean, assuming there's no big changes within those docs, we seem to be pretty good. But in terms of process, we cannot go full speed ahead until those documents advance too. So the message broker suite are the first ones which are going to go. I might have got something wrong about two instead of three. I think Thomas is going to be talking about a little bit later. So what Benoit and I discussed is to we'll do working group last call for either two or three of those docs. We'll want to close working group last call, but we cannot advance those documents until the documents they depend on advance too. So sometime after the IETF, we'll discuss with the authors, and the chairs will decide when to advance those. And then after that, you got the anomalies the three anomaly detect detection documents, which have a normative reference on message broker. We'll advance that after. I think this is yeah. That's the last slide. So we sent a request for feedback to the working group in June. Now the questions we asked was, does the current scope align with operational priorities? Have to remember that nmop was created for operators. Are there important topics missing? Are there any issues in the working group? One other thing which I didn't mention here was, you know, nmop is really based on experiments, whether there's experiments which, you know, people feel the working group should be working on, all those things. So we got a few responses. Some were public, some were not. So the first one was, you know, it's big kudos to the working group for focus on the running code. So we always have a hackathon portion. And I think that was Andy who mentioned that, you know, it's really interested with the Apache Kafka and TSDB. Also, more work on binary yang push. SID file management is something that he mentioned. And then we got a suggestion to update the charter to include AI for network management automation. Anyway, so this request for feedback is not closed. It's feel free to send responses either to the working group or to the chairs.
[00:09:44] Benoit Claise: There's one queue. Chong Feng.
[00:09:48] Reshad Rahman: Chong Feng. Yes?
[00:09:57] Chong Feng: Hello, everyone. My name is Chong Feng from China Telecom. Yeah. I have one question. Maybe we noticed that there were several agent related presentation in agenda now. We I I saw that there have been several AI agent related set meeting this week. So I'm concerned about the scope of mop in the future. Will mop be one of the major venues for discussing this topic, or it will be a temporary place for AI agents? I hope you can give some feedback.
[00:10:41] Ahmed Elhassany: Okay.
[00:10:45] Benoit Claise: Alright. So this seems to be a topic of the session number two, but you got a very good point. We're all wondering where we want to publish all the AI related documents. So there is something we need to do for session number two in agreement with the AD, is that we're going to contact the author and ask them how are your work going to be an experiment? Richard mentioned this. It's going to be an experiment in nmop. And what is the scope of this experiment? And are you engaging yourself? Do you have do you plan to have open source code, etcetera? And we're going to have a couple of questions to understand how we can open the charter for something which is specific and experimental focused in nmop- for AI. We don't have all the answer yet, but it's a beginning of an answer. Makes sense?
[00:11:34] Camilo Cardona: Okay. Thank you.
[00:13:21] Thomas Graf: Good morning, everybody. So we have some updates on the YANG-push to message broker integration. First, on the document updates. So we have two revisions, Revision 12 and Revision 13. And the main part on revision 12 was now we completed the security and also the operational considerations section. And here, we would like to request from the working group some review, whatever this is helpful, whatever there is something missing, that will be super helpful. Then in the Version 13, we got a couple of feedbacks from implementers of the YANG message broker consumer side. So we detailed a bit more on the deviations, how they are being implemented in the Yang schema registry from a producer and also from a consumer point of view. And also, we detailed for the message broker itself the header aspect so that, basically, there, the reference to the schema and also, basically, the content type, the application, young data JSON, or CBOR is taking place there. So these are the main changes on '12 and 13. So here, just we've seen basically in the chair slides, there are dependencies to other documents, and we just updated updated those dependencies and marked them in yellow. What has changed compared to IETF 125? And maybe also one remark on the message broker integration and telemetry message. We believe that both documents are ready for Working Group last call. And the message key document, we will see I don't even have it here, yes. So the message key document was in the last I think it was it 1.25 or 1.25, it was working group adopted. And you will see today in another presentation from Ahmed some updates on the document itself and also related to some open source proof of concept code. So we believe that, that document should come after the telemetry message and the message broker because it's like describes the aspect of indexing and how basically topic names can be created where the broker integration is the system architecture itself and the telemetry message is basically the API between the producer and consumer. We believe those documents belong together.
[00:16:15] Benoit Claise: So a quick validation question. Out of the three documents we mentioned for the first last call, message broker message key, message broker integration, and message broker term to message, you're fine to have those as a set.
[00:16:31] Thomas Graf: I suggest to do the message key afterwards. Afterwards? Yes. Okay. Because it's relatively new. We just have adopted it on the the working group. We all now, this time, we have like a first proof of concept, so we believe it's not that stable yet as compared to the other documents. Thank you. Then let's give me a brief status update on the hackathon activities we did where we validate the end to end implementations. This is our website. It's focusing on publishers, receiver, the telemetry message, schema registry, and producers and consumers. The repository is accessible here. The first part and that's the architecture we are aware of. And then, basically, the the first part of the hackathon is about we have additional, basically, yang push features which are now being implemented by the vendors, by the implementers. And also, we have additional implementations, notably in the area of TTLS and And CBOR is named identifiers. And here in green, you see the changes compared to the IETF 125. And also on the subscription side, we are now moving towards ITF and subscriptions. On the message broker side, in terms of testing, last time, we were not able to finish the Sienna Blue Planet young message broker consumer side. So this has now been concluded, the test results have been shared there. What's new also and here in the last slide, you will see also a reference to the NetMode session. So Vivek from Insa Leon started to do comparison about different open source Yang library implementations, and these are basically the key features for the message broker integration. You see pretty much we have a good coverage on the Libyang side and some action items to do on the YangKit and the ODL YankTools side. There is a link at the bottom for the complete review, and also please join the NetMod session if you want to get more details on those future comparison. Now we had actions items from the IETF 125 hackathon. So these are the things which we addressed this time. So it's quite an extensive list. As I was mentioning, we were not able to finish the Sienna Blue Planet workflow engine tests. Also, the six wind got us some more ITF and IEEE subscription. This is now also concluded. The feature comparison on the Yang library was just mentioning it. And then there were other minor things like, for instance, to ensure that the YangPush subscription state is always reserved in the YangPush receiver. And then also all the advancements we did in the Libyan completeness is now finally also merged into the data collection itself, and the message key and the topic name proof of concept. There are a couple of open items we are now looking forward in IETF 127. One is basically on we have an example, Java message broker consumer. This message consumer is currently missing, basically compiling the young library instance data, and also the young AnyData validation part is currently not supported in YangKit open source library. That is also being worked on. And last but not least, the proof of concept for the message topic naming we want to now implement into the data collection itself, moving forward from a proof of concept to an actual implementation. These are the people who contributed to the hackathon, quite an extensive list. I've been asked, like, what's the biggest challenge so far? It's really, at the moment, like, there are many implementations. There's a lot of interoperability testing, a lot of people involved, so that's quite a challenge. Questions or comments on the document updates and on the hackathon status?
[00:21:22] Reshad Rahman: Actually, I I might be getting the documents confused, but do we need a YANG doctor review on on one of those?
[00:21:29] Thomas Graf: We had YANG doc's early review on the telemetry message and an ops directed review on the message broker integration.
[00:21:38] Benoit Claise: Okay. Thank you.
[00:21:45] Thomas Graf: Thank you. Good. Okay. Thanks.
[00:21:54] Reshad Rahman: Next one, Ahmed Boltinin. Just wait. Did you give him control in the clicker? Just one second. Oh, you you can start talking. I'll just give you a clicker.
[00:22:17] Ahmed Elhassany: Alright. Good morning, everyone. Today, I'm gonna follow-up on what Thomas was mentioning. I'm gonna talk about the message key part of this whole architecture. And to start with the problem statement, I'm gonna be short because this has been presented before. Head of line blocking is bad. Having one giant pipe to put all the data in is bad. So the idea is we want to have some API that both producer and consumer can agree on to split the different subscriptions into different topics to have them keyed and indexed correctly on these topics. These topics should be easily be findable. That's the whole point we of this strictly draft. Alright. So this is in relation to all the other documents. I'm not gonna go again over it because already mentioned by the chairs, by Thomas, but it's, you know, part of
[00:23:06] Thomas Graf: the whole package that we have here.
[00:23:09] Ahmed Elhassany: So what we have changed so far? We refined the algorithm. We rewrote it, actually. And, basically, we defined the format of the message key, so it's now exact format. The topic name derivation is now there is an algorithm that defines it and also how we extract the key. Also, there is a three phase algorithm that does it. We worked a little bit on the terminology to make it a bit sharper. These are the changes we have since last ITF. So what about the algorithm here? So we adopted a three phase algorithm to basically extract the keys from the subscriptions. The first step is basically a normalization step. Subscription can be either a subtree filter or an XPath filter. We normalize them all to an XPath. We have a way to convert a subtree, basically, to a union of XPaths. Second, from that, we derive a template. Basically, this is the key template. And when subscription data comes in in in phase three, basically, you have to extract the list keys and the values that you need to fill in the templates. So it's designed phase one and two. You do it when you first receive the subscription started message. So it's a bit slower, but you do it once. Phase three, you do it on every message so you can optimize your code a little bit there, and you have a fast extraction of the keys you need to do to extract. And here is an example. It's supposed to be new lines, but, basically, we include the router, basically, the node that send it some subscription ID. And this is the last part. This is what we extract from all these three phases. You will have an exact, basically, pointer to this key.
[00:25:00] Reshad Rahman: So, sorry, I mean, I have a quick question. If you go back so when I looked at your slides yesterday, I didn't understand the part in phase one which goes multiple routes become a union of XPath.
[00:25:10] Ahmed Elhassany: So in subtree, basically, you can extract more than one subtree. And then, basically, you can have, you know, you can have you can extract, for example, BCP information and interface interface interface information at the same time, and then they become a new like, we convert them to an XPath. You have a union operator in XPath, actually. So that's that's exactly the key the point there.
[00:25:33] Reshad Rahman: Thank you.
[00:25:39] Ahmed Elhassany: So for the topic derivation algorithm. Here, how we can derive automatically a topic name. The goal here is to have a global name that's human friendly. It doesn't have to be fully exact because we have very short space. We have in Kafka about 209 characters. So we there is gonna be some information loss. But that's Okay because usually there is a metadata database. You can always look the subscription schema in the schema registry. This is just to make it easier to consume, a bit more automated to do. So we have multiple steps. We rely on the short name prefixes of the modules, basically. We allow the operators to add their own prefixes because there might be different teams, different organizations. They wanna slice the namespace in the way whatever they way the way they like. And it's designed to be deterministic and collision free. At the end, if we cannot get to that point, we use hashing to hash the last point, so we we guarantee this point.
[00:26:53] Jefferson Campos Nobre: Alright.
[00:26:56] Ahmed Elhassany: So this is the learnings we did from the BEST hackathon. So, basically, the document was initially introduced in IETF 124. At IETF 125, we did the first hackathon. We found a lot of a lot of problems, and we tried to go one by one. And I think the three phase algorithm that we have basically resolve all these issues that we have seen. And with that, I'll stop. You know? Questions to the last, or we should
[00:27:22] Benoit Claise: wait? Okay.
[00:27:29] Ahmed Elhassany: We have the first implementation running. Now it's a Rust library with a binary CLI. You can try it, give us feedback, and we designed it in a way in the CLI. You can call each phase individually or you can call them on one shot. So you can basically play with all the phases of the algorithm that we have. It's in GitHub open source. Any feedback is welcome. For the next steps so we have already revision two posted. We have the first open source implementation. And then as was Thomas mentioning, the next step is to have it integrated on the whole ecosystem. So not testing individually. Now we test it, like, for the whole ecosystem all the way from Yang Bush producer to the consumer.
[00:28:25] Rob Wilton: Rob Wilson, Cisco. Slide six, please, I think. Yeah. So I I agree with your algorithm what you're doing here. I think that makes sense, but be aware that there's no guarantee that the yang prefix is gonna be unique. So often often they will be, I think, but there's no guarantees there.
[00:28:45] Ahmed Elhassany: Yeah. So that's why we do we always have to go back to the to the actual subscription in the metadata. And if it's if there's a collision, we will have to use hashing. So the algorithm the last tip of the algorithm was just hashing and and call it a day if there is collisions. Because it's very hard to guarantee complete information unless if we have, like, the full XPath again, the full YANG schemas again, which we don't wanna do because it's you have a metadata database that you can just look it up in there and and you're done.
[00:29:16] Rob Wilton: I mean, you could if you if you knew that all the modules, like, you took all the scheme for the devices, you could do a a uniqueness check on the prefixes. And if they weren't unique, you could allocate alternatives.
[00:29:28] Ahmed Elhassany: Sorry. Can you say say that again?
[00:29:29] Rob Wilton: If you knew all of the schemas, all the YAM modules you're dealing with, you could do a uniqueness check across the prefix across all of those and potentially allocate in a few cases different prefixes, which would then get you back to it being unique.
[00:29:41] Ahmed Elhassany: Yeah. But then this is I agree with you. Could happen, but if you have a lot of vendors, a lot of different devices, it you know, I'm not sure if the goal here is to make sure the prefixes are unique or just have a sensible topic name. Right?
[00:30:01] Benoit Claise: It's a vendor issue, right? Yeah.
[00:30:10] Thomas Graf: Thomas here. Rob was raising that also in the previous sessions about that, and we were actually looking at whatever there are alternatives to the prefix, but also the module name is not unique. The only thing basically unique is the namespace. And using the namespace, basically, would mean a very long name, so that's where we came up with this option here.
[00:30:37] Rob Wilton: So the module name, I think, should be it has to be unique within the schema of a given device. That's effectively required. Ignoring imports, you might import two different versions. So that's given I think it's likely to be unique across vendors because they should be using a vendor prefix for these things.
[00:30:54] Ahmed Elhassany: That I don't think there's a language for should. I think it's just a common practice. Yes. And I have to account for that. If if it the the standards allow it to be to happen once, then I have to account for it can happen. Because I know that in, like, future versions
[00:31:12] Rob Wilton: of yang, think there's thought about trying to drop, like, the namespace altogether and and just use the module name, and I don't guarantee uniqueness on those or have an expectation of uniqueness.
[00:31:21] Ahmed Elhassany: That would be interesting to follow. I haven't followed that work yet.
[00:31:24] Mahesh Jethandani: So
[00:31:26] Thomas Graf: Just to follow-up, unique on the device, yes or not, we cannot guarantee it across the network. Here in the message for career, collecting from multiple devices across the network.
[00:31:40] Benoit Claise: Okay. Yeah. Alright. Thank you. Thanks. Next is Chen for ten minutes.
[00:32:06] Chen Li: Morning, everyone. My name is. So I will give a quick update of of this YANG data model for nano incident management. And document status, this draft, you know, get some discuss before this meeting and to see whether we advance this document for publication. And so thanks, Adrian, and then Hans, many other to support this kind of work. And, also, we have some discussion about some, you know, issue in in the draft. So thanks, Benoit and Thomas. And a lot of update we made is housekeeping, and, also, we discussed some outstanding issue and get get it resolved. So so latest version compared with previous version, we, you know, we still, you know, have second align with terminology draft, which is obviously ninety nine forty. And, also, we fixed document reference to matching model reference, and we add more collapsing text on the minimal element usage. And and also in this version, we make an incident number mandatory to, you know, make it explicit and also create incident without a known source. And and, also, we add based based on suggestion on the list that we add operation consideration section, clarify unique index in this section. So several fundamental change we add here. First is to clarify our relationship with network architecture. So this issue raised by by my, you know, in a recent review and really suggest to we need to build these ops towards Chen to navigate it back, force between anomaly incident protocols into, you know, draft related to a model. And so follow this discussion, actually, we have a discussion on the list and reach agreement on, you know, how to do this kind of navigated back and forth and to come up with this proposed text. We we we you will see, you know, how we can map or, you know, the parameter in the incident model into the model defined in a network anomaly architecture. So also, we agree to follow its approach and use, obviously, 89, 69 layer architecture as a base. That means we have a service layer, network layer, and device layer. So we can, you know, better align, you know, how how we can map it to each other. So this text we proposed. And anybody you have, you know, comments, please feel free to add here. And second is that we add operation consideration section as for this, you know, YANG data model worker is mandatory. So we come up with some text and also based on suggestion from to move the retention with full draft in other section to the second nine section nine for this operation consideration. In addition, we clarify the unique index in the operation section. I think this is read to the comments. You know, we support both, you know, the incident number and the incident ID. And you can see for current incident data model, actually, we have a compound key, actually, name and type or an incident ID to identify each unique, you know, incident instance. Alternatively, we, you know, use, you know, incident number to identify each, you know, incident in the instance. The reason we do this because in IPC and in the notification and we, you know, we could add this component key, you know, to identify each incident. But it seems a little bit, you know, complicated, you know, maybe make a performance downgrade. So we, you know, use incident ID. You know, this can increase the performance. And so
[00:36:36] Reshad Rahman: So sorry, Chen. If you go back to to that slide, it's I mean, I sent you review comments yesterday. You replied to me. I didn't look at your response in detail. So the first thing I did not understand was you have a incident number Yeah. Which is unique per the yang.
[00:36:51] Chen Li: Yes.
[00:36:51] Reshad Rahman: But it's not the key. So that's the first part I did not is it because there's cases where you don't have the incident number, but you have those that three tuple?
[00:37:00] Chen Li: Yeah. Right. These coexist, but we want to make sure for IPC and notification, we can use one single parameter to identify incidents. So we introduce this incident number. So we make a allergy to, like, SRv six that you has a pass segment to identify the whole SRv six end to end pass. And also, you can use, like, a segment segment list. So it's, you know, equivalent, by the way. You know? Okay.
[00:37:32] Reshad Rahman: I understand that, but why isn't the incident number the key? You've got the 64 bit number, which is unique. Yeah. Why is that not the key? If it's unique, it can be the key, or is it because you don't have it all the time? That's number one. Yeah. And number two, there's I mean, this is a bit of a net. You've got a string which is incident ID, which according to description can be empty as part of the key. And then you've got an incident number, which is a unit 64. So at the minimum, I think you have to clarify the difference between incident ID, incident number. I'll read your response in more detail this afternoon because I still don't understand why you need the three tuple as opposed to just using that 64 bit number, ASCII.
[00:38:18] Chen Li: Yeah. As I clarify, you know, for YANG data model, we have this kind of compound key, you know, name, type, and incident ID. But for IPC, you know, notification won't want to have a, you know, single attribute or parameter to, you know, to identify the incident number. So that's our motivation to make it, you know, more easy you know, this really help to increase the performance, you know, process performance efficiency. Yeah.
[00:38:45] Reshad Rahman: I'll read your response. Okay.
[00:38:46] Chen Li: Thank you. You do. Yeah. Another one is about we need to allow incident without knowing the source. So these are, you know, risk by the MI actually, we do think for some cases before the incident diagnosis, you don't know the source. So how do we put the parameter over there? So the solution we propose is we remove the minimal elements set to the one. And also we allow, after incident diagnose, we can populate these sorts if we already know these kind of sorts. So there's a change we made. Yeah. And I think that's all. And we I think happy to receive a review from both here. And and also we think maybe we can request some YANG doctor review. I know that, Reshad, you are a YANG doctor, but you are in the video to make comments. So I hope, you know, get more people keep our eyes on this chapter so we can, you know, make make this work, you know, advanced. Yeah.
[00:39:51] Benoit Claise: Any question or feedback on this presentation slash draft? So I'm the document shepherd for this. That's why I spent quite some time reviewing the documentation. You improved. Thank you very much. What I've not done yet, this is a final check on the interaction with the network anomaly. I know that you two have been speaking and you added the text in one slide six, but I need to review this from this draft, but also from the point of view of the series of network anomaly draft. That's what I have to do as well. And next to the feedback that Richard mentioned so I think that we were close, but we need to do a couple of checks.
[00:40:29] Chen Li: Sure. Yeah. I think we need to better collaborate and better align with Thomas drop, and we, yeah, happy to take any, you know, suggestion if you have.
[00:40:39] Benoit Claise: Yeah. So the point is that you two agree on the minimum interaction, and we want to see how far we want to go. This is what I have to think about because we could go as far as telling, oh, I want a mapping of all the the young leaves, but maybe it's not required. So that's why I need to spend a little time there. Okay.
[00:40:57] Chen Li: Thank you. Thank you.
[00:40:58] Reshad Rahman: Yeah. And the other thing I would say to that is even if that's good, I think there's some small changes you agreed to make hook in the dock.
[00:41:05] Chen Li: Sure. I add a firewall issue ticket, so I will close this.
[00:41:09] Reshad Rahman: Yeah. So once that's done, then we can go ahead with YANG doctors with you once Yeah. Benoit says it's fine.
[00:41:15] Chen Li: Appreciate it. Thank you.
[00:41:17] Reshad Rahman: Thank you, Richard. Next is Olga, I think. Nope. Next is Thomas.
[00:41:52] Thomas Graf: So we have a couple of updates on the network anomaly detection related documents. Just a brief recap. We have the architecture document, we have the semantics describing symptoms, and we have the lifecycle, the workflow on basically optimizing the results of the anomaly detection system. On the architecture, that's the overall architecture. And basically, we have changes, some minor changes in the references towards the SIMAP related documents. We changed them from normative to informative. And also related to the knowledge graph, we also changed from normative to informative. And then, all the way around, as just previously mentioned, in the network incident contribution, there is a section on basically how the mapping between the network incident and also the anomaly detection, the ITF relevant state notification, which are the key fields which needs to be mapped so that an incident can be mapped to an anomaly detection event. So we described it there and we would look forward for a review in there. I see Benoit.
[00:43:11] Benoit Claise: Yes. One quick one because actually, this is exactly what I mentioned was the incident from Chin. I reviewed this from Chin's point of view. So which of your documents have you been updating to do the mapping? Is this just the architecture or also the other ones?
[00:43:26] Thomas Graf: So we believe that, basically, with the update now on the network incident, which is explaining how it maps to the relevant state notification on the anomaly detection system, I think we are good enough there.
[00:43:40] Benoit Claise: So the question is you have not been updating your draft to point to
[00:43:44] Thomas Graf: the incidents? That's correct. Yes.
[00:43:46] Benoit Claise: Okay. Thank you for that clarification.
[00:43:54] Thomas Graf: Going forward to the semantic side. So here again, just to reiterate, it's about action, reason, trigger. And, basically, the main changes to IETF 125 is that we got some feedback to simplify the abstract, which we did. And, also, there was some references in the schema name from, I would say, in the past of to the term CBL, which is the implementation, the Cosmos Bright Light implementation, which we removed now to make it generic. And there were also some simplifications on the prefix names. And since RFC 60 nine-ninety one, this is now RFC 90 nine-eleven, we updated those references as well. And for completeness, we have also now a relevant state not only the relevant state schema in schema itself, we have also some instance data examples. So hopefully, that will make for an implementer more clear basically what needs to be implemented. Then we also put some text in the ITF Network Anomalies Service Topology- young model, why that young model is needed. And I need to highlight again, this is an experiment here. So we are looking forward on the outcome of the onsen discussions, at the end that we can actually reuse the Layer two and the Layer three service models. And until then, basically, we have that as a temporary workaround, that ITF Network Anomaly Service Topology Yang module. On the right here, the updated Yang schema tree. Then on the life cycle, here it's about the refinement process to keep basically the AI assisted human in the loop. The main update since IETF 125 is mainly on the abstract in introduction, so there is some refactoring to keep the abstract as short as possible. Then we moved some things from abstract to the introduction and also refined a bit the introduction section. And on the life cycle process, we received some review, many thanks, Richard, to detail a bit when basically in the life cycle process it changes from validation to refinement. Hopefully, that makes it a bit more clearer. And then there were some references towards the message broker, basically topic name and subject name. And here, we introduced some dedicated type diffs to make sure that the topic name and the subject name are within the constraints of the message broker naming. And that was based also some outcome basically on the message key from the message key document. Next steps. We believe the documents are in good shape, and probably it would be now a good time to go move forward with an early YANG doctor's review to get some feedback, whatever they are from a young perspective, some some issues which needs to be addressed. And in parallel, we are currently working with Vivek from INSA Leon on a so called post mortem system POC. And from that POC, we want to bring in also some post mortem system requirements and also some feedback on those implementation and detailing a bit what the post mortem system should do. That mainly will result probably in updates in the life cycle document. And I would say that's it from the anomaly detection side. Any comments or feedback from the working group?
[00:48:10] Benoit Claise: While people are rushing to the mic, So those are part of the Recaplast score two, I would say, of documents. So I think that going asking the YANG doctor review is about the the right time. Would you agree?
[00:48:23] Thomas Graf: Exactly. You you also mentioned in the beginning, since there is a message broker dependency from the anomaly, probably first go forward with the message broker documents.
[00:48:34] Benoit Claise: Maybe Oh, even sequence the YANG doctor review.
[00:48:36] Thomas Graf: Okay. Yes. Good point. Yes. But but but maybe now doing the YANG doctor's early review would be, like, a good moment in time just to to make sure. But after that, basically, we believe also with by the time we also have the from the postmortem a bit more more feedback, we could include that and then do it do a wrap up.
[00:48:57] Benoit Claise: So it would make sense to have the same YANG doctor for this set of documents. Is this something that we want to mention?
[00:49:04] Thomas Graf: I don't think so because there is only a minor, like, dependency, like, on the type dev stores, the message broker. It's not necessary. Here with this. Okay.
[00:49:13] Benoit Claise: Yeah. Thank you. Sure. And we're all proud of you because the timing is perfect. And the button exit chair.
[00:49:52] Reshad Rahman: Six.
[00:49:58] Olga Havel: So now hello, everybody. So now when the SIMAP concept document have been submitted to ISG, we are proceeding with the modeling exercise.
[00:50:10] Reshad Rahman: So sorry, Olga. Bruno just reminded me to give an intro. So we have as I was mentioning at the beginning of the when I was presenting the chair slides, this is a suite of three presentations from SIMAP-yang. So Olga is going to be presenting the approach she's been leading regarding SIMAP-yang based on eighty three forty five. Italo afterwards is going to be presenting the SIMAP-nmop-nm based on eighty seven ninety five, which is the TEAS one. And then after that, I'll be leading discussions, hopefully, with the help of the working group as to what direction we should be taking. So this is number one of three. Thank you.
[00:50:53] Olga Havel: Thank you. So this is the agenda. I'll skip over it. I have more text here, so I'll try to be to summarize some of the things. So as Reshad said, we are looking at which based topology model should SIMAP adapt. And requirements and use cases are defined in the draft- ITF-nmop-, SIMAP concept. We have two candidate based models. I'm is no consensus currently. I'm presenting RFCA-three 45 approach. This approach is fully aligned with RFCA-three 45 original goal that network node TPN link plus supporting for underlay are used for multi layer, multi domain, multi technology model, and full graph navigation. I have a quote from RFCA three forty five that mentions, VPNs, tunnels, and parts. So please, look at it at the slide. We had met multiple hackathons, and showed demos to many of you here from layer two, layer three, ISIS, OSPF, BGP, MPLST, MPLS, LDP, SRV six, layer three VPN, in different labs different operator labs, with the operators. So here are some of my personal opinions about the other option, but I won't present it here. So what we agreed is that we would select a subset of requirements from the draft and compare the models for two solutions based on the subset of requirements. So these five requirements, requirements basic model support, layered model, navigates, semantic, and supporting are the ones that we picked. We didn't pick others. So we are comparing based on these five requirements. Here is the link for the overall analysis. Myself and Italo, we did kind of based on these requirements Excel spreadsheets our proposal, with some analysis, and the proposed full model for each one of those requirements. So there were four modeling options. I'm aware that there is a fifth one on the proposal, but it's not on the so I'm leaving Grecia to kind of go through it. I will just go quickly through the four proposals and focus on the one that I favor. So the first one is joint common proposal. My comment about that we already disagreed on the base itself, so I'm worried that co authoring one base would require solving the problems before starting, and maybe it will not be the fastest option. Second option was a draft based and team mapping out of the scope. So, like, although my preference is option four that I will describe at the end, this option may be a pragmatic fallback as opt if option two four is not adapted. My concern about this option is how to kind of formalize reuse as much as possible structures to these mapping with the t topologies. So we may end up in the situation which is similar as option one to kind of as much as possible align. Third option is TE as a base for multilayer topology. I have different concerns in terms of profiling that the current proposal for model that doesn't show tunnels and tunnel interfaces and applicability across all layers technologies that I maybe I'm aware, but I didn't see pox and hackathons that prove outside of the optical domain. And the option that I'm favor would be to use both, but depending on the use cases. So, this is the preferred direction for me. It's clean split. A draft based proposed generic top down navigation across and into any domain layer technology using just network node TP Link and supporting very simple navigation. Draft can provide declarative what if an intent readwrite for topologies. And existing young modules remain for exactly whatever purpose was to be continued in the exactly same way for technology specific in domain depth and control and for imperative realization of intents. New modules, for example, SPF and ISS topologies may use SIMAP for both read and write, but we can be very specific that for optical control, the existing same as for layer three VPN provisioning and configuration, the existing young modules would continue to be used. So we can be more specific in terms of this option and agree exactly the scope of one versus other, but this leaves RFCA-three 45 option to go ahead independently. And it doesn't affect. I believe it's very it's complementary option. It's not competing option with the TE.
[00:56:10] Reshad Rahman: So so, Olga, I've got clarify, if you go back to slide six, I just want to make sure that we're talking everybody's talking the same language. So when you say two ways, and the first way is generic c map draft, what c map draft are you referring to? Yours?
[00:56:24] Olga Havel: RFCA three four five extensions.
[00:56:26] Mahesh Jethandani: It's an
[00:56:27] Olga Havel: initial proposal, but we would work on it and then
[00:56:29] Reshad Rahman: Okay. So the first SIMAP draft you're referring to, so the generic way would be draft- Havel SIMAP- yang or I forget what exactly it's called?
[00:56:36] Olga Havel: But that one is just initial draft. So any proposal is for the reviews, and
[00:56:40] Italo Busi: Yeah.
[00:56:41] Olga Havel: There is nothing there. There are some extensions that that we are proposing, but those extensions are based on the existing RFCA three four five terminology. And and
[00:56:51] Reshad Rahman: And when you say detailed as the second one, existing yang, are you referring to TE?
[00:56:57] Olga Havel: Yes. Yes. Sorry. Sorry for that. Like, I would say TE is used to con to control to do traffic engineering because it has all the attributes that are needed for traffic engineering. But when the tunnels are created, when the parts are created, then sees them in different obstruction as a view. They become links, layered links with supporting. So would not have any impact on write in the optical world except maybe for declarative intents and motifs.
[00:57:27] Benoit Claise: K. So
[00:57:32] Olga Havel: the next few slides, I'll try to be very Sorry.
[00:57:35] Reshad Rahman: Dan Dan has a question.
[00:57:37] Dan Voyer: No. Not a question. I want to also amendments.
[00:57:40] Benoit Claise: It's okay.
[00:57:41] Dan Voyer: Thanks. To also support your option number four with Yeah. A d t 45. I think it makes sense from an operator perspective that we use this one as a cofoundation Thanks. Of the
[00:57:55] Olga Havel: We did we did hackathons with this one. Thank you so much. And we tried to kind of so I'll go into the this is the option for them. Again, a lot of text and clarifications, but the goal here is alignment with fully RFC eight three four five way of doing things and augmentations are done in the spirit of eight three dot four five in a very simple way. So for each of the requirements here, we have for the basic model support, we only have the basic basic network node TP link for every layer, every topology. It's quite simple. There is no need to have some deep understanding, and it can wire all the different young modules around
[00:58:43] Reshad Rahman: it. Nigel, can go ahead.
[00:58:47] Nigel Davis: Just came in a bit late. Sorry. I just wanted to support your option four also. Think it's very pragmatic and it gives us the the right shape to build, you know, quite different topologies to optical and so on. So I think it's really important. It's okay. Thanks, Nigel.
[00:59:02] Benoit Claise: Thank you very much, Dan and Nigel. So in terms of supporting which option, Olga is going to present, Dan Italo and Rachel is going to lead this discussion for exactly this type of feedback. Thank you.
[00:59:18] Olga Havel: So the requirement basic model support is done through the basic basic entities. We, as I mentioned already, we did model all the layers from layer two, layer three, IGP, ISIS, OSPF, BGP, MPLSTE, SRV six, MPLS, LDP, layer three VPN, layer two VPN. So we did all of this only using these four concepts. For layering, we used supporting for everything, and then we identified some gaps, which I will address for the next requirement. But supporting could be used again for any underlay between these layers. And you can model the the modeling is done in the way that it includes both management control and and data plane concerns. Navigation. You can see on the top layer here how navigation is done. Navigation change all via supporting link. You know? You can go top down, very basic relationship, simple queries that would allow both young and another kind of natural language on top of young, for example. Yeah. So this is the one where we have example of how few attributes could be added in the supporting, which we then identify as a gaps, very simple extension. And this is some extensions to the supporting how to support TP to node or nodes to network. I think this is the most important slide. I hope I can maybe just finish it. Advise it the right approach for SIMAP. I believe it's the right model for the job. Navigation is a topology walk network node link termination point supporting. That's really what RFCA three four five purpose was. And we talked with Alex yesterday about it, and that's what it is, Validated across all of these technologies, hackathons, pox, the simple toolbox is proven sufficient with some augmentations that we identified as gaps and based on requirements. Augment don't deflate. So the important thing here is when gap appears, just add leaves on existing entities and relations. Don't create new entities. Don't create new relations. Four leaves on supporting link, you know, resolve primary backup path ordering bundle overlay instead of having all of these things modeled as separate entities. Tea keeps its rightful role, realization, not multi technology, multi layer. So it's really I believe strongly it's complementary, not competing. We have one model, many use cases, so it can be used at navigation, intent, what, if, etcetera, and all four entities could be used in the same way. And discipline in choosing not to over engineer. So every layer navigable with one primitive, every topology navigation with one primitive independent of service type domain or technology. Every gap closable with simple augmentation. Every use case can find the context and then use the existing GEL modules. The proposal doesn't add power SIMAP plex. It refuses to add complexity SIMAP really doesn't need.
[01:02:51] Reshad Rahman: Thank you, Olga. Thank
[01:03:08] Nigel Davis: you.
[01:03:16] Italo Busi: So I have more time. There's slides. I have more slides than time, so I will skip on some of them. I'm focusing on the most important one. So so this draft is described the applicability of eighty seven ninety five for addressing the SIMAP applications. So it's mainly an applicability statements, and it and it's applying it's using also the t topology profile, which is a work in progress in TEAS on how to use a subset of it. Just a clarification which I got I thought people were confused after last meeting. If you look at the SIMAP requirements, I think we can divide into three groups. Some requirements are already met by t three forty five. Some are not met neither by t three forty five nor by t seven ninety five, and there is no discussion on the fact that eighty three forty five should be used. And the second the second case in the red one, we need to new model. The big issue is about the requirements, which may be supported by eighty seven ninety five. We don't have an agreement on how to address them, and we don't have an agreement about what is this list yet. And the content of the draft is analyzing is an initial gap analysis for some, but not all of the requirements that can be addressed by t seven ninety five and also provides an appendix with some consideration about programmatic profiling to deviation statements. What why? Why why would we have this debate? Okay. My concern by having application specific data models is that if we we can have a situation which where everything works well, I have a controller a, which supports an application specific data model for application one. Everything works perfectly. I have a controller b, which which runs over which provides an application specific data model for application two, and everything works perfectly. As soon as I want to move application one over controller b, then I'm having a problem. I have exactly the same set of information, just different data models, and the controller b vendor will say, oh, I'm standard compliant. I gave you I have all the information that you need. I'm not going to change. Application one vendor will say, I'm standard compliant. I have all the all the information that you need. I'm not going to change. And you, mister operator, will have to fail to fit into this fight and try to manage this mess. That's why I think it's not a good idea to go and with multiple application specific data models. But say, as an example here, we can see for this will be a nice animated slides. So I'm starting with application number one. I created an application specific data model one with two attributes, one and two. Then I have an application two that needs attribute two and three. Oh, I cannot use the model number one because application attribute number one is not needed to my application. So I need to create another model with two and three. Then I have another application three, which needs attribute one and three, then I create another model with attribute one and three. And then what happens? So I have three models which reports three attributes under three different models just because they have they they have different combinations I need or different syntax or different formatting. Then what happens? Application one evolves and say, well, actually, I need also attribute number three. What I'm going to do, I'm going to add attribute three to my model. And application three will say, I also need attribute two, and I go to add attribute two to my model. And then I have two data models which have exactly the same content, just different format. That's the way. How my question is how many data model do we need to report the link, the the bandwidth or the latency of the link just because somebody uses that for part computation and somebody use for something else like motif analysis? It's the same information. Why do we need different in data model? Because the application are going to do different use of that. I don't understand. The idea of the profile is I create a single data model with all the four three attributes that I need, and application number one will only use two. Application number two will only use two. Application number three will use different queues. And then when you migrate, you will just use more attributes that are already there in the in the in the in the main model, and the controller just need to implement only one data model with all the attributes reported once. The controller may also meet some of the attributes because maybe it's not needed, that's okay. The issue we have here is people is complaining about how we how we can do that programmatically. I know how many POC and some deployments will are implementing profiles, de facto, by mutual mutual agreement between the client and the server, but only here I'm I'm having problems, and I I will see what whether it is interesting or whether people has has an idea how to solve it. It's really good to understand what is the problem. And what we learned
[01:08:04] Reshad Rahman: from other Sorry, Tala. Have a question. Can you go back to the previous slide, please?
[01:08:07] Benoit Claise: This one?
[01:08:08] Reshad Rahman: Yep. So just to because there's been you know, we've been talking about profiles for a couple of I t ETFs now. I think some people on the t side, they're very familiar with profiles are. I was not. So I just want to confirm and also not just for me, but for everybody else. So the example you're giving here is they're all using the same module Yes. Even though they don't support Everything. Full Yes. Schema. Yes. Okay. So and the way this is conveyed is via, I don't know, customer documentation.
[01:08:42] Italo Busi: Yes. Usually, what we did was we defined in the POC I'm working on. We I took the Yantry from its 75. I just manually remove the leaves with which are not needed. And sometimes the the tree becomes very short. What I did in this draft is to I used the deviation statement to manually generate the the pruning of tree. But, basically, it was to say, we need this attribute, we need this attribute, we need this attribute. And, yeah, all the other attributes are not needed.
[01:09:08] Reshad Rahman: So I'm a bit confused now. If you're if you're pruning it, whether by doing copy paste or whether you're doing deviation, you have a different module.
[01:09:18] Italo Busi: It's the same model. It's the same net namespace. It's just telling you what attributes are needed. Like here. I'm saying, you see that the tree of example of for used by application one is the same module, same set of attributes, the tree is is is much is much smaller than the tree that the network controller is implementing. So it's it's just providing a subset of the attributes. I'm implementing attribute to one, attribute implementing attribute two. I don't need three and four.
[01:09:51] Thomas Graf: Okay. K. Just to add that, I think it's the same module, but the a different schema tree. Would you agree, Talo?
[01:10:01] Italo Busi: That's that's the first thing, man.
[01:10:03] Thomas Graf: Okay. Good. Thanks.
[01:10:09] Benoit Claise: And one more question, if I may. So you use profile because you don't want to implement everything. So app one doesn't need a full set. App two doesn't need a full set. They just need different parts. Yes. So that's why you're pruning this instead of Correct. Loading everything. Correct. Yes.
[01:10:28] Italo Busi: Okay. What we learn we noticed in the other working groups that even if we have a a YANG data model, it's a condition necessary but not sufficient for multivalent interop. It's what we find useful and needed sometimes is to have some guidance. If you have this application, this the way you need to use this not only which attributes or how do you use those attributes to represent specific conditions or specific solutions? Otherwise, people will come up with the same model in different instances for the same to represent the same entities because they have a different interpretation of of the syntax or of the semantic beyond that attribute or a structure. And we think applications applicability statements are a good way to guide people to try to implement the YAM model in the same way. But what we noticed and we have two example. One is a transport and BI in C. It can be the other one is a packet optical integration in TIS. What I noticed that people tend to lose enthusiasm on this type of work and because it's a lot of work, because you have to describe very well the the the application environment and and go into the details. And sometimes it's easy to write just write it beyond this model that address my my use case. So I understand the personal attitude toward I have this problem. I have this data model. It's fixing my use case. I don't care about anything else. But this is going to be an issue for those who have to put everything together. So, okay, this I I already presented the work that we've done. Okay. I don't know exactly what is the issue. The issue it looks like the issue is okay. We are creating new entities to address missing gaps, like the path. The path is an older set of links. There is a primary path, the backup path. They have a lot of rules. We needed that. So all these connectivity matrix was added because nodes may have connectivity constraints and so on. And at this moment in time, my conclusion is is, okay. People claim they want something simple, and this I will go quicker. I presented last time. Simple is very subjective. And
[01:12:34] Nigel Davis: okay. Nigel? I just wanted to support your point on the Yang model. It's not sufficient. I know I know you know that I do support it very strongly on that. It's not sufficient. You can have a mass of different ways of interpreting it, which is exactly why we had to put together TR five forty seven in TAPI, which is an immense amount of work, as you also pointed out, but it's fundamentally necessary. So I'm I'm not sure how we resolve that challenge, but it's true. The Yang model is not sufficient to
[01:12:59] Italo Busi: My suggestion is to spend more time on those
[01:13:02] Chen Li: more Yeah.
[01:13:02] Nigel Davis: I know. Know.
[01:13:03] Italo Busi: Than in creating a model that that do solve problems which have been already solved. Knowing how long it takes to do that work, it's it's a big challenge. Yes. Yeah. Okay. Another issue, when I talk with SIMAP people, sometimes I'm confused about whether we really need a profile or a subset or we need a superset. Because if you look at the concept, you when we talk about t for capacity planning, you need all the information about t. For what if analysis, I hardly believe you can do what if analysis without implementing eighty seven ninety five completely. Because if you don't know how your t algorithms are going to react to a specific condition, your what if analysis will be completely broken. So, again, so depends on maybe looks like that depending on the type of SIMAP application, we need different profiles. So sometime, even a superset of the profile. So it's so I'm still not sure whether we need one profile, multiple profiles, or sometimes everything about it is m 95 for SIMAP applications. And, okay, this personal considerations, which we had some discussion during the work with Olga about whether we can simplify the way to model make eighty seven ninety five more modular. One idea was to split. Splitting eighty seven ninety five, in my opinion, is will address some of them, let me call it, marketing issues because I'm hearing from previous meetings that the term is sometimes creating a false friends like, oh, it's only 14 networks, so it's not for me. It's something else. It's from other people. It's not I don't care. Doesn't matter. Or people say it's too complex because it's a big monolith monolithic model. Unfortunately, it will becomes an MVC change because if I split if I move attributes from one module to another module, the namespace changes. So there there is a non an is an MVC change. But it's not a big issue because it's the same name it's the same attributes syntax and and semantics, so you just need to fix some some adaptation. It's looks to me quite simple from an implementation point of view. Maybe it's a big problem from an operational perspective. So I'm asking whether the marketing issue is worth the effort, the technical effort. Another option would be to work with the network types to do some one statement to say, okay. This portion of the model may is when if the topology is t or when the topology is, for example, multilayer, no matter whether it is t or not t. So there are possibility. We need to get consensus from this. So this is just my thinking. No no idea whether this will accept or not, but it's something food for thought.
[01:15:37] Rob Wilton: Robert, I just wanna ask a clarifying question, not a discussion question. So here, you're saying you'll have to create a new version of module. Is that because you need the existing one to coexist for other use cases and it's a separate thing, or is it your concern is you don't want to break it in terms of changing it? Because, obviously, with what's going through NetMod, we're now breaking changes to occur, and we can create a new if we say, actually, we just think we haven't got the base model quite right. We need to evolve it. We could you could keep the same namespace and create a version two dot zero zero of of watch effectively.
[01:16:07] Italo Busi: Oh, yeah. Is that we have one model with come coming to this. We have one model with four attributes, so we want to create, for example, four model with one attribute. I no. It's more
[01:16:20] Rob Wilton: in your topology question, the topology module.
[01:16:22] Italo Busi: Yes. Yes. To split it into multiple modules. But this means that the attribute which already exist, they will become duplicated because they are in a different namespace. Fine. Okay.
[01:16:34] Thomas Graf: Thank you.
[01:16:34] Italo Busi: That's all on my side.
[01:16:36] Reshad Rahman: Thank you.
[01:16:40] Ahmed Elhassany: Okay.
[01:16:42] Olga Havel: In regards, what we agreed to do is look at those five requirements and show the model as we propose it. So, you know, I don't think attribute one and two is kind of representative of what our exercise was. So do you have the model that you are proposing, the profile, how it
[01:17:01] Italo Busi: looks like? There is something in the draft- board
[01:17:05] Olga Havel: services, tunnels, parts
[01:17:08] Italo Busi: Okay.
[01:17:08] Olga Havel: In IP and other domains.
[01:17:11] Italo Busi: Okay. Yeah.
[01:17:11] Olga Havel: Like, similar to our hackathon.
[01:17:14] Italo Busi: Can you go back, Margaret?
[01:17:15] Olga Havel: I
[01:17:15] Italo Busi: don't oh. You can't control it. It's okay. Okay. The the the okay. As I said, the draft is not analyzing all the use cases, and it's not analyzing all the requirements. It started with some use cases and requirement like bidirectional link, a multipoint link. Yes. That was done before that this was done before that one. So the the draft is analyzing some use cases. We can add more. And this is and there is an appendix which, through the variation statements is creating a pruned version of the YAML tree that can be used to address those specific use cases. We if there is an interest because I don't it's a huge amount of work. So if there is an interest to reuse eighty seven ninety five, it makes sense to continue. If the intention is to is to go to to another direction, then there is no need to continue in this detailed analysis, in my opinion. So but I I definitely we need to complete the analysis because, as I said, we also don't have a a clear answer about what are the requirements which are not met on 8795. We need to continue the analysis to to go to understand which one is red and which one is yellow. But if there is an interest, that makes sense. Otherwise, I don't think it makes sense to keep doing analysis of if if you have four five requirements and the it's a no go for five requirements, it will be a no go with 20 requirements. It doesn't change.
[01:18:41] Benoit Claise: Dieter Beller. Have a to join the queue. Right? Sorry? Don't forget to join the queue next time.
[01:18:48] Dieter Beller: Oh, sorry. My my mistake. Sorry. Is my understanding correct, Italo, that you you're you're in favor of following an approach where we leverage existing yang modules as much as we can instead of creating new yang modules? We may actually extend the existing yang modules where needed. And of course, profiling means probably deviating things out that are not needed for a specific application. Is is my understanding correct?
[01:19:14] Benoit Claise: Correct.
[01:19:15] Ahmed Elhassany: Thank you.
[01:19:19] Reshad Rahman: Okay. So we've had a few discussions in private. And so what I'm trying to do here is I've looked at the various points from Olga and Italo in their documents, and there's going to be some repetition of points mentioned by either of them. So the goal at the end of this is to for the working group to come with come up with a decision as to what's the best way forward. So some history, and this is the reason why, you know, we we we spoke about this IETF 124 when there was less clarity about what profiles are. So that's eight months ago. Eight months after, we still haven't closed. We need to close on this now. Okay. That's the summary. We have two different approaches which are on the table right now. There's all draft based on 8345, and there's draft, which is eighty seven ninety five t t based. And I believe at IETF 125, Med suggested that the two groups, you know, meet and try to arrive at an agreement. So there were three options on the table which were presented. The first one was agree on a common approach. There's been many discussions, and the author groups could not agree on a common approach, as you guys might have guessed. Option two is you using Olga's draft as as for SIMAP-yang, and it was out of scope how to do the how the t model can be used. And option three, on Italo's draft. During recent discussion, there's a fourth option. Now my fourth option, I think, is what Olga's fourth option is. There might be some differences, okay, in details. And so, again, Olga and Italo, if I'm misrepresenting anything about your respective drafts, I'm sure you'll speak up, but this is based on the understanding that I have up to now. So this is based on eighty three forty five, and draft- havel is technology agnostic. That is it can be used to navigate between multiple layers. All got demonstrated that at multiple hackathons. Now when we discussed that in meetings before the IETf, this can be viewed as both a benefit or a drawback. You know, for some people, hey. If there's a new new layer, new technology somewhere, I don't need to change anything. I can use that way. The disadvantage can be viewed is that now you got two ways of representing things. There's that generic way, and there's the service specific way. And then as been discussed before, there's some concepts which are in 8795, which have been re in in invented in that draft, like supporting node and maybe supporting link. Option three, based on 8795, which actually, I say which it augments. It's there's a bunch of deviations. Right? Or am I? Anyway. So this one requires service models at each layer. Again, it's the opposite of the previous one. It can be viewed as both in a benefit or a drawback. Now this makes use of profiles, which until recently, again, wasn't very clear to me. The drawback of profiles to me is that there's no machine readable way. You know? Italo has explained that it works. It's not like, you know, when you somebody is saying I support module x, there's no equivalent of line Yang library to say those on the nodes support. Is it an issue? For some, it might be. For some, it might not be.
[01:23:47] Thomas Graf: Yeah, Thomas here. So I presented before the network anomaly detection documents and I even shared in slide eight the young schema tree and one grouping was basically referring to the network topology. So what I understood is if you are choosing option three, that means, basically, I can no longer rely, basically, that those items I have in the normal detection system that I can actually refer them to the topology because basically we are as an implementer, we will choose then certain options and then I might not be able to refer to a stable Yang schema tree anymore. So here, my concern is basically the interoperability when I'm implementing such systems. I don't have a well defined Yang schema tree anymore. Is my understanding correct?
[01:24:42] Reshad Rahman: I think it is, but Italo might have a different view.
[01:24:52] Italo Busi: Well, I didn't see that draft. Sorry about that. But if you reference to know the links NTP, they are also in eighty seven ninety five because eighty seven ninety five is augmenting eighty three forty five. But if you have an anomaly on a path or if you have an anomaly on the TTP, then I don't know how you can manage it with how to use in TTP and path, but maybe that's why I I don't know exactly whether it's it's an issue or not. But if it is an anomaly on the node, anomaly on the link, it can be done with G795 because it's an augmentation of eighty three forty five. An normally on the link depends because if we have if we create a new augmentation twenty three forty five to mimic the concept of the link by putting the order, the the the op ID on the supporting link, then okay. Then that changes the semantic of the entities. So
[01:25:46] Thomas Graf: It's an anomaly on a VPN service because usually at network operators, when we are providing connectivity service, it's on a VPN level, so either layer two VPN or layer three VPN service.
[01:26:00] Reshad Rahman: Yeah. So I think we might need to dig a little bit deeper in the concern you have. It my first impression is that it is potentially an issue, but I might be wrong. Yep.
[01:26:15] Olga Havel: It was going forward RFC three four five approach, you know, then you could align both service anomalies, but any other problems in the network with those four entities without having to understand specific implementation, like, you know, whether it's a tunnel issue or whether it's a link issue or whether it's a, you know, VPN link, not not VPN service, but VPN link issue between two SAPs at the end of the multipoint link, you would be able via the same reference point to to connect any kind of incidents, any problem problems in the network in a very generic way. Same as, for example, how we connected how we're connected to inventory from RFC 8,054 physical to the inventory. So so that's one of the things. Otherwise, you would have to understand underlay TTPs, tunnels for this, and and then for data center, maybe some completely different entities so you wouldn't have a generic solution. But that's my opinion.
[01:27:24] Benoit Claise: And the queue is now locked because no. You can go. Right? Because there are questions.
[01:27:29] Rob Wilton: Okay. Robert and Cisco, quick one. So I think you mentioned deviations, and it's really probably a question for, Italo. So I don't know if deviations are used here. We need to be really careful about how they use they are because deviation is meant to be a debate about implementations not conforming with specification rather than being used to define new specifications. So that's one thing I think we should be careful. And you may argue this is an implementation. I don't know where that falls, but I would just be really careful at that line. Or we need to go back to NetModel or some of your the yang next and say, look. We need a different mechanism for this.
[01:28:08] Reshad Rahman: And option four. Maybe it's option four prime. Maybe it's not exactly the the same as what Olga presented as option four in her slides. So here is you know, we go with both. We use option two, which is eighty three forty five base, all gas draft to cover the base, you know, l two VPN, l three VPN, any non TE stuff. The use cases which require traffic and engineering, whether it's MPLST, optical, and all that would use option three. Now we will or may end up with some overlap. I think, Olga, you mentioned we would end up with overlap for navigation.
[01:28:53] Olga Havel: Traffic engineering generates the tunnels or parts. You know, they will appear in the SIMAP as links in order to simplify navigation. But the full management and control could be done for the optical through TE.
[01:29:08] Reshad Rahman: Through option three. Okay. So we might need some further discussions between the other group to close down on the specific details, but at a high level, this is what my understanding of option four is. So the conclusion, each option, in my opinion, option two and three have perceived downsides. But depending on the operator, they might care or they might not care. As an example, option two might be suitable for an operator which are who has no traffic engineering. Likewise, some users may not want to use profiles, but some users might love profiles. I don't I can't speak for everybody. Now option four has a drawback that you have some overlap as we just discussed for navigation. Italo mentioned it. We discussed the possibility of refactoring eighty seven ninety five. That could be a fair amount of work and would have impact on any users over eighty seven ninety five. So it's, you know, it's a fairly it's it's basically doing a breaking change just for refactoring, not to fix something where you have a bug in the yang. So right now, we don't think I mean, actually, I don't think we should be going down that road unless there's people on the t side who have a use case for this. Okay. So unless I think we're going to be close out of time. So next thing I'm going to ask Benoit to ask poll poll question. Go to next slide.
[01:30:37] Nigel Davis: I'm good. Okay.
[01:30:40] Reshad Rahman: So the first question and maybe we'll have only one maybe we'll have two is whether the working group agrees to go with option four where we'd be going with both approaches and having them use case specific but maybe have some overlap.
[01:31:56] Benoit Claise: Okay. So
[01:32:01] Reshad Rahman: so there's about 75% of people who've had an opinion said yes approximately. I'd like to know so the drawback of the option four I mentioned was the one I know of is there's overlap. Is there any argument against option four that we haven't heard yet? Or, you know, so the people who voted against option four is for the reasons that we already discussed. Okay. Thank you.
[01:32:43] Mahesh Jethandani: Yep.
[01:32:49] Nigel Davis: I carefully put my hand down so you didn't think I had an objection to the thing I just voted for. So but the, the one thing I wanted to say is we're get overlap regularly. Overlap is a very common thing that happens as you develop models, and we need to get better at dealing with that. We see two things in common. We identify a proper place for it. We identify a migration path, a method to move stuff, and then to recognize that the industry is going to have to move on to use a new structure and so on. That's going to be repeated forever, I think. So we need get better at doing that rather than shying away and going, oh, no, we can't have overlaps. I think we finally need find so that's that's more the point I'm gonna make. We need to find a way of doing that migration from one place to another.
[01:33:33] Italo Busi: Yep. Okay.
[01:33:34] Thomas Graf: Thank you. Thank you.
[01:33:42] Benoit Claise: Okay.
[01:33:50] Reshad Rahman: Yes. Thank you, everybody. That was a good discussion.
[01:34:26] Jefferson Campos Nobre: Showing the the polls here.
[01:34:29] Reshad Rahman: No. It's you need to Maybe stop stop and start again, maybe. Alright. Okay.
[01:35:03] Benoit Claise: So you've got one of the two screens. I'll check with if they can remove the poll.
[01:35:08] Reshad Rahman: Think you need to stop the poll. Okay. Stop it.
[01:35:11] Benoit Claise: Let me try. You can you got your slide.
[01:35:14] Jefferson Campos Nobre: I'm going to the other side. Okay. So good morning. I I think Richard and Benoit are trying to, you know, to get me on that. Okay. So good morning. My name is Jefferson Capsnobri, and I'm going to talk about the, collaboration opportunities between the network management research group, the NMRG, and the network management operation, NOP. So as a little introduction, there are some discussions on how to transfer information and some have collaborative work between the RTF and the IETF. And something which is which is very clear, I think, right now is that the gap between research and operation, considerably narrowed in these times. So we have opportunity, you to explore between collaboration, the collaboration between our communities. So there are, of course, several working group, research group in pairs that can be explored for that. And, I'm going to talk about the obvious one, which is the NMRG and Mop, but there are other ones. So I I got this, this information from, from Thomas' presentation. So I have this advertisement for, the presentation. It will be on Thursday in the session four. And it says that the average directors from ops and management are members of the NMRG mailing list and are invited to NMRG meetings in order to ensure free flow of information in both directions and to avoid duplication of work with the various IATF working groups. So it's very clear that the the concept, the idea to have this kind of collaboration is in the charter of the the research group. And, of course, I think that, it's the best for everyone, you know, to try to, you know, to reduce the work which is duplicated and and the overlaps of the work of between the groups. So regarding the the NMRG, I'm going, quick on on that slide. We are encouraged to have one more than one alternative approach to problem areas. And there's no expectation that RGB will come to consensus on an approach. So it's kind of a difference from the working group in that perspective. And it's something that can hinder, you know, the collaborations because you don't have this kind of, you know, like the the more direct action of a working group. And I'm going to talk more about that, but the NMRG can can work as a landing zone for some kind of, you know, of, works that can, you know, start or initiate in the in MRG and can develop for our working groups, such as ANIMA. And I'm going to talk about this as an example in the next slides. And one thing that is different also in a research group, and in this case, speaking of an MRG, is that the outcomes can, of course, be the IETf documents. But, also, we have some, outcomes that are more, you know, like a scientific and position papers and also have a good integration with the research community, for example, hosting some of the research group meetings in network management conference. So it's kind of different. So right now, in the NMRG agenda, we have three main points, which are intent based networking, artificial intelligence in network management, and the self driven and managing networks. So this is three, you know, three main points. And for each of these points, we have adopted drafts for that. But I'm showing this to say to to to, you know, to try to make the point that for some of these of these points, we have opportunities to collaborate with nmop and have, for example, some kind of way of doing, you know, an integrated work. Okay. Also, I got the the Thomas reached out for the NMRG and mop and ops area communities, and they have this an AI, synthesis of the conversation. So there is you know, some part of the conversation, it's focused on a way we're expecting that network management will be in the next times. For example, considering data driven, cognitive network management, and the need for a whole boost AI agenda stack and something that we we can see, for example, considering the meetings and the presentations in this week. There are some some points in order to operational safety, for example, considering digital twins. And in the in the, have some work on network digital twins. And, finally, it's the conversation and the, you know, the messages that are exchanged show that's to be nice, you know, to have some joint initiatives and hackathons or some kind of, you know, of of, integrated work between our communities. And we have an example of that in the past. So for the, working group, ANIMA, it started as, you know, like some meetings for autonomics in the NMRG. You have three of these meetings, and there are some works that from from these meetings, from Internet drafts from these meetings. And then after that, we have, two main points that we think that will be a good way to to push forward this, initiative. And, they lead to two RFCs, the seven five seven five and the seven five seven six. And, in this context, we have the UCAM BOF, which lay which led to the animal working group. So we think that is an important outcome of the NMRG work, and we have a good popularity on the beginning of that considering the UCAM BOF. After that, the animal working group, focused on the, autonomic network infrastructure, so they provided some some, drafts and RFCs on that. But the the the the the work, which is known, alternative network infrastructure, is not quite, known in the the same speed and same with the same energy. So at some point, there is some kind of a lack of interaction with the NMRG, which is something that I'm I'm going to I'm saying this in order to, you know, to avoid to this kind of mistake, considering the NMRG. So to just to finish, there are some some ways to move forward with that. So, I think the easiest one is just to increase the MRG and MRG discussions and mutual attendance. We can have aligned documents, for example, documents exchanged between the groups, something that we can do. Also, it's possible to have, as we did in the past, some specific attend meetings or joint sessions, as an example of the IBPM and BMDWA. And, also, something that, appears in the conversations to have, for example, hackathon efforts. So my last my last slide is just some questions and maybe historical ones. But is it worth is there interest in both working groups and in both groups? Is there energy in order to do that, consider the groups, and how to provide a continuous collaboration? And saying that because it takes some time, you know, to community adapt it for this kind of integrated work. That's it.
[01:43:10] Reshad Rahman: So just Rob and Thomas, before you start, we're starting to run out of time, so be as brief as possible, please.
[01:43:15] Rob Wilton: Okay. Rob Rob Rob from Cisco. So, I think collaboration is always good between working groups and different working groups and research groups. That's fine. I think when I set up nmop a few years ago and things, this whole discussion came up between my research and what's done. And and where it landed then was anything that the operators need in roughly a one to two year time frame, so the near term stuff, then doing that in m m p makes sense because it's the it's the problems they're trying to deal with now and solve here. Whereas what I saw the NMRG was more longer term, like the five years out and things. So the one concern I have between, like, sharing documents and things is, certainly, when it comes to AI, it feels to me that that's moving so fast, you don't have time to do that. So I would like to see experiments of how operators using AI, that might be something that comes into into nmop or somewhere within the iATF rather than iRTF. But there's more discussion to be had.
[01:44:10] Thomas Graf: Thanks. And I just wanna follow-up on what Rob said, and thanks, Jefferson. I think nmop is doing experiments, and I think we should share that with nmop-. And as you said in the slides before, like, nmop- is doing exploration, and I think nmop- also start doing a bit of explanation and share it with nmop and vice versa. I think that probably, if we are working on that level together, might prevent what happened in the past with ANIMA and NMRG that you're somehow losing contact to each other.
[01:44:46] Reshad Rahman: Thank you.
[01:44:53] Diego Lopez: On my way, Diego Lopez. Normally working for Telefonica, but today, proud supporter of the of the World Cup champions. Does that does that comment I was sharing an RG some time ago, one of the things that people, I mean, some people are aware, wiser than me there, insisted very much. It was about the fact that the role of the RGs providing sort of a research agendas and identifying hot topics. And it would be ideal if we since we are a group that is trying to experiment to collect, these ideas from from MRG and identify which are the experiments that could be more interesting to continue the work of the group. That's something something practical is about saying, hey. Look. We want you to do this on this particular act.
[01:45:48] Benoit Claise: That's that's Thank you. Alright. You have less time. You have? Sure.
[01:45:55] Reshad Rahman: Sure. Sorry.
[01:45:57] Camilo Cardona: Morning from my side as well. Here are some updates on the BMP telemetry message draft. So here an overview slide to illustrate where we stand in the whole YANG push to message broker integration. And basically we are modeling BMP messages and the idea from the data BMP data collection perspective is then we are going to populate any data payload of the main telemetry message with our schema. Another overview slide on the data processing pipeline, I'm not going to go into detail here. So what we actually did compared to the last version is we are now directly importing the ITF BGP model from IDR instead of redefining some modules and reworking them. This is to avoid duplicating semantics already standardized at IDR. There is an ongoing requestdiscussion with IDR, with the authors of ITF- BGP so that they move to standalone reusable models instead of this sub model architecture so that we can actually import only the the models we we really need and and not have to import the whole ITF BGP, which comes also with configuration and policy related schema content which we are not interested on for telemetry use cases. Then we also added a new ITF BMP TLV module, where we model the values of the BMP TLVs consolidating from multiple drafts where TLVs are being defined: main BMP draft, lock main BMP RFC, lock rib RFC, and the BMP before draft. And we have groupings to define which TLVs are applicable to which BMP message type and also a common grouping to define what TLVs can be used for whole the message types. Still in the context of TLVs, we also modeled the past marking TLV information. We have a container with Boolean leaves for the path status and also a reason code there. We got some feedback on the mailing list regarding some duplicated information now because when we're using models from the main ITF BGP, we also got in the best path information also from the Adj-RIB-In-Post perspective. Perspective. We need to understand how to address this application now. We also added a BGP Open module. This is to enable a reusability of BGP open information types defined in the IETF BGP model, and now this we use inside our BMP model model the sent and received open message we get in BMP Peer Up messages. Last thing we added is a session metadata container. This is basically when we receive a BMP init message, we get some router identity information that does then is not sent in the subsequent messages. So we are suggesting an approach where we where our data collection could cache this information and then add it in all the subsequent messages in this session metadata container. Now coming to the message broker topic naming to connect with what Ahmed and Thomas were mentioning before. For BMP, we are suggesting two topics. One topic where state changes and statistics are sent and this is meant for real time use cases in time series databases, for instance. And here we send all the BMP message types. And then we are proposing a second topic for the current state of the rib where it will be topic compacted, so we ensure we only retain the current state of each router rib. How do we do it? We do it with a by specifying a message key concept, and this message key we are suggesting is built with a two line byte string with the host name in the first line and the second line basically a young identifier path into the actual instance data where we go from the root of the telemetry message. And on the right, you see an example for a route monitoring message. We go from the root down to prefix and path ID. And this way, we know we uniquely identify an entry in the rib. And when compaction is being done, we only maintain one entry per prefix in each rib. Doing this, we kind of break the the, like, message broker producer approach where message key is also used for for partitioning. I mean, we don't break, but we would kind of then not maintain the concept wherein in a partition, we send all the the information from a from a network node. And to recover that, we we are defining a new concept of a separate partition key, and then we need a a custom partition implementation that will use this partition key instead of the message key to determine in which partition to produce the messages. And this way, by using the host name in the in as a partition key, we would determine we'll make sure that from the same network node, it's always gonna be ending up in the same partition. This is important for consumers that need to maintain state information. Right? Then some questions to the working group. If you still think that this split between message and partition key makes sense, if you agree on how we model the data, the BMP metadata in Yang, And if you still resonate with the idea of modeling BMP and IPFIX data in Yang to integrate in this whole Yang message broker architecture. Next steps, we need to extend the document to cover additional BGP address families. This is going to be an extension of the ITF BGP model because they are only at the moment supporting Unicast address families. Then we need to improve BMP statistics modeling and we need to clarify authoritative timestamp and also authoritative flex when TLB come into the discussion with BMPv4 especially. Then we got some feedback on the mailing list. We need to address it, and we would like also to request working group adoption. And also the fun stuff, we need to implement it in the BMP data collection.
[01:53:09] Benoit Claise: That's and two person in queue.
[01:53:12] Reshad Rahman: Yeah. So maybe something can follow-up. I think I'll ask that question in private via email. Like, the Yang models you defined, could I mean, it's for the data you get on the wire from the, I mean, from the device to the BMP collector. Right?
[01:53:30] Camilo Cardona: It's more meant for after the collector being produced to the message broker.
[01:53:35] Reshad Rahman: Okay. So was there any discussion about adding defining those yang in grow or whatever, or really it it's it's it's specific to acute telemetry? Yeah.
[01:53:44] Camilo Cardona: We we saw some some points on the mailing list regarding this, but this is more meant for for telemetry use cases, at least in my opinion.
[01:53:53] Benoit Claise: So Thomas, the queue is closed.
[01:53:59] Thomas Graf: Just one second to remind, last, ITF-one hundred twenty four made us the 80 for the Grow working group, suggested that basically this work should not be in Grow. Should be in Nmop-, but maybe in March.
[01:54:15] Mahesh Jethandani: Okay. You just preempted my question. So question more for the chair since the adoption question came up is if we have resolved the long term maintenance of BMP, whether it should continue in nmop or whether it should go to ideas slash grow. So all I'm suggesting is before we adopt the document, we just make sure that we let the other working groups know.
[01:54:50] Camilo Cardona: And also for the future additions of the
[01:54:53] Benoit Claise: yeah. I think we're good. Thank you.
[01:54:58] Reshad Rahman: Sorry. I'm the
[01:55:02] Lucia Cabanillas: only thing between you and the break. Okay. Lucia Cabanillas. I'm gonna present our work on a model for distributed authorization policy sharing. This slide is is just to recap a bit. Basically, the goal of this framework is to define a canonical way to manage and share authorization policies. We use YAN to define and distribute these policies in a matching readable way. However, the policy logic itself is written using policy as code languages, while DAN carries this logic together with this it it it is metadata enabling it to be validated, versioned, and distributed. And this approach is designed to support interoperability across systems and domains, while different kind of policy engines. Typically, PDPs can consume and enforce the policies. We made some updates to the draft. For instance, we included a JSON example to complement the JAM module. This is important. We changed the type of the policy language from enumeration to identity ref, which will allow us to include new policy languages as they appear without changing the base model. We also updated the the diagram to show the full cycle between the policy enforcement point and the policy decision point. We also removed the leaf version since we assume or we have left it as an external concern because this can be handled in many ways. For instance, what we are using is the repositories to track all the versions. We introduced a new leaf, the aria, as the main grouping mechanism. This leaf it's important because will help us to distribute the policy to the corresponding, let's say, domain, discipline, or or lift. We also included the leaf author. This will be the entity that created the policy. We also included the owner, which may differ in case of outsourced authorship. The origin, which identify the upstream object the policy derives from. And we also change the type of the of the leaf area from ST and Turing. But let me assist on that because this leaf is so important because the PDP will use it to scope its authorization decisions, and the policy enforcement point will use it to bound its enforcement breach. During the hack athon, we demonstrated the policy creation, distribution, and verification across domains using this JAS JAM based model. In our scenario, we have two domains, the red dm set layer one, map it to op-one number one, layer two, map it to op-one number two, each one acting as an independent PDP and as a separate domain. What we use is Rego, which is the policy language used by OPA. And in the demo, basically, we submit a model in YAN to the policy administration point, which commits the policy and routes it to the corresponding PDP instance matching each area. And to verify it, we basically execute some queries to check which policies are currently stored in each PDP, and then we play with it. We update the policy. We delete them. We restore previous versions, and that's all. We next steps. We would like to keep refining the Jam models based on the feedback received. Thank you. We would like to explore the integration with existing program mechanisms. What we have used until now is OPA as the PDP, which is fine to demonstrate the distribution of the policy across domains, but we would like to demonstrate at the next hackathon heterogeneous multi domain scenarios. For instance for instance, domain one using OPA with Rego and another domain using or even another domain with some nodes expecting the policies through risk conf. We're trying to define we're already trying to define a good scenario to demonstrate this at the next hackathon. We will see. Something that we are considering considering or we're already working on based on some feedback that we have received is to explore new or other policy languages to support other systems. Seems there we may have some system that don't speak Rego or only use x ACML. In that sense, the model should be agnostic neutral. So we shall we shall not only be considering policy as code languages. We are already working on it. You will see it in future versions. And, of course, we are looking forward for getting feedback.
[02:00:28] Reshad Rahman: So there's a question from Mahesh on the chat. He's saying on the policy sharing draft, the only question he has is if there is an overlap with other authorization, can policy work? Or even for me, is there any working group which deals with that kind of stuff?
[02:00:45] Lucia Cabanillas: I do believe that no.
[02:00:47] Nigel Davis: Okay.
[02:00:48] Lucia Cabanillas: Because we are trying or the idea will be that our framework should be general because we're trying to define a model to distribute authorization policies. This can be enforced in in different kind of domains, in an old, in a router, in a PDP, in any policy engine. So I do believe that no.
[02:01:13] Benoit Claise: Okay. Thank you. Thank you.
[02:01:15] Lucia Cabanillas: That's it.
[02:01:17] Chen Li: Yep. Thank you. Yep.
[02:01:21] Benoit Claise: Done. Thank you very much for the session. This was the first mMop session. There is one later in the week. I have to check one.
[02:01:29] Reshad Rahman: Thursday.
[02:01:30] Benoit Claise: Thursday. Yes. And we're going to focus on sharing your incident and AI related presentation. What else?
[02:01:40] Thomas Graf: Thank you. Thank you.
Session Date/Time: 23 Jul 2026 09:30
[00:00:22] Benoit Claise: Good morning and welcome to the nmop session, the second session. I'm Benoit Claise, and we have And I'm Rashad. So welcome again. This is the one hour session this time. The note well, you've seen this slide multiple times. And by the way, you agree to this whenever you registered. So note well. The tips for the meeting. So make sure you sign into the data tracker to be able to to go in the queue and and ask your question. If you are here in this room, use ideally the Meetecho Lite client. If you take the full client, make sure that there is no the microphone and the speakers are are off. And I don't believe that we've got any, remote participants sorry, remote presenters this time. So we have we would need volunteers for the meeting minutes. We've got Lucia and, Jeferson and also Thomas. Very good. The main point for everybody is that if you go to the microphone, the link is there and make sure your comment is correctly captured in the meeting minutes. That would be a great help. The agenda is packed, and somehow this is good. We'll start with sharing your incidents from Swisscom. Then we will have five minutes by Mahesh who's going to discuss about the site meeting on AI on AIOps tomorrow, followed by a series of AIOps presentation of all of them five minutes. So we'll put a clear timer and please respect this. And in the end, there is again Mahesh for applying the wiki guidance on AI draft to see if you could draw some conclusions. Now we've been thinking with Richard and also with Mahesh because we have a lot of AI related presentation in nmop in the past with always call for adoptions, which is a natural thing. And if you look at AI this week, there were a lot of side meetings, obviously. There is the the side meeting tomorrow morning organized, I mean, organized by I don't recall the province. I think this is China Telecom. And now if you look at the NMOP charter, because we're reaching the end for some of the experiments, it says this n mop is scoped to do operational issues faced by deployment of existing network management technologies. And something which is in the DNA of this working group, why it was created, it's because it's based on experiments, and that's something that we want to keep as a DNA of this working group. So whenever you present today, think about why nmop is the right place. Think about the experiment. Think about the experiment boundaries. We're not going to do NMRG and do the research for five years. Think about, are you committing to, you know, code and hackathon? If I take the the best experiment we've got in nmop, which is network anomaly, it started small with an architecture, and we've been adding things sometime in different working groups because it was already started in in NETCONF and all of these. But here's the point that's been increasing all the time. And we are there for one or two years, and I believe this is a good experiment. We believe it's a good experiment. So, actually, do you commit to kind of follow the same path? And do you realize it's not like I'm going to present something, get my document done, and that's it. It's not the way it works in this working group. Now after that, we're going to send an email to mailing list because it's not only the six presentation that you've got here. Maybe there are other experiments that could be fitting for nmop, and we're going to discuss with the AD, and we'll see what we could be doing. We cannot accept everything. It's not the point. It has to be limited experiments. And, also, we're a little bit worried, the two of us, about, you know, working group shopping, and we've seen that up to the point where sometimes there is one document in one working group, and suddenly there is no feedback, it comes back and it's
[00:05:14] Thomas Graf: a zero zero in nmop.
[00:05:20] Benoit Claise: Be aware that we know. And, that's it, for me. There is just one agenda bash. We're going to have, like, Zhao, Ms. Zhao, who's going to present the two, transition together. Alright. Any other, Ashina Bashing?
[00:05:42] Rachid Medbouhi: So just one thing I'd like to add. I know for people who have only five minutes, it's really hard. But if you could keep a few seconds, maybe there will will be questions, maybe not. I know this is hard, but the good thing about this here today is is is the back and forth, not just a presentation.
[00:06:00] Ying Zhen: Hi. This is Ying. And, actually, for and then obviously, if my understanding is correct, they're most focused on the observability. I think whether this can be further expanded to cover, like, agent observability. And we in this week, actually, on Wednesday morning, we have a site meeting to discuss this agent observability and intervention control. And although we have hackathon project to, you know, to demonstrate, you know, how it works. And we got a lot of people interested. And we were wondering whether these agent observability can fit into the, you know, nmop charter. Actually, we and also, I think, yeah, for agent intervention control, this maybe also relate to the intent interface. We can get add more capability. So I'm wondering, you know, what chair think about this kind of worker.
[00:06:50] Benoit Claise: I propose that we don't do discussion now because actually, would like that we have the two sessions from Mahesh. And in the very last part, maybe he's going to come back. My main point as a Chair, and I believe that you're in sync, is that we want to see how it fits into the criteria we've been showing in the slides. Thomas,
[00:07:12] Thomas Graf: yes, just a quick comment on the chartering and AI. Please don't forget, for AI, you need really good data. So the transformation work, which you started from BMP to Yang and then also IP fixed to Yang, I believe, is kind of related. Thanks.
[00:07:31] Benoit Claise: Thomas, don't go too far.
[00:07:46] Thomas Graf: Good. So now we are not talking about experiments, talk about incidents. So usually, when I'm presenting incidents, my format is start in the beginning what really happened in the network so that we get a picture, what are the operational metrics we are collecting from the network, the analytical insights derived, and then go in there how we, as an industry, can do better, where can we actually improve. So this one is about the network incident at Swisscom very recently on July 2, so just two or three weeks ago. It's about the BGP routing loop causing high CPU on the routing processors. And what have happened is on an early morning, additional VRFs peerings on an Inter AS Option A peering has been introduced. And there, basically, everything aligned was there were 42 Layer three VPNs attached and a routing loop was occurring. And that routing loop was then eventually being observed in real time from an anomaly detection system based on those drafts we are discussing here at nmop. The main concern object which was triggering the anomaly detection was the excessive BGP route withdrawals. Later that day, then basically, analytics team picked up on that and noticed that they were all originating from a set of route distinguishes on those inter AS Option A peerings. And then at that day, it was decided because there was a so called frozen zone because we were, in the last few weeks, only focused about soccer. We decided basically to leave it that way until the very next day where then basically those peerings were being taken down. Look a little bit more detailed in the operational metrics. On the left hand side, you can see basically two side of origins on a particular route distinguisher and route target on a VPN. And usually, you should not have two site of origins within one VPN because on the right, on the top, you see from the RFC what's the meaning of a site of origin. So if you're learning a route from a CE on a PE, basically the private AS number and and AS numbers are basically there to prevent routing loops in BGP are being stripped and replaced by site of origin. On the right hand side at the bottom, you see a graph. So basically the same thing, but now over a period of time. And how you see basically how the two site of origins are fluctuating across the time line. These are basically the key metrics in operational metrics. So basically, they show traffic volume on a specific VPN over a period of time, forwarded traffic but also dropped traffic and the amount of flows those VPNs are carrying. And on the bottom left, the main focus here now basically is the updates and withdrawals on those VPNs. So the main conclusion, basically a network engineer would take from those graphs is basically the routing table is very instable. However, we do not have much drops here. Now from an anomaly detection system perspective, this is also exactly what we are observing there. So there are excessive changes in updates and withdrawals. There were also some peeling state changes happening at the beginning and at the end. And then also basically some minor drops on
[00:11:47] Mahesh Jethanandani: that
[00:11:47] Thomas Graf: VPN. So that's what we know here, and now we are venturing towards a new area. So maybe the final last one is that so we are measuring also the process usage on the RAP processor. And what you see here is basically not the overall process consumption. This is the process consumption only from the BGP process. And what you see basically, most of the available CPU time is now being allocated to BGP itself. The big graph shows basically all the network platforms in Swisscom Network, how this is impacting. And on the bottom right, you see basically the four main network platforms involved in those 42 VPNs. These are the prefixes which were basically causing the loop. So from BNP, we have also so called peering statistics. And one is the so called stat type one, which according to RFC 7,854 says number of known duplicated graphics advertisements. Do we have anybody from Grow and IDR here in the working group room? And what does it that actually means? How does a BGP process knows that there are duplicated graphics advertisement? That's a question we like to clarify. So if you have more details, please comment on the mailing list. Now from there, we go towards generative AI. So about a little bit more than a month ago, we plugged in our time series database, which has the operational and analytical metrics from the anomaly detection system. We blocked it into an agent. And now we are using prompts to interact with that data. And I have three slides on how generative AI can be applied to this. And on this first slide, basically, it's about querying the operational metric. And here, we start with the prompt where basically the one who is prompting knows exactly what's going on. It knows very much about the available operational metrics. And in this prompt, we are saying basically, look at the BGP process usage, make a correlation towards the BMP collected metrics on specific VPNs, which are fluctuating and let me know on which platforms or network platforms, that's a group of routers, are being affected here. And already the first outpost would give us a very good list, and I had to anonymize that. And it shows us basically what would be the normal average CPU consumption and that we have now a very abnormal high. The next prompt is about what are the looped prefixes. We get the list. And then we get also some more details on that the AS passes are relatively long. We have a massive update and pass instability in the network and exact time stamp when the problem started and when the problem end. Notice here, I have not prompted for that information. I get that as a free gift. Now, let's say I don't have much knowledge. I just heard from a colleague, there is a routing loop and I want to know more. So that's the prompt. And immediately, I get back basically what are the prefixes which are currently looping, what are the shared AS_PATH attributes. I get some additional details. Then I give a hint and say, okay, in our, let's say, VPNs, they have a common AS number, which identifying those VPNs, focusing focus on that and let us know which site of origin attributes are being fluctuating. And we get the list. And from there, we can actually further drill down. Then we ask a question and say, Okay, we know that there are specific VPNs. I want to just double check whether those VPNs are really affected and get a confirmation in here. So previous one was specific question. We know exactly what's going on. Here, we start with almost no knowledge and go deeper down. Now this is the fun one. So here, it's about creating anomaly detection metrics. So basically, we already have some AI in it. And now we throw more AI on top. So we ask specifically basically, we know that there is a routing loop happening. And in the anomaly detection system, in the ITF relevant state notifications, we have so called concern objects, basically describing the causality of the anomalies. And here we are saying, look at the BNP withdrawals, when there are high concerns, and let me know which VPNs are actually affected. And on those VPNs, what are the common BGP dimension, the common denominator in there. And we get the list of the affected VPNs immediately. And we get the information that there are eight route distinguishers. So that's basically the Inter AS Option A Peerings, which are actually triggering the loop. And from there, we go further down and basically we got the information. There were other activities on those VPNs as well. And then we are asking in the prompt, can you give us additional information on those activities? And even the LLM basically prompting us back on the timeline that those events on those 42 VPNs appear to be completely unrelated to the routing loop. So this is the IETF relevant state notification, which we are defining in this working group. We are currently working on a post mortem system. Just to give a little bit outlook where this is heading to, on the left hand side, I mark basically what are the keys. And on the right hand side, in the life cycle, so in the validation refinement state, we want to add additional informations, labels on whatever the operational analytical data was correct or not, adding additional tags, so basic commonalities between the different alerts and also give additional annotations like incident or maintenance window tickets. Now key discoveries on large language model here is they do understand operational network telemetry data. The symptom semantics are helping basically the RAGs to understand what those network metrics mean. We are looking forward to bring also the young semantics from the young schema registry and scheming catalog into the RAGs. So basically, those metrics also the operational metrics can be better understood. And what's really surprising or not much of a surprise, depending who you're asking, is large language model have network knowledge. They know what a BGP routing loop is. They can subnet. They understand relationship between BGP process, CPU consumption and BGP loops. So it proves that basically with the right operational and analytical data, you can have you can gather the right knowledge. So on the right hand side, you see the documents we are having here at nmop-, so the message broker integration, is about making the young metrics available, where the message key is about minimizing the data consumption that's relevant for your agent AI because the context window is very small. And basically, with the BMP to telemetry message, make the conversion from BMP to Yang. The semantics, we're defining the symptoms ontology. And with the lifecycle, the refinement of the anomaly detection process. Now, questions or comments? I think we
[00:21:06] Benoit Claise: are probably already So one of
[00:21:08] Rachid Medbouhi: problems we have is we don't have much time. Do you mind sending it on the chat or on the mailing list, Joe? I'm sorry. Yep.
[00:21:16] Thomas Graf: Okay. Sorry, Joe.
[00:21:20] Xing Zhao: Thank
[00:21:25] Benoit Claise: you, Thomas. Mahesh.
[00:21:44] Mahesh Jethanandani: Alright. We have the side meeting tomorrow. So as I there were some questions whether there was gonna be enough leaders to lead the meeting. And happy to report that quite a few people have stepped up. I just need to make sure I get all of them identified in the meeting tomorrow. We'll do that. Well, the reason why the meeting and the reason why I have tried to capture this in the wiki so far. So we have had, as Benoit mentioned, lot of presentations in, as he called it, work group shopping. We have had presentations. The result of it is that even though there is a lot of interest, there is no one particular work group that has been identified. And that's a problem. I will admit it. So and the AI ML work itself, whether we call anomaly detection, closed loop remediation that nmop, for example, is working on, that works separate from the AI ML work, sorry, needs to be clearly defined. So what the Wiki has tried to set out is in my in just my opinion, and it's only a guideline at this point, is really to define the categories of work. So I'm happy to take input on whether this category works or does not work. But the idea is that when, as Benoit said, when you are trying to present a draft, not only in addition to what the nmop guidelines are, just think of how does your draft fit in to any of these categories. And if it doesn't, it's okay propose why it should and we'll I'm happy to listen to it. What I still believe though, in spite of all those, is that there are certain items that are certainly out of scope. The whole AI ML algorithm specifications, standalone gap analysis, as I have noted in some of the drafts, or external framework alignments. I think those sort of final item is better suited for a liaison rather than as an RFC. I would also encourage all the presenters to look at the related buffs that were presented or are going to be presented in the BOF sessions in this meeting and see what are they doing in this respect to make sure that your work doesn't overlap with it. Alright. So tomorrow's meeting is a community organized meeting. I just set it up so that all the interested parties could come together to discuss how they want to progress this work. I'm there to listen and to answer any process level questions And merely just to say that if there is no existing working group that can cover this work and that is entirely a room's call, then we have two options that we have in front of us, which is we propose a new working group and I with the charter and with the problem statement that I take directly to ISG. Or we say, we haven't quite gauged the level of interest and call for above. Either one of those options are very viable options. So how to engage? Come tomorrow for the meeting. Raise your hands to review, author, or implement any of the drafts that are being proposed. I have identified a couple of candidates to lead the discussion tomorrow. They're not chairs technically. They're just discussion leaders. And ideally, it would be great if people own up to defining the problem statement and the charted text. That would be excellent. So the site meeting, again, it's available through remote Webex also. It's a small room. Unfortunately, it was the only room that was available. So if the room is packed, don't just go log on to Webex. I'm I'm gonna try to monitor Webex also. The other logistical part of it is that it was supposed to be a two hour meeting and and a lot of people have indicated a conflict. So I would even if the meeting runs for two hours, I would say the bulk of the work should happen. The at least the most important part should happen in the first one hour itself. At least that's a suggestion from me to the community. And I will just say, if you have any process level questions, they're welcome now or in the side meeting. I don't know if I have the time.
[00:27:02] Benoit Claise: So Mahesh, is it the first statement that you want to have discussion at the end of this session with the five minutes? Or you want to have questions now because you're going to exhaust your time?
[00:27:12] Rachid Medbouhi: What do you prefer?
[00:27:15] Mahesh Jethanandani: I will I thought the last five minutes were more disposition of the AI drafts. But this is if people have any questions about tomorrow's meeting.
[00:27:24] Benoit Claise: All right. So AD takes precedence. Any questions?
[00:27:29] Mahesh Jethanandani: All right. I'm going to skip the last slide, I think, because, Benoit, you have covered it as for what is NMOP.
[00:27:39] Benoit Claise: Thank you, Mahesh. AI based network management agent, which is a document which has been presented multiple times in nmop already.
[00:27:57] Xing Zhao: Thank you. Okay.
[00:28:06] Rachid Medbouhi: So I'm sorry. You're down to nine minutes for both. K?
[00:28:10] Xing Zhao: Nine minutes. Okay. Okay. So this is Xing from CAICT. I'm here to present the AI based network management agent. And I may we've presented it many times before. And since the last I've ITF meeting, we did a lot of updates. And first day is about the NMA terminology. We did a minor a rewisement to the concept. Now an NMA is a network management entity that translates user intense or preset goals into closed loop management tasks. So the key point is NMA is defined by the semi autonomous or autonomous closed loop processing capabilities, and it can be implemented by different technologies. So the second key part that we updated is about the interface part. And this is quite important, we think. In this, Warren, we reorganized the interface and make them into four kinds. The first day is the a two u interface, means the NMA to when we're talking about the user, the user can be a agent or can be a non agent user or system. So that's why we split the agent to user interface into two kinds. The first kind is the a two u interface, means an enemy to a non agent system or user. And second is the h two a means an enemy to another enemy. So second the third is the a two c means an enemy to controller or controller functions. And the last one is the a two n interface means an enemy to network devices. So I think the first interface, two u, maybe can work in a mop, and we can discuss in in our last last slot. And in this wherein in section section 5.1. We also ended an dynamic closed loop task workflow. In we we want to show how an NMA collaborates with controller functions to complete the closed loop. So I will not describe too detail. And since last meeting, we did several work around this draft, including we we wrote a new problem statement draft, and we propose a new young model for the a two u interface. And we also built a hacksong demo in this ITF meeting. So I believe this draft day is quite stable. So I will leave this discussion for for for for in the end. So I'll continue to present the the next draft.
[00:31:14] Rachid Medbouhi: So while I'm getting the next draft slides, if there's any questions, now is the time.
[00:31:31] Xing Zhao: Okay. Thanks, Richard. And this is our second draft. It's about the framework or and mostly the young data model for the NMA two interface. It's a new draft and it does not work.
[00:31:48] Mahesh Jethanandani: Oops. Sorry. Okay.
[00:31:52] Xing Zhao: Thank you. And in the beginning, we want to say describe more about the problem, why we would propose this draft. Because we know NMAs poses new capability like intent planning or or such things. But the existing systems like OSS or or maybe they are not agents. So they need a very simple interface to use the capability of an MA. So that's what we do in this draft. We want to define a two u interface and the information model to solve this problem. And in the framework, we can see that the nonagents upper layer system or user can be the a two u client, and the NNMA is the a two u server. And the a two u client can use the a two u interface to do the capability discovery, intent submission, or task status check, or some notification subscriptions. So that's the function. And the interface model includes several core components. The first is the agent capabilities. This is for describe describing what an enemy can do, and the intent object is to describe the user's goal. And the task object is to describe the task state, plan, results. And confirmation object is for the human to do some confirmation act before the NMS actions. And okay. And that's the young tree of this data model. In this data model, we also define it to three RBCs, the submit the intent, resolve confirmation, and abort task. So we can take a deep look at the intent object. In the intent object, we can use the intent type to support both natural language and structure the intent. And what we want to clarify is this young model is consistent with the existing ITF young models. We can use constraints to reuse the existing young models like ITF incident young or the upcoming SLA assurance young. And here gives a example of the incidence diagnosis scenario, which we can the the a two u just to provide a common interaction structure, and the existing young models will provide the domain specific info. So that's the difference and the relationship. And this page, I I will just escape. It's just the the example a two u interaction flow. And here are some quick we can have some quick look at the hexagon demo without we we built a simulated OSS, a simulated controller with an embedded, and we implemented the a two u interface between them. And you can see that we implemented the whole process of the a two u interaction flow. And this is the confirmation card, which is super important for network scenario. And here, we list all the A2U APIs, which is implemented based on risk conf. And, Okay, just go to the last slide. So our most urgent question is where can we continue this to work? The framework and the interface. So, okay, it's for open discussion.
[00:35:47] Rachid Medbouhi: So the chairs have been discussing the many documents this week, and we believe that with the architecture document, there's a potential to do an, what's the right term, an ecosystem. If you look at the network anomaly architecture that there's a group of authors working on, we believe that with the NME architecture, there is probably other documents which could graft to do that with experiments. Again, as going back to the slide that Benoit was presenting before. So we're not saying yes, we're saying
[00:36:24] Benoit Claise: maybe. And we're going to say and we're going to sync up with Mahesh. But it's great that you've got, first of all, Hackathon and that you start to have this architecture with this document and also the other interface. So the final word would be with Mahesh once you've got the feedback of tomorrow, new working group, now or later, where do we open and not?
[00:36:48] Xing Zhao: Okay.
[00:36:49] Rachid Medbouhi: Next question, I think, is Joe. Actually, Joe, I don't think you can go. I'll let the next
[00:36:57] Joe Clarke: Joe Clark. You kinda answered part of my question as as the presentation went on. So you built working code. That's great.
[00:37:06] Mahesh Jethanandani: Yeah.
[00:37:06] Joe Clarke: I I'm skeptical that agent authors will want to embed RESTCONF interfaces into agents. I I don't see a problem necessarily defining this interface in Yang. Yang is a nicely descriptive language. I just I I just don't think the whole RESTCONF thing is it's too heavyweight. It feels like we're trying to bolt things into an an ecosystem that may have passed us by. That's just my opinion. It it just feels too heavyweight for what these agents are trying to do and and the way they're already interacting.
[00:37:45] Xing Zhao: K. Thank you.
[00:37:46] Rachid Medbouhi: Thank you. Diego, very quickly, please.
[00:37:49] Diego Lopez: Very quickly. Simply out of curiosity and probably is a too naive question, but don't I to me, it's hard to understand why you are distinguishing between users and any other thing. I mean, what what qualify a user and is different from what from on other agents? In the typical SDN architecture, this would be the northbound interface, and you don't care about who is using the northbound interface. Why why why specific being so specific about the user there?
[00:38:21] Xing Zhao: Yeah. That's a very good question. We we want to do the this integration because there are a lot of agent to agent product discussion in ITF, and we don't want to involve in those discussions. And if there is a non agent systems like the operators, OSS, want to use the capability of an enemy, it doesn't need to wait for the of the agent to agent protocol stuff. It can just use our interface to do this work. So so that's the our core goal, core rhythm. I I don't know if I answer your question.
[00:39:01] Diego Lopez: I can understand it. It's Yeah. I would say it's conceptually wrong, but it's practical. That's yep. Okay. We we can continue on this later.
[00:39:09] Xing Zhao: Okay. Thank you.
[00:39:12] Bo Wu: Okay. Actually, it's not a question to the presenter, but to the chairs and maybe Maheshie as an AD. So I I believe the kind of taxonomy on the types of interface is quite important and useful at this moment. And according to the previous presentation by Mahesh, it's clear that a two a, a two c may go to the upcoming working group. But I would like to also confirm the right place for the a two u. So, yeah, could it be answered now or later?
[00:39:45] Mahesh Jethanandani: Okay.
[00:39:48] Bo Wu: I will note this as a confirmation from you to answer this tomorrow.
[00:39:54] Xing Zhao: Thank you. Okay. Thank you.
[00:39:58] Rachid Medbouhi: Thank you. Yeah. Thank you, Boo. Boo, I'm sorry. Like, everybody is going to go down to four minutes because Joe asked way too many questions.
[00:40:07] Participant: I
[00:40:12] Presenter: I I hope I can be quick. And just like the the previous interface, the discussion on what's a northbound interface will be. So, I have another name for this is northbound task interface problem statement. So, this is from the discussion from the whole co authors. And, like, there's actually some AI driven NMA is deploying the service provider network, doing like forward diagnosis, service remediation, and feasibility analysis. And, there is a common pattern emerging that these yearly a task delegation interface that the upper system will send out quite simplified high level input, then an I may can internally acquire state correlation and acts on the analysis. So, like the current OSS Fort management system, they already have two sources, like one from user customer complain or the alarm incident from the directly from the physical network. After that event came, then OS is a system like Fort Management will diagnose the whole network, like, curate information from network controller to then there will be multiple step and that will be lengthy analysis. But, this NMA approach, they will be like a one intent goal with some constraints, then the NMA can send out structure feedback to the ops system. This is a background of this interface. Then, here is a very specific layer three VPN performance. If there's VPN corporation a have a performance, they will complain to the OSS, and then OSS system will send out well, in previous one, they will get step by step collecting all the information from different sources, then analyze, but with an MA, they can have a one goal there, and they will can collecting the all the information and analyze and give a structure feedback. So, I think there's a gap on the two category by that. How to the what's an I'm a task input and what's the output will be. If there's automation remediation supported, whether there's authorization needed there. So, that's for this VPN performance. And, another use case is that if there's a cross domain hardware fault with like, I post picture here, like a base station attached to the ingress router, access router. If there's a like, there is a fiber issue or some transparent plug issue between this base station and access router, maybe the efficient way that the upper system will send out some diagnosis task to the controller to collecting all the information. If possible, they can also initiate some OAM tooling to do the analysis. And, but the output could be because this is quite relevant with Hot Wheel. They sent the output needs to be some structure location data and what specific of the component will be. So, I will be quick. So, this is a capability because an I may right now, they're still evolving that some could be for diagnosis and some could be some alarm correlation. So, these could be different capabilities. So, how to the app system to discover all these capabilities gap we see. And so, here is a gaps analysis summary. So, I'm yeah. I I I think that. But, the question here is that this is a zero zero draft. We like to collecting more use cases and to see whether this is right direction.
[00:45:30] Yunzhe Liu: Hello, everyone. I'm Yunseo from Tsinghua University, and I'd like to share our draft of the framework for AI assisted network portal testing from specifications.
[00:45:42] Rachid Medbouhi: Sorry. One minute.
[00:45:48] Yunzhe Liu: Protocol testing is to validate whether a protocol implementation conforms all functions as we expect. However, this workflow still remains labor intensive, and engineers need to interpret interpret product specifications and identify test points, design test cases with topologies, procedures, parameters, and expected results, and then produce something that can be executed in the environment, and finally, analyze the results. There are many key challenges in this in a specification driven testing. The first is to extract test relevant semantics from the specification text, and the second is to generate some representative and discriminating test cases that can that are very useful, and finally is to execute them in the heterogeneous test environments. Therefore, we propose a framework with some explicit stages with the impulse of protocol specifications and test requirements. It has six stages of the protocol representation and current scoping, test case generation, artifacts generation, execution, and refinements. There are also explicit state boundaries between each station each stages for humans to review and trace. Structured protocol representation is to preserve the test semantics, and you can contains message formats, state machines, algorithms, and error handling. And after that, it can be used to scope the test coverage with the input of protocols representations and test requirements, and we can also record the decision for humans to review. Test case generation separates the test templates with the parameters to provide provide test cases with with both breadth and the depth. And the parameters can be calculated from the algorithms in the protocol. Finally, is the execution. AI agent can ask can can automatically generate test test artifacts such as the DOT configuration and the tester scripts from the test cases and then analyze the the responses and feedbacks from the environment, finally make refinements. And here are our next steps. We first want to discuss the respective responsibilities of AI agents and humans in in protocol testing at different levels of AI capability towards the future. And secondly, we want to discuss whether this draft should be split into separate documents for such as requirements and several stage several stage specific methodologies. And we sincerely welcome your comments and feedback. Thank you.
[00:48:59] Rachid Medbouhi: Thank you for the presentation. There was a comment from Boris on the chat, and the chairs have discussed earlier this week. We gave you presentation time because there was a whole suite of AI stuff, but we don't believe this belongs in nmop- Yeah. Was one of the working group which was suggested. Yeah. We have to follow-up, but we don't think it's here.
[00:49:20] Yunzhe Liu: Yeah. Thank you. Thank you.
[00:49:41] Rachid Medbouhi: So means that you have two presentations. Right?
[00:49:44] Benoit Claise: Yes. Yes.
[00:49:45] Mahesh Jethanandani: I have
[00:49:45] Mingxi Wu: two. Okay. Okay, everyone. I'm from live. I'd like to introduce our draft gateway for net network and knowledge graph management. Okay. Let's start from the background. We we can see that in mop the network and knowledge graph ecosystem is becoming mature, and there are lots of discussions around the architecture and the data unification, like, say, from YAM to KG and other domain applications, including the traffic modeling and incident management. I think we are moving from the basic concepts to operational domains. But there is still a gap. The larger graph construction pipeline already, but the interaction is still hard. Most especially, how to how how do users and applications to interact with the knowledge graph but without the KG operation as per test? So we proposed two points. The first is that the operators re request the deep knowledge of the underlying graph schema and t taps and the queries and tests like this, a c four and a SPARQL, which has specific not a graph querying language. The other point is that there is a mismatch between the high level user expectation. There's a low level graph operations. So the core change we're focusing is this draft is to translate the high level requests to the low level graph operations while preserving the security and the transparency. We want to this structure focuses on three requirements. The first thing is that we we need to handle the continuous inputs and and the normalized input to intermediate to repetition and to ensure security and return the synthesis of results. So we propose our three layer architecture. In the upstream layer, it's processing inputs and the interactions. In the midstream layer, it process high level Internet to the low level graph operations. Then the downstream layer is responsible to store the fundamental data and the knowledge graph. So so the upstream layer, it is supposed to two types of inputs. The first is the if the input is expressed in natural language, the other is the domain specific language. In the middle stream layer, it is responded to translate the high level high level intent to the internal category catalog under under their heading intents. And in the the downstream layer, the storage of the network and other graph and and spot some graph operations. Here is a concrete use case. In this use case, operator may want to inspect HTTP traffic regarding a specific service. So this op the operator input an intent, so you spread the initial language. And the Internet gateway translates it into the c four query language and the the return the answer of the security down the graph engine. Okay. That's my presentation. Thank you.
[00:53:15] Mahesh Jethanandani: Thank you.
[00:53:20] Benoit Claise: Alright. Thank you.
[00:53:22] Mingxi Wu: Okay. I think I have another presentation. Okay. My second presentation is about the operational requirements for the network status changing agent assist in network operation. Okay. So background is that so we are we are moving from the human driven network management to the agent assist in our workflow. So we can use the agent to call the CRM, the API tools, and correlate to the multisource information, including the topology, logs, traffic, and configurations to perform some specific tasks. So there is a new question, what and how the network data should be communicated from the network devices to the agent? A nature of first reaction is that we can just feed all the telemetry into the agent, but this will bring a high token cost and a bandwidth cost and other issues, like the semantic gap, reasoning errors, the traceable security and the convenience barriers. So the agent need a broader understanding of the of the network and has a multidimensional evidence and a faster correlation and some other capabilities. But in fact, there are many operational constraints, like the data volume limits and the privacy and the time sensitive issue. So the core challenge is that how to support the agent to perform compressed reasoning while meetings are bandwidth wise on the privacy and other constraints. So we see that the data shifts from the data for human to evidence for agents. Here, we use an example of DDoS. In scenario, the DDoS agent need to answer some questions like what IP prefix carries the most the traffic and is the traffic from multi sources. You will just feed all the information to the agent. This will only introduce some data over all the issues and privacy and policy issues. So we're seeing the in the agent, the communication shifts from data to state of evidence. We propose a state artifact, which includes payload and contest and accountability. In this trial, we pose several requirements. The state artifact needs to compact on the scope and the multiple network information. They also need to provide the bounded arrow incremental synchronization and privacy issues. This is mapping to the draft requirements. Also launched a project to to show the sketch and maybe our reference solution and the way to a compression ratio of 443. We we also want to say that we should also keep the humans loop. And we don't want to replace any existing protocols. And the NETCONF is still responsible to collect the telemetry data, but we just add the downstream and stay as a semantic layer. Okay. Thank you.
[00:56:36] Rachid Medbouhi: It was a good spring to cut the end. Congratulations. Thank you. So I know there's questions. I have a question to Thomas as a question. We'll follow-up on the mailing list. Next. Thank you, Mingxi. No. It's not we'll do questions on the mailing list. K.
[00:56:58] Mahesh Jethanandani: I have any slides.
[00:56:59] Benoit Claise: It is fine. Just need a discussion.
[00:57:01] Mahesh Jethanandani: Yeah. Just don't need that. Alright. So this is gonna be tricky. I don't know how many minutes I have. Minutes. Thank you. So couple of ways to do this would be I think this disposition as far as this working group is concerned. And then we'll I'll just give a general guidance on what to do come tomorrow, the site meeting. So and chairs to help me. If I understand of the six presentations that we went through, there was probably one that sounded like an experiment. Did I get that sense? Okay.
[00:57:44] Benoit Claise: Which one do you have in mind?
[00:57:46] Mahesh Jethanandani: I think it may be the Zhao document maybe.
[00:57:50] Rachid Medbouhi: And The NMA one?
[00:57:53] Benoit Claise: Around the NMA. Right? For the interface the interfaces. Yeah. And I
[00:57:58] Mahesh Jethanandani: don't know if that's the intention, Zhao, that you have with the document. Are you intending it to be an experiment, or are you really thinking of defining a model?
[00:58:12] Benoit Claise: And that's actually why I go to Mike. That's a good point because I saw things that are like, there is an intent, an intent ID. Right? I mean, it's a simple string. Actually, there is way more just behind a string. So there are a lot of experimentation there.
[00:58:25] Xing Zhao: Okay. So our opinion is is experimental is the possible way forward. We accept it this way. Experimental.
[00:58:37] Mahesh Jethanandani: So the the couple of ways to and so there, if you think it's entirely an experiment, then I'll let the chairs decide whether this is something they want
[00:58:48] Benoit Claise: Can I can I there is a confusion here? We speak about an experiments like in nmop, and you you I thought you understood experimental as a document. It's not it's we speak about
[00:58:59] Mahesh Jethanandani: experiment. Okay. Sorry. Okay. Thank you.
[00:59:01] Xing Zhao: So the experimental means is experimental individual draft or it will be an individual an experimental track to be adopted by the nmop? Which which meaning?
[00:59:16] Mahesh Jethanandani: Yeah. So I think what it what the nmop working group is does is it does takes on experimental work. Forget the status of the document. Right? So for a minute, just set set that aside, whether it's a proposed standard experimental information. Question really is, nmop does experiments like Benoit did in the beginning of the meeting. Does your document fit that category of experiment that Benoit described?
[00:59:46] Xing Zhao: Yeah. I I suppose so.
[00:59:49] Mahesh Jethanandani: You think so? So okay. But so a couple of ways to do this would be if you're thinking of a Yang model definition, split that work separate from the experiment itself, if you understand what I'm trying to say. That would be one way to deal with document itself.
[01:00:10] Xing Zhao: You mean just take the Yang model out of the draft?
[01:00:14] Mahesh Jethanandani: Right. So the portion nmop can work on, if I and just do feel free to correct me. If it's being defined as an experiment Yeah. Then do the experiment in nmop. But if you're trying to define a yang model
[01:00:31] Xing Zhao: Mhmm.
[01:00:32] Mahesh Jethanandani: Then that would go, I think, in the proposed new working group.
[01:00:38] Xing Zhao: Okay. Okay. I So think I
[01:00:42] Benoit Claise: actually, let me, as a contributor, say, if we take the analogy with the network anomaly, we had an architecture and then we had multiple extensions to it, which were even like Yang modules. It just happened that those Yang modules and those extension were sometime in NetComm, sometime in different working groups. Mhmm. So it depends and actually, it's having a pain because you have to track multiple working on all this. So if there is an architecture and if there are experiments that are, you know, self contained
[01:01:14] Diego Lopez: Mhmm.
[01:01:15] Rachid Medbouhi: It
[01:01:15] Benoit Claise: would be better to be in the same place. Now it could be the new working group. It could be here. We have to define what experiment is. If you're committed to, you know, the kind of one, two years effort and all this, you have to discuss this.
[01:01:28] Participant: I wanted to understand that what is the experiment. So if we remove the young model, which is the standardization part, what is needed for interworking? What is left in the experiment? The framework? What what is
[01:01:40] Mahesh Jethanandani: That's for the authors to describe what is the experiment. I don't know what the experiment is just by looking at the document.
[01:01:49] Rachid Medbouhi: So, I mean, you could use the framework do an experiment with, I don't know, agent to user. I mean, you've done part of that already, I think, in the in the hackathon.
[01:01:58] Thomas Graf: Okay. Okay.
[01:01:59] Rachid Medbouhi: Right? It's that kind of stuff. Maybe you can expand, maybe not. Done. So done. Okay.
[01:02:07] Participant: What's the impact then for nmop if we are talking about the young modules being out and experiments in? Is it just for AI, or is it
[01:02:16] Rachid Medbouhi: No. It's not in general. Future work? No. It's not in general.
[01:02:19] Participant: Just for AI. It we were talking regions.
[01:02:21] Mahesh Jethanandani: Yeah. Yeah. This is very specifically we're talking about AI. Okay. I know we are out of time. Yeah. The only question left is the disposition of the remaining drafts, I would say, well, take it to the site meeting tomorrow. We don't have enough time to go through disposition of each draft. I'm happy to talk to the authors separately.
[01:02:41] Rachid Medbouhi: Thank you, everybody. See you in San Francisco or in Kuala Lumpur.
[01:03:25] Mingxi Wu: I got confused. Am
[01:03:27] Ying Zhen: I'm sorry.