Session Date/Time: 24 Jul 2026 07:00
[00:00:37] Roberto Manzotti: Okay.
[00:00:42] Fatai Zhang: Hello, Okay. Guys. Good morning. So let's start. So welcome to CCM. Okay. Let's start from the load where I I think we all of us, you know, are familiar with this loadware IT policies. Otherwise, please look have a look at this documents mentioned in this page. So and we know this this session, it's being recorded. And for the in person participants, please make sure to sign into the session using the mid echo tools, and then use the mid echo to join the MyQ. And, also, please keep the audio and the video off if you are not going to speak. And for the remote participants, please make sure your audio and the video are off unless you are, you know, speaking. And the use of a headset, it's generally recommended. And then this administrative information, and there's links for the mid echo. And I think we know how to use their, you know, the online tour and how to, you know, press the buttons. And for the minute takers, yeah, and, you know, there's a button on the top of the echo, and, you know, you can click and then it goes into minute taking. And if anyone can help, you know, taking the minutes, that would be much appreciated. So we just just just talk about why we are in the AI yellow, why we still needed to, you know, meet takers, why we cannot just use the transcription, be saved at a minute. Right? So for the blue sheets, so last thing for us to do, it will be automatically generated. This is very good. And for the demand IPR process, so prior to moving to next step in working group documents, for example, before individual draft becomes a working group document or a working group document goes to last call, the chairs we send out IP polling, and they requires can also and the computers to provide the polling as soon as possible. Otherwise, may it may delay your draft to move forward. So this session, this time, we have only one session with two hours. So there's agenda. So this time, we have two hours. So I think we should have enough time for for discussion. And, you know, yeah, there's some type. And, you know, we have
[00:03:51] Daniele Ceccarelli: No. It's not it's not a typo. We we changed the agenda after it was published. We antich anticipated the microwave presentation to the third slot. The we did some agenda bashing to meet traveling constraints.
[00:04:10] Fatai Zhang: Okay. Good. So this time, we have three individual jobs. You know? Right. Okay.
[00:04:24] Oscar Gonzalez de Dios: So
[00:04:26] Ramon Casellas: I I will cover briefly the the status of the working group. So, basically, well, you know well, we we are documenting regularly in the in the wiki all the the status, the the evolution of the different drafts. So you can see here the the the two prioritization queues that we are handling, one for working with the option and the other one for progress in the the documents already adopted. So we are always marking priorities, three priorities. So in in both columns, you can see the priorities that we have identified so far. So for adoption, we have the draft June c c c cam PM streaming. This this working group adoption sorry. The working group adoption of this draft was stopped after discussions with IPPM. And, basically, the resolution of this was to split the document between IPPM and PCAM, and we even this week was presented in IPPM part of the work so that this somehow is progressing in in parallel. Also, as priority one, we have the SICAM f e o t n yang document. This has been just adopted. So we we move to the to the other column in some point in time. Then we have the CKAN RFC eighty five sixty one b's. That is the microwave radio link that that, I guess, Jonas will present. Right?
[00:05:44] Daniele Ceccarelli: And then the CKAN client PM, Jan. Also, we we need
[00:05:48] Ramon Casellas: to check how to do this together with IPPM and and see how we can progress either here or here or there or there. Regarding the documents already adopted, we have the the second working group last call was already completed, so has been requested publication of this draft. We will report in the next. Then the WDM interface parameter, yang. Basically, we have passed the the reviews of the directories on routing, operations, and also the young doctor is ready for working group last call. And we we have here a note for checking potential dependencies with the work on on pluggables. The team has been signaling draft, so there are some some reviews done are pending to be fixed. And this, I think, September is the date for for that that we expect for for being covered, all those comments that we received. And finally, have as the fourth priority, a clustering of two drops, the OTM tunnel model and the path OTM path computation model where basically yeah. We have also received the the reviews from the the the electorate and the young doctor review. So for the the first of the documents, there there were no recent RFCs. In the editor queue, we have five documents that have some dependency, some misref depending on this, if I'm not wrong. And as said, we have requested the publication of the Flexigrid Yang document. In the agenda, we have two of the doctors drafts, the d w the WDM interface parameter and the WDM tunnel yang. And for the rest of the the documents, please go through the wiki, and you can see the latest status. We we encourage to have, let's say, a spontaneous update of the status. It's always helpful. And but by the way, we will try to regularly update the status so that we, all of us, we can handle fresh information record register in the wiki. Regarding liaison statements, we were consider well, we were working on liaison relationship with OEF. This basically was already done, and Italo- has been nominated as liaison manager. So now Italo would be the bridge between ITF and OEF. And then we have three other liaison statements related to CEACAM. One what coming all of them, I think, are coming from the ITUT. You're not wrong? Yes. No. Sorry. Two of them from ITUT, another one from Robotn-four. The first one is the the one that was requiring some action together with and and and it's about informing the the latest work on on the area of IMT, 2020 IMT, 2030 to ITUT. We already passed the date, so we will try to see how we can basically maybe recover or what we will discuss maybe with the net and teach on how to progress it if it makes sense. Then we have two informative liaisons, one from the forum and another one from ITOT about signaling and protocol considerations for on networking for AIA and collaboration. So set are informative. So if someone from networking group has any input on that, it's it's we'll be we'll be safe. And that's all from our side. So let's start no. Sure. Any comments? Yes. Yeah.
[00:09:15] Dhruv Dhody: So just a quick thing about the liaison thing. I that's what I was just cross checking with Daniele. There is a liaison which is going out going to go out towards ITOT for the PM work, which you just described. Correct. And I was just cross checking this morning. So that's mainly coming from the IPPM group. Yep. But CCMP is also on it.
[00:09:40] Ramon Casellas: Is it? Yeah. This is thank you for for the reminder. Yep. Any comment from the working group? Otherwise, we will start then with the with the meeting. So
[00:10:04] Daniele Ceccarelli: k.
[00:10:07] Roberto Manzotti: Good morning. I'm Roberto Manzotti presenting this draft in behalf of the quarters. This is a data model for the management of DWDM interface. Which one? Okay. Yeah. This slide is there since a few IATF meeting. We are keeping it as a reference just to show also the status update of the other related model. So the other two main model model that are now connected to this one are get to the RFC editor queue. All the other are already RFC, and we have two draft that are this one and flexible grid topology that exactly TWDM tunnel that that are still work in progress at the moment. For this slide, let's focus on the on what is new for for this new update. So from the issue tracking, we closed the last two issue that we had open, and we are having one minor issue from the follow-up comments that we are tracking now for foreclosure. So which are the main document change that we apply since last revision? For the young model, I think the the for sure, the last update has been the alignment with the work on the pluggable gap analysis, and we decided in conjunction with the with the team there and text them to add all the attribute that were coming as state, so as operational parameter to the DWDM interface. So in order to fill at least the gap that was highlighted in that work for what concern the operational state of the interface. We also realigned the model to the network management data store architecture. In a past revision, we were splitting the configuration and operational data into different branch in a way similar to what OpenConfig does. But, actually, after discussion with the wider team, we follow the approach of IATf to have one single parameter for operational and configuration and manage the related value using the data store architecture. And then we have some other minor fix and cleanup on on the model. For all concerned, the document, the main change are the fix for the comments, the last two issue open. So we updated one appendix with actually, we added a new appendix with a description of how the module should be used and which is the main concept and how it's structured. And we updated what before was appendix c and now appendix d with a complete JSON example. Before, there was just a very tree that was providing an example of application. We now have a complete JSON example of the use of the model. We just want to flash the what has changed right now in in the model tree. So this is the initial part where there are just few changes. One one attribute has moved from read read only to read write. That is the line code in bit rate. And we had that did the received total power and also another factor counter for the uncorrectable blocks paired with the uncorrected words. And while the large changes in the last section of the DWDM interface where we added a lot of new attribute that we are coming from the gap analysis work for the optical interface management. I invite so all of these value has its own specific reference to standard ITT, IETf, IETf, or whatever, but so I invited a review of the model so that we make sure that the whole the reference are perfectly aligned. And what are the next step? We are actually able to address this last minor comment from the follow-up. That is basically a review of the deferred value in the model. Actually, we already started this, and we feel that it's good to have a default value defined also for the read only data. So just to give to the implementer an idea of which could be the the default value for for that part of the tree. And the other minor is the update of the reference to eighty four seven b's that now is becoming RFC. And then we think that we should be ready for the request of the last call. And if there are any question mostly, I think what can be interesting to to look at is and to discuss is the the all the new parameter that has been added that is the bulk change. So
[00:15:53] Daniele Ceccarelli: I think we already did the the routing data
[00:15:58] Oscar Gonzalez de Dios: Mhmm.
[00:15:58] Daniele Ceccarelli: Review. Two young doctor reviews and one review. And most of them are pretty recent. So do you think that the new the new changes to the model would benefit from another young daughter? I mean, the the pool of young daughters is pretty reduced. So we have a limited amount of tokens to to play. If you think that there are significant changes, we can ask for a third review.
[00:16:30] Presenter: Also, the there are
[00:16:31] Roberto Manzotti: significant changes in the number of attribute, but in the model structure, not. So, basically, the the way the model is structured is is the same that we had after the correction and the acknowledge of the change that we had with the last.
[00:16:49] Ramon Casellas: Okay. So Perfect.
[00:16:50] Roberto Manzotti: In theory, I do not expect any
[00:16:54] Daniele Ceccarelli: So we will wait for a new revision fixing the last updates coming from the the last comments from the routing the review?
[00:17:03] Roberto Manzotti: We will do probably just after
[00:17:05] Daniele Ceccarelli: the And after that, we can do the final reviews and start the the the last call process.
[00:17:11] Ramon Casellas: Okay.
[00:17:14] Daniele Ceccarelli: There there is one note that we took when we were working on preparing the admin slides, which is the impact of the pluggable work on on this draft. Do you think that
[00:17:28] Roberto Manzotti: I That's gonna consider all the all the people that are working on it, I think from the last activity that we have done, all the operational state parameter, now we should have integrated all the work of the pluggable team. There is still an open gap big open gap from the pluggable activity that are the capability and update. But, unfortunately, that is not in our model. We are importing this from the 1993 visa. So the update of the capability will require and we all agree that it's good to have it in a single place so that every other model can import it and will require probably an update of So the 1993 b suite, the Ether or or with the Veloce. Exactly. That's With the Veloce process, so that is what we are trying to focus and probably will be shared by the.
[00:18:25] Daniele Ceccarelli: Good. Yeah. I don't know what's so I've seen the requirements for Veloce, but not yet all the the procedures. So I don't know if this time it makes quicker to go for or to wait for the launch, but in any case
[00:18:41] Roberto Manzotti: Depends on when 9093 biz will close the RFQQ.
[00:18:46] Daniele Ceccarelli: Okay.
[00:18:46] Jonas Allberg: Okay?
[00:18:49] Daniele Ceccarelli: Thank you. Oscar has a question.
[00:18:51] Roberto Manzotti: Oh, I'm sorry.
[00:18:52] Oscar Gonzalez de Dios: Yes. Can can you go to back to the slide with the the first one, I think, the the relationship with between the models?
[00:18:59] Roberto Manzotti: The first one.
[00:19:01] Oscar Gonzalez de Dios: Yes. This one. Right now, the it is this model, it is intended only to be after the ITF interface, but it will be have relationship with the topology. Right? Yes. Do you and question for you and and Daniela is, at some point, do you want also to make the relationship with Ivy or not? Or it is because in Ivy, you define the inventory of the Boards. Of the boards and transceivers, even at some point, but also transceivers. So some of the attributes that you are defined here, someone could have them also there, not only for here is for configuration, but also for for inventory purposes. So that that line, do you consider it at some point? And if there was such line, do you think it would impact the the model as it is? Or at least or you have a collection of identities and leaves, it can be, let's say, reduced easily.
[00:20:00] Roberto Manzotti: Tell you my my view, then then the other will plot whatever. So I the the F Param is mainly a model for network element management. So it's not it's controller to device. It's not a controller to controller. Nothing block it to be used also between controller, but that is the the the way it is designed.
[00:20:21] Oscar Gonzalez de Dios: Okay. So now it's it's between con controller and device And device. The main the main scope.
[00:20:25] Roberto Manzotti: Not Yes. The main scope. Say that. I think that for every interfacing in theory in the topology or in the topology, there should be a related termination point. I see that the topology relation that is going to be present, so the the the the IV topology draft that is already mapping IV to the topology should also get Okay. Inherited also the connection to the interface. That that that is my intention.
[00:20:55] Oscar Gonzalez de Dios: So you think with that should be enough, and there should not be no need to do a tie the trial agency between between the other four. Yes. Okay.
[00:21:03] Ramon Casellas: Do you think? Do think? Yeah. I agree. Okay.
[00:21:08] Oscar Gonzalez de Dios: Thank you.
[00:21:09] Ramon Casellas: Sure. Okay. Thank you. Thanks. Thank you, Robert. Thank you. So I think that was the turn for Iowa.
[00:21:26] Aya: Yep. So this is for an update on the young data model for WDM tunnel. Okay. So so this this draft is pretty stable, but we are still having some open issues and primarily focusing on the analysis of of WDM tunnel going through a three r regenerator. So there are different types of three r regens and how it affects the the modeling of of the tunnel, whether it's end to end or it's it's it's it's brought into different segments, and there are also different types of three r regenerations at different layers, you know, with different technologies. So for this update, we only did very editorial model and text updates, but the main thing is progressing is we are still discussing and make alignments different scenarios. So the current status is the review is almost done, but we still have cases that needs to be finalized. And the main work that we have done is to focus on the main case and eliminate some edge cases and proprietary use cases from the consideration. So here, it's just a a summary of the covered WDMs scenarios. We are looking at the end to end WDM tunnel provisioning with both transponders and max ponders because they present different characteristics in terms of the the the use of the tunnel. And they are also looking into different kind of client payloads and different client side and line side run line rate of the transponders and multiplexing and also considering the OTSI inverse multiplexing and the the way how signal is digitally mapped from the client to the line side and whether region is is used or not in an end to end WDM tunnel. Also, there are different region scenarios. Some of them are standards defined, like, by ITT, by different MSAs, but they're also vendor specific or proprietary scenarios, which was as well as as well as forum defined cases like OIF. So for those for those defined by the MSA or proprietary or by by other forums, those scenarios are also analyzed along with the with the with the with the the other scenario just to evaluate whether the model is flexible enough to support, but to the actual support for this, nonstandard, scenarios, basically, we considered it as, it can be augmented by the current, from the current model. And, so there's an open issue 75. There's a diff diff detailed analysis of the scenarios currently in progress. So yeah. So as you see, like, this is just to show, like, we what do we have done in terms of analyzing, these scenarios from the simple one, such as, Ethernet, 100 Ethernet over single OTSI, and also o t ODU four tunnel segments over, over single OTSI. Those are done, and there's a the third scenario about OTSI for an OTSI over a single OTSI, and it's coming from from the OT I OTU OTU switch or or IP router at coming to the optical end as a gray wavelength. So for this scenario, we have considered few two options. One is to to create basically, to establish an end to end OT or for a link between the between the OTN switches. But and they are being supported by by by a combination of gray client side links plus the the client signal established between the two WDM nodes or as an option two, the o two four link is supported by an end to end WDM tunnel. And with the WDM with the the, the connection in between the two transponder, as, WDM tunnel segments. So, this is still under, under evaluation, and we need to make a decision on whether how this can be supported. And we still yet need to support to to do the analysis for OTN OTSI service as in the scenario four. Yeah. So odd we also analysis on the four four hundred g Ethernet service of a single or multiple OTSI and how they are regen in the middle. And yeah. So what we are to see is whether we need to diff develop the definitions for that defines the regeneration layers that and also defines the the definition of digital termination and also the sequence of the digital termination as well as the definition for inverse multiplexing types. So those are those are the gaps that we have identified that needs to be developed in the YARM model, and also depend depending on the analysis, which determines how many types that needs to be defined. So the next steps is, obviously, to complete the review of all the scenarios and then also update the text as well as the young models. And, also, there are previous routing director reviews and young doctor reviews that has still remained open that needs to be that needs to be looked through. And, yeah, and, also, since we are working on the pluggable analysis, this may also come into the this draft as as gaps that can be covered. We have weekly discussions on Thursday, 9AM. So you're more than welcome to join it to help complete the analysis and develop the model. And that's it. Thank you. Any questions or comments?
[00:29:11] Ramon Casellas: Okay. Yes. No questions. Thank you. Yep. Thank you, everyone. Thank you, Aya. So now is Jonas.
[00:29:29] Jonas Allberg: Hi, everybody. I'm Jonas Allberg. I'm the one to blame for the change in the agenda, but I appreciate that. Thanks a lot. I'm here to present the status of a draft we are working on within the microwave team. And I'm doing this presentation on behalf of all the participants in the microwave team and especially on behalf of Scott, who has created all these slides. So thank you. Starting with a bit of a background. We are talking about a young data model, a device model for microwave radio link. And we are working on an individual draft right now with the intention to create a base of an existing RFC85-sixteen. And we are doing the work using a GitHub, which you can see the link to. And we've had 11 meetings since the last IATf-one hundred twenty five meeting. And we meet every Thursday between five and 6AM US Eastern Time. And if you're interested in the minutes, there's a minutes page on the GitHub. So what has happened? We have refreshed the draft and a call for IPR is underway or it's perhaps even completed. But the next step we are hoping for is and it was listed out on the list of priorities here as well for a working group adoption call. The version we have on the data tracker is zero version of draft with a new name. And we changed the name and included cCamp in the name just to indicate that we believe that it belongs to this working group, even though it's not yet been adopted. And we have done minor changes to refresh the draft while we are having discussions on our weekly meetings and using the GitHub. I see that there are questions.
[00:31:46] Ramon Casellas: Do Just a clarification on Jonas about the IPR call. There is one now for the thing, no not answering. We can basically, the the email address is not any longer valid, so we need to figure out what to do with that just to clarify that point.
[00:31:58] Jonas Allberg: Okay.
[00:31:59] Ramon Casellas: So we are missing just one answer, but we are not able to
[00:32:02] Jonas Allberg: Okay.
[00:32:02] Ramon Casellas: Either This was a call for for an NEC. There were two two co authors for one is a contributor. Like, the call for is silly, and she already answered, but one of the contributors is not basically cannot reach him. So Okay. We will need to figure out what to do with that Okay. For clarification. Okay.
[00:32:29] Jonas Allberg: Yes. We have done we have worked on this draft for quite a long time now. But we believe that we will be able to conclude this in a fairly reasonable time going forward. And the reason for that is that we now have an agreed list of open issues that we intend to resolve. And we have resolutions preliminary resolutions on most of them. So hopefully, we will be able to get to a conclusion fairly soon here. And I'm going to walk you through some the open issues that we are working on right now. The first one is about a mode of the radio link, which has been a configurable attribute. And we've updated that in the draft that is on the data tracker right now to make it more flexible and allow for more variants to be configured. But then we realized that this attribute is actually impacting the same aspects of the microwave link as other attributes are used for configuration. And that means that in order to avoid a conflict here, that we configure this in one way and the other attributes, which actually is doing the configuration of the radio link in another way, we decided to use this attribute as a read only attribute going forward. Because it still has a value since it represent some kind of a high level description of the configuration of the radio link. Space diversity is a function to increase the signal quality by combining multiple carriers in a radio link terminal. And there, we have a proposal. And we are just reviewing that to make sure that this proposal is in line with how this is done in a standardized way and not only representing a model for one specific vendor implementation. But I believe that it's a standardized way. The third one is about a request to introduce a new loopback function. And there, we agree that it's probably needed. But the question is if it really belongs in the microwave domain or if it's perhaps rather something that we should introduce in the Ethernet space. The fourth one on this slide is about cross polarization interference cancellation. And we support that already in the model today, but this is about allowing or extending this function to do cross polarization over multiple nodes. And there, we have a fairly straightforward proposal, which I think we can agree upon fairly soon. Then air interface receiver is about being able to disable and enable the receiver functionality. And there, we have a proposal, and we also have a pull request for that. And we're only looking for more vendor input to make sure that this function, as modeled in this proposal, is supporting the use cases that we believe would be requiring this type of function. The next one, air interface maintenance timer is has been on hold for some time, waiting for the conclusion of the RSC nine thousand nine twenty two, which is about scheduling of functionality. And now when that is ready, we believe that we can create a contribution fairly soon. The next one is a bit interesting, I think. It's an existing function we model in RFC8561 today. But we have realized that, that modeling might not be in line with how the ETSI specification standardizing the microwave technology as such is describing that function. So we might need to change that in order to better align with the sort of technology standardization or the description of that function. It might have a bit of impact on other aspects as well. But we believe that it's important that we are not modeling things, which might be a common way of doing it among vendors, but which is not in line with how standardization is done in other parts. And the last one is about band and carrier aggregation. It's a functionality to combine carriers in different ways in order to increase the capacity of the radio link, to increase the quality of the signal, etcetera. And there, we have worked through a number of alternatives. And right now, we have one alternative on the table that requires a review and agreement upon. So all in all, we have a number of open issues to close, but we believe that we are in a good position to do that fairly soon. And then as always, we have editorials and guideline checking that needs to be done on top of that. We have closed some issues since last ITF meeting. And the first one is about a request to increase the ranges, the value ranges for two attributes, signal noise interference ratio and cross polarization interference. And there, the request was to include also negative values, but that was rejected since microwave experts clearly stated that that's not really applicable to support those type of negative values. And the other one was a question raised about a new entity in the model, which is ACM profile list. And the question there was if it's reasonable to include a list that might require thousands and thousands of entries in order to fully describe the capability of the node, which was or is the purpose of that profile list. And the resolution there was that it might be a problem, but on the other hand, this attribute is not or this list is not mandatory, and therefore, we can move forward as proposed. Okay. So in summary, if you're interested in Microwave, please join the discussion on the GitHub and on our weekly meetings. And watch out for the working group adoption call once we have sorted out this with the And final IPR thank you all from all of us, editors and contributors. Thanks.
[00:39:54] Daniele Ceccarelli: Thank you.
[00:39:59] Ramon Casellas: No questions? No comments? Okay. So, yeah, we will figure out what to with the, like, this contributor that is missing. If we cannot reach out, probably we need to maybe move him to
[00:40:12] Daniele Ceccarelli: Yeah. Acknowledgement. Yeah. Yeah.
[00:40:14] Jonas Allberg: Can you repeat the main name? Or
[00:40:16] Ramon Casellas: I don't remember
[00:40:17] Jonas Allberg: his Okay. But can you can you send me Yes. The the name and I was checking.
[00:40:20] Ramon Casellas: I was checking with she because it's both were from NEC.
[00:40:24] Jonas Allberg: Oh, okay. Oh, so Xi can't
[00:40:27] Ramon Casellas: that that is any longer working for NEC. Uh-huh. So we don't have a way of contacting him.
[00:40:31] Jonas Allberg: So Okay. And then I have Probably not in a position.
[00:40:35] Daniele Ceccarelli: We are even before the adoption stages, I think we can remove him to the acknowledgment list and move forward. I don't think it's a big problem.
[00:40:46] Ramon Casellas: Moving from contributor to to the acknowledgment if you wish. And
[00:40:49] Jonas Allberg: Okay. Sounds good. Okay. Thank you. Thank you.
[00:40:58] Ramon Casellas: So then I can express the next one.
[00:41:10] Presenter: Thank you. Good morning. My name is. On behalf of coauthors, I will go through a few slides to show the status of the pluggable draft. The short summary of the draft is outlined here. We have weekly meeting for the draft. We had three constructive meetings, this week as well to go through the rest of the attribute that we have to address. In summary, there are attributes in the area of the capabilities, configurations, and stats that we went through various STOs to bring those together. As Roberto mentioned at the beginning of today's meeting, we identified gaps in the area of the stats and config. It's already added to the draft. The rest of work that we have to do as outline at the very end of this page is about capabilities. So this is a short summary of where we are. Aesthetic and config, we feel that we are almost done. Having said that, this is the ongoing activity as well. If you feel that there is something should be added, we have a Google Sheet. We discussed a few times. I don't wanna repeat whatever was discussed before. More than welcome to provide your comment. So for the rest of presentation, I just go through the config, a stack, and capability, I give you more context where we are. So but that is the basically, the short summary of what happens. As mentioned before, about a statistic as config attributes, these are basically the gaps that we found related to coherent pluggables. And in most cases, or actually all of them, are not only pluggable attributes that are applicable to other entities as well. But in the context of the pluggable, we identify gaps on a statistic config. They are already added to the model WDM interface. And I will update the draft. Right now, the draft itself. It's in version three. I will add whatever I just discussed. We didn't have time to go through it and finish it. The next version of the draft will include, you know, what happened the in the the area of the size and configuration. What is outstanding? And this is something I mentioned. We had a very, tree constructive meeting this week. We went through the, capability attributes. These are the read only attribute, which are basically characterizing the capability of a pluggable. We find the gaps. We went going through the Google Sheet, which outlines everything that we found, and we covering whether or not they have to be added to the model. And the most important aspect that I put here is for those capabilities where we have to add them and clearly mention here that we decided that, collectively, we have to have one place to address all these attributes, and that place is nineteen ninety three b's. That is something that we discussed. Right now, at this time, we are doing two thing in parallel. One is covering one more time the capability going through that, scrutinizing it to make sure we capture everything correctly. In the meantime, we want to add that one to nineteen ninety three b's. We will put that one in the private GitHub, and we do that one in parallel. By the time that there was a discussion about the the new Veloci way of introducing b is at IETf, which is a very lightweight. So by the time that that discussion is finished, we are also done with the attribute, and we can basically provide our last part of the coherent pluggable work in this context. So having said that, you know, if I summarize where we are and what the next steps are, we are watching the Veloce initiative to see where it's going. We are working on the capability attributes. We are finishing that. We are incorporating that one into nineteen ninety three biz as a private in our GitHub. And by the time that Veloce is there, our model is there as well. And, basically, that as a a state at the very end of this page, this will be the last portion of the pluggable work that we do. There are some other thing that we can extend on top of this, you know, that is extra works. The but the context of this work is basically this capability attributes. And hopefully, next few months, we can if the velocity is there, we have the model, and we can provide the the last portion of the coherent pluggable that we have started, you know, the a while ago. With that, it concludes the discussion. If there is any question, please. Thank you.
[00:47:18] Daniele Ceccarelli: That was fast.
[00:47:19] Presenter: So okay.
[00:47:20] Ramon Casellas: Yeah. Thank you.
[00:47:21] Presenter: Okay. Thank you. Thank you,
[00:47:24] Ramon Casellas: So next is. Good
[00:47:46] Presenter: morning, everyone. I'm from NTT. This draft is a young data model for a semi success control, and I present the update of this draft on the behalf of the. It is now the revision, the three, and we we we we have a new co host, Reza Lokui from CNR. Welcome, Reza. Here is the agenda of this presentation. Today, I will cover four points. First, recap of this draft. Second, update since previous version zero one. A third, liberalized to feedback arise in the last meeting, I t f 134. And finally, next steps. So let me start with a short recap of this draft. The first is the motivation. So coherent programmable module have some attributes and the feature features that obstructed model cannot cover. So there are two types. First is one is OPU attribute such as custom pages, which vendor specific field. The other is function which module is capable of that network OS does not support yet. Sorry.
[00:49:37] Ramon Casellas: Sorry.
[00:49:40] Presenter: This proposal provides the capability to use such features, which are not supported by the abstracted model. And this module structure shown in right side mirrors the CMS memory maps, CMIS memory structure. So page number and bank identifies CMIS memory map. And data to write or read or write is defined with offset size and data value. This yang is assumed to be augmented to ITF interfaces, and it attached to the interface where the module is plugged in. The access goes over the standard NetoConf or RESTCONF schema and NetoConf RESTCONF server on the host network OS will be the entry point. Okay. So we have two use cases of this model. Firstly, it's centralized control of protocol module. Today so sorry, module for layer layer one private network services. Today, we can use new optical features only after the network OS support it. It have some limitation on the combination of the network OS and programmable modules. So and this model enables to enables to controller to handle the features of which is not supported by networkers yet from the con optical controller. And it may relax the combination constraints between network OS and the probable module. It will help because operator can select the module more flexibly, and router vendor does not need to support the new optical features right right away. The second use case is custom pages. So there are several features using custom pages. For example, high accuracy met optical metrics measurement, such as measurement of the object characteristics or non sec second order delay trans transport delay measurement, like at the right side figure. Okay. So this slide shows the update from the previous version, one to the zero two, zero three. As I mentioned at the first at the beginning of the presentation, Reza joined our OSHA team, and it will help coordination with probable modeling work. And as second, we added the page level access governance. In other words, we added the we defined the default policy and the RO list in the structure. So the operator expressly presidly delegate only selected pages to the remote controller and action RPC to write to the output of policy pages will be reject rejected. So it's will be the safeguard for prevent safeguard for preventing the unexpected operation from the outside controller. Third is thirdly, we added the CMS page classification by function. So it will be the basis for deciding what pages can be delegated to the external controller. And, firstly, we improved the use case use case section. For example, we added the OpenXRAR Pizza MP communication scenario. And it's just a note, but we collected the reference and the technologies and restored the primitive modules on the update from the zero two to zero three. And it's there there are no changes on content on this update. Okay. So let me clarify the position of the this draft. So this draft is just complement for the current the product abstracted product group modeling work. So this draft provide the capability to handle the OPAQ attributes and the features not yet supported by network OS as option and as a opt in schema. So this draft will not compete with the current and past abstracted modeling. So in the following two slide, we summarize the reply to feedback rise in the ITF-one hundred twenty four, and I will explain the important three I will explain the important three points. So first question is who manages DCO transceiver? And the answer is the host of network OS still managing the entity for the TCL transceiver. And this draft provides just option to delegate control some limited attributes and feature to external controller in the obtained schema. The second question is how to handle the this transceiver, and the answer is obstructed model is fast always. And register level only where obstructed cannot be cannot reach. But the custom pages semantics are vendor specific by definition, and it will be difficult to abstract in advance. So for such cases, this draft can be useful. Third question is safeguard. And, yes, this path does not go through the network OS management functions. It is by design, but it is bounded because we added a row list and the right is denied by default, lower memory rights prohibited, and network OS can disable remote access entirely if needed. So we we can prevent the unexpected operation from the controller. K. And I summarized the remains question and the re replies. So and but it's early time limited. So I was I will not explain in each item, so please read them. And if you have further queries or comments, please let me know on the mailing list. Okay. So next actions. So we believe that the draft is ready because we have the draft have stable young five young modules, and they clearly defined the use case or scope. And we addressed the feedback from the last meeting. And but we I had the further feedback in this week from the some implementers. For example, there are scalability concerns or more of further security risks. So and we are preparing to provide the next revision as zero four, and we will publish it soon. So with that, we would like working group to consider call for the working group adoption for this draft. Okay. That's all. Thank you very much.
[00:59:18] Ramon Casellas: So I
[00:59:22] Fatai Zhang: have one comment. So please move to the, you know, page on positioning.
[00:59:27] Presenter: Okay.
[00:59:28] Fatai Zhang: Yeah. Actually, in the previous page, you mentioned the two use cases. Right? One is, you know, centralized control for the pluggable and other one for the custom pages. So do you mean I think, actually, for the first case case, it should be covered by draft. Right? So do you mean that your draft only covers the second use case or not?
[00:59:54] Presenter: So so sorry. I reused this figure in past presentations. Right? And in in the first use case, basically, the abstracted model by used by optical controller. So this model use of this model is there should be limited. So I I think it it's we'll buy right the current obstruction box.
[01:00:30] Jonas Allberg: Roberto.
[01:00:34] Roberto Manzotti: Hi, Roberto. Thanks. First of all, thanks for addressing most of so all all of the comment basically related to the security and the protection of the page that should not be, let's say, exposed and so on. I still have someone my main doubt is still not really on the technical feasibility, but on the administration of this this model. So if I see it very good for experiments or for lab work. I don't know. And here, I would like to hear the comment also from some operator if this is something that can be set in production and an operator is maybe going to do this type of tweaking on the interface on a production network. I would like to have some comment from operators. So yes.
[01:01:31] Presenter: Thank you very much for your advice, and we we will cover your feedback. And, yep, we are considering to the yep. Make make some examples in the for operation with this. Yeah.
[01:01:46] Dieter Beller: Yeah. So me from Nokia. Right? So this is something that you and I, we discussed this week, but I'm kind of stating this for wider audience. Right? I I kind of understand the need for some kind of, you know, setting transparent attributes that goes and changes the CMS, you know, without waiting for the implementation on the on the NOS. But the way this model and and the use cases are defined, you implicitly have a dependency on the NOS implementation to actually to read the yang and and and update that. Right? So it's it's not fully transparent. Right? Now if it's dependent on on and on an implementation, then would it make sense to kind of cover the use cases that you have in the pluggable drafts that that reason I be working on so that, you know, that becomes one more use case and one more, let's say, gap in in in in what we have. That way you have, in in my view, a faster chance of of of completing it in a single draft rather than having two. Right? I mean, if if the requirement is that you need to have a capability for, you know, transparently setting the attribute and just read and write, And those could be, you know, some of the leaves in in in the config and and state trees of that. That's that's my comment.
[01:03:16] Presenter: Okay. Thank you. And I hope we can continue to discuss and incorporate.
[01:03:23] Ramon Casellas: My turn now.
[01:03:24] Daniele Ceccarelli: So first of all, thanks a lot for the the slides are are arranged. This is a template that we all should follow replying to all the comments I received in the past. This helps having a recap and better understanding it. So from a chairman point of view, I have nothing against this work. If there is a support in the working group, I'm perfectly fine to to progress it. As a contributor, I still I'm still struggling to understand why you wanted to standardize a mechanism to configure, customize the parameters. So the I mean, the my my comment is a little bit aligned with, what Roberto was saying. Is this something that would go in production, or is this something that is used for a for an experiment? I mean, maybe we could also consider the the the experimental track if if this is the case.
[01:04:26] Presenter: So one of the reason that from the operator aspect, we would like to select the more cheaper, more good digital transceivers, but there are limitation on the use of the router or yeah. So we would like to relax that invitation with this module.
[01:04:57] Daniele Ceccarelli: If there is no other comment, we can move to the next presentation. I see no one in the queue.
[01:05:05] Ramon Casellas: Thank you.
[01:05:06] Daniele Ceccarelli: Okay. Thank you. A lot.
[01:05:12] Ramon Casellas: Next is. So, Bin, I think this Yes.
[01:05:38] Bin Ye: Yes. Hi. And so today, I'm going to present the new revision of the young data model for the performance monitoring streaming on command transport with tools, the companion document. The this document has been changed in terms of structure. Okay. History. As you know, this work started a single document in young data model, PM streaming, at c camp years ago almost. And just to be co just as the before those the working group adoption, Paul finished, and so we got the comment from the channel. And he's point out this document contained some genetics PM's requirement out of scope for c camp. Maybe IPPM working group is responsible. And so we had as the online meetings, working group chair and the ADs of the CCAM and the IPPM. It was agreed that the generic part should move to the IPPM working group while the technology specific part remain the CEACAM. Now and so we proposed segment separate into the three document is divide between the CEACAM and IPP working groups. Two for the IPP working group, one for the CEACAM. Okay. The original draft is the mixed two generics of young data model and one technology specific part. And the first two is the generic part of the PM's collection and the inter interbar capabilities that are taken out to move it to the IPPM working group, two separate documents. The PM's parameter part, the remainder is CCAM. Okay. The outline of the discrete document is and the first one is the collections, the measurement for the IPPM standard track. It contained the generics model and the parameter and sampling and street collection type. Second document is about internal capabilities. It document, augmented the first young data model in the previous draft, and it make the server advertised interval capability. So the one is for the CCM working group and PM streaming on the transport. Actually, it's the this part, I think, the some standard track, not informative because it defined some very important is the performance parameter of the three groups. Now it's being updated in the ITT. Okay? And the first documented in detail a little bit, and it addressed the three stage of the PM pipeline. And this draft model the collection part, it processed the the raw performance data created in the sampling stages by the embed open OEM. And then the produced structured performance data, the over the collection interval and delivered to the server, delivered to the client's, you know, as pull or the push based mechanism. And as you know, this draft is the defined three types of the collection collections. Okay. This draft include the three structures of young data model and from the profile to the parameter to the intervals. The left figure showed the hierarchical structures between the sampling interval and the connection interval for the different purposes. And so, for example, error second energy center and network operation center can be monitored this by the count measurement with the one sampling interval over the three different collection time for the different purpose. It showed that one sampling interval can be mapped into the three different collection interval as like as the hierarchical structure. Okay? Does the terminology the terms the three types of collections should be aligned? We did the works of IPPM working groups. The sing snapshot is, for example, correspond to the singleton and counts and the title marks correspond to the statistic of the sum and the min max. And so as a aggregate temporal aggregations are at least sixteen ninety. And, also, this draft is the try to minimize the collection types based on the g dot seven seven ten. It picks the small and the operation or it validate the set and instead of all statistics possible statistics like average and the variance, all statistic are not included in the draft. Right? The reason is that it keeps the and inside the computation is light and heavy analytics to stay in the external system. Okay. Second one is the advertising interval to intervals towards client. It augmented ITAP assistant capability based on our efficient nine one nine six. And then the and there are three reasons to to wide discovery into our capabilities needed because the one single parameter can be monitored this with a different several different type of sampling and collection intervals. In that case, client should know the what kind of interval capability server can support. And based on the information, a client can configure a client can configure this performance parameter. And this draft also defined as the metrics of the interval capabilities. You need min max value and the granularity. Okay? Last one is for the SCCAM work, and and this slide is the showed us some app applicability of the tools, the generating models, some IPPM working group to the transport networks. And by importing import to the tools, the general gang data model. And it also defined as the three groups of performance parameters. For example, and the first groups that can be monitored by the one of the three is the collection types with the fifteen minutes for the maintenance. And that and the third ones, for example, is the can be monitored by only the count measurement, not for the snapshot and type marks. Okay? Then we did a twenty four hours for the QS, for example, and SLA compliance. Okay? This draft is also the describe this the whole procedures of PM streaming. And from the startings, from the discovery of the interval capabilities, server can support based on the information server subscribed target parameters. And then after configured and the servers streamed the performance datas. And then finally, the the trigger report the threshold report is triggered when the monitoring values across the threshold. The on the picture, I'm wondering how does the I like to ask the chairs and the the plan of the working group adoption. It stops and at the last night of the working group call deadline. And so yeah. And comment always welcome. Please refer to the GitHub link. That's all.
[01:16:02] Fatai Zhang: Yeah. Bing, so one minor comment. So to double check, so you just mentioned that that this draft should not be informative. Do you mean this draft also should be
[01:16:11] Bin Ye: a standard check? Yeah. Maybe standard. Right. No. It's actually it's the base on the JITA seven seven ten. Yeah. And and there, we we where the the describe define the some three group of performance parameter. Here's we use make a young data model to support the three group of performance parameter. This kind of parameter is very important to the come to the oldest transport networks. Okay. I agree. And from my perspective, I think it should be a standard check. Yeah. Yeah. Yeah. It should be correct.
[01:16:51] Daniele Ceccarelli: Yeah. When while you were presenting, I checked that if you just said the informative in the slides and the draft was standard attack, but the draft the draft is informational. Yeah. So you needed to update it. Yes.
[01:17:04] Ramon Casellas: We'll also comment the the remainder of the latest one is ongoing. Yes.
[01:17:11] Bin Ye: I should remind this. You know?
[01:17:15] Daniele Ceccarelli: Yes. There is a plan to send the liaison today at UT saying that IPPM is planning to adopt the first two drafts and second with the third. From a second point of view, given that the draft depends on the two others, From a process point of view, we needed to wait for the draft to be adopted in a PPM, and then we can start that adoption in a in Secamp. But that's something that we can immediately after.
[01:17:44] Ramon Casellas: Okay. Yeah.
[01:17:45] Daniele Ceccarelli: So we are monitoring the IPPM mailing list. But in case we miss we miss it, once if if you see that the draft is adopted, just send the ping to the c camp list and say the draft has been adopted. The the drafts have been adopted in PPM. Can we proceed with with the c camp? Just just in case we miss it. Okay. Okay. Dieter? Yeah. Dieter, no Nokia. My apologies for not having followed the discussion why this work is now split across two working groups. Because, I mean, you just mentioned it, Daniel, that now we have a dependency to work, which is carried out by another working group. Maybe you can shed some light on the rationale for this decision to split the work across the two work groups. Actually, this is a decision taken in conjunction between the chairs of CEACamp and FPPM and the directors of CEAccamp and and the PPM. There was the the feeling that this work was going beyond just our domain, the transport networks. So there was the request to make it generic enough to to be applicable to all the technologies and then do the transport specific extensions in. Like, it happened so many times now. So this is this is the rationale, and this is why we now have this dependency. At the same time, the IPPM chairs in agreement with the direct, etcetera, decided and promised to have a prompt adoption of of the draft. So they will go directly with with the adoption without having a long process of social socialization within the working group, etcetera, etcetera. So they will propose for for adoption in immediate.
[01:19:52] Bin Ye: Yes. I used to make a comment about from the technologies perspective. And if we're and after and when I read some documents in the IPPM area related to this one, I cannot find out the exact part of the collection measurement. You know, it's the this part, I think there is a transport point of should be very important. Is that because when the you send the old status data to the system and external system, you should remove the unnecessary performance data. In this process is, you know, I think they did a listing IPP working group. I I don't did the working group as up to now. And so that is why is the I they moved to this IPP working group with the strap. I see.
[01:21:08] Xin Li: Okay. Thank you. Good morning, everyone. This is Xin from CICT. I will present the integration of into ECTN based optical network. This is our third warrant. And since the last ITF meeting, we did several updates, and we redraw the figures three to show how can coexist with existing SATM functions. And we do some refinement to the enhanced CMI or NPI descriptions. And we also clarified the three interaction cases. And there is appendix a ended to describe the non normative MCP based capability in location example. And okay. Let's start from the figure three. And this figure described how and let me phase into MDSC and the PNC interaction. So when we look at the interaction between MDSC and the PNC, they have extended the NPI to be the unified communication channel. And there will be logical agent to agent communication between the MDSC agent and the PNC agent. So in the PNC, the PNC agents can reuse existing controller functions through some internal API or through some tool in location. And here, I list the one to one relationship between agent and the ACT and NDI model. Like, if we implement the service assurance agent, then we can invoke the ACT and SLA assurance model. And if we do the for the handling agent, then we can reuse the ACT and incident model. So that's the relationship. And in this page, we want to describe the three interlayer deployment cases and the interface needs for for three cases. The first case is both the MDSC and the P and C have NMAs. So in this case, there will be the logical agent to agent interaction between MDSC and the P and C. So we need agent level is changes. And the case two is when the upper MDSC has no NMA, but lower has NMA. So in this case, the PNC need to expose the agent capability on PNC to the upper MDSC. So in this case, we may need some agent capabilities, and some kind of interface. And the case three is the upper MDSC has NMA, but lower has no NMA. So in this case, the lower layer P and C actually can remain unchanged, and the MDA, SC, and then they can just invoke the P and C by using the ACT and CMI MPI. So that's the three different cases. So for the three different cases, we provide some example implementation. They are just for illustration, but not mandatory. So for the case one and case three, we may use some MCP based capability or unocation. I I listed two patterns here. The only difference is where we put the MCP server on. We can put the MCP server in the MDSC or put the MCP server in the P and C. So they can they both can can support the MCP the the PNC capabilities for and the invocation. So the other example is for case two. Case two means there is no agent on the MDLC, but PNC has agents. So in this case, we can use some interface like a two u young model we define in in we are trying to define a. So in this case, the enhanced MPI can reuse the a two u young model to expose P and C capabilities, and we can carry the domain specific contents in the constraints part. So here gives a example. And okay. I think that's all for this Warren. And maybe next step depends on the timeline, the the progress of the draft. So my question is, how's the suitable timeline for this draft in CEACamp? So should we wait for the progress of that draft, or or can we move forward? So okay. Thank you.
[01:26:26] Haomian Zheng: Okay. As a contributor. So, basically, we this work has been integrated for a few times, and I believe it's self contained from CCAM perspective. However, it would always be useful if we align with the generic framework, which is still unstable at this moment in ITF. So a reasonable way forward would be we can agree somehow agree on working on this first. And we're always keeping in mind that we will watch what would be the generic framework or guidelines in the I don't know which group or which organized who will who will manage this, we will try to keep an eye on alignment with that to after maybe working group adoption.
[01:27:21] Daniele Ceccarelli: What what what do you mean with generically agree to work on this? Is there another way other than the working group adoption? Yes. Yes. It was do you suggest Yeah.
[01:27:40] Haomian Zheng: Will support as an individual first consider starting off the working group adoption. Put it in the queue would be helpful.
[01:27:50] Daniele Ceccarelli: Put it in the queue, I don't see any I mean, in our priority list, I don't see any issue with that. The working group adoption, I'm afraid that here I mean, I would be more than happy to to do that because, I mean, I'm one of the authors of the NMA work, but the NMA work is not something that we can reference, unfortunately. So, again, I I don't see any issue in putting it in our priority list and then move forward once the NMA becomes an ITF work because today, unfortunately, it's not an ITF work.
[01:28:33] Haomian Zheng: Yeah. My my point is this work would be needed for CCAM sooner or later. So
[01:28:38] Daniele Ceccarelli: I don't disagree with that. It is we need that to the to define sooner. Christian?
[01:28:50] Christian Schmutzer: Hi. Christian Dikoff. I when I looked at the draft, I got the impression that it is formalizing something that just that does not need to be, like, formalized because we already have that. So once like, stripping away the term agent from the draft, in the end, it's like you have a request. You get a request ID, and it's a formalized process that we already have with the NetComp routines and all that stuff that there is. So it's basically, like, we're doing the same thing we already have just the second time with another terminology in it. So, yeah, I yeah. Adding up the comment that I have not yet got the benefit of that draft to the existing routines that there are.
[01:29:35] Xin Li: Okay. Thank you. So may I ask what what work you are referring to? You mean the existing work? Is there any terminology similar to the NMA?
[01:29:50] Christian Schmutzer: It's far away from NMA. It's, like, basically looking at the basic way we are implementing, like, interaction with using NetConf and related protocols and based on young models and stuff. It's basically that if you're stripping away the term agent and then look at what we already have, it's no different than a user interacting with existing infrastructure. So that was the point where I was not really able to catch the the improvement that it's bringing.
[01:30:28] Xin Li: Okay. Thank you. I'll talk to you later. Thank you.
[01:30:31] Daniele Ceccarelli: Okay. If I mean, if you can take this discussion on the mailing list, it would be great so that also we have the possibility to understand what what what is missing and what the draft is trying to cover.
[01:30:46] Xin Li: Okay. Sure. Thank you.
[01:30:48] Henry Yu: I I raised my hand. I like to comment on the previous comments because I'm one of the authors to this draft as well. ACTN,
[01:30:57] Jonas Allberg: as
[01:30:57] Henry Yu: we know, yeah, it's quite self contained and quite mature standards. This draft is trying to complement ACTN using AI agents. What to standardize may maybe is two things. First is how AI agents, right, can be used to extend ACTN functionalities, especially in the service assurance area, right, which is lacking of the functionality defined by ECTN. Secondly, equally important is how agents are managed. So if we have agents running in our system, the management side need to be standardized. K. These are my two comments. I
[01:31:40] Daniele Ceccarelli: speaking as a contributor, I fully agree that the agent management is something that needs to be standardized, but I don't think that's that's a SCCAM thing. So I I I completely agree with you, but that's not something that we do in in CEACAM. So if we wanted to describe that in a CEACAM document and how it applies to to all the technology we deal with, that's perfectly fine. But if that's the core content of the draft, it's a little bit weak. This is a little bit the the the the problem that I'm trying to to explain. If there are other, I don't know, mechanisms, interfaces, extensions that are needed to operate transport networks using using AI, the the this is what you should focus on in the in the document, in my opinion.
[01:32:46] Xin Li: Yes. We are focusing on the interfaces.
[01:32:50] Ramon Casellas: Okay. Thank you. Can open it, please?
[01:33:02] Henry Yu: Hello. I'm Henry Yu from Huawei. I'm presenting on behalf of all the authors on a new draft that we just contributed for a young model a define a new young model for SLA assurance.
[01:33:20] Ramon Casellas: Okay.
[01:33:26] Henry Yu: Motivation. What is this draft about and why we introduced this new draft? It's it's about this draft is about the SLA assurance management in the optical networks. SLA assurance management concerns with the monitoring analysis and the management that that the net management of the network conditions that may impact the performance of the existing services. Okay? The objective for the assurance management is to detect potential issues proactively to prevent SLA violation. So so the prevention is the key. And following that, the the the key concept is what's called issues. This if we identify issues before issues become problems that violates SLA assurance, then we we we met an objective. So this draft defines a young model that provides a standardized way to define, detect, and report issues, which I will explain later the definition of what issue. Okay. So oops. I always do not know the the right left direction. Okay. Anyhow, so use cases. So is is there use cases for this problem that we define? We believe yes, and we listed the three typical use cases for service assurance in the optical network area. And as we know that the optical networks are are are indeterministic in nature, and it's very applicable to services such as, like, a mission critical and carrier grade services. These services need ensure a near zero interoperability of the service delivery. So the the the draft is about to detect issues that may violate the the the the interoperability of of the existing mission critical services. And another two examples are are deterministic latency services. So we want to identify the issues that may break the the the guarantee of of the deterministic latency jitter and and and packet loss for for for the services such such as AI distributed training, which are very sensitive on the latency. And then the the the the third category is dynamic bandwidth allocation. So we that is mainly for the the the AI training workloads services or distributed computing, etcetera. So these are the use cases that that that that that the draft the young model try to address. Okay. See. So what is issue that we we want to define? We the SLA issue is a network condition that if not addressed in time, may lead to SLA violation. So once a issue become a problem, which is incident, then it's too late. So, basically, that's the the the the key one of the key differences between issue and the incident. And there are two type of issues. One issue is a symptomatic. So these issues may cause the the impact to the to the health of services, but it's not violated at the SLA yet. So that's the difference between as a violation and the the the visible impact that may not validate the the the service. But there's another type of issues that's opt often seen in the optical networks, but but it's more difficult to to to to deal with, which is asymptomatic issues. So these kind of issues does not impact the service at all until, right, another condition jump in that such as a reroute of a service, then you will see all the latency is different that after the a new walk. This so these are the so called asymmetrical issues. Fortunately, the type of issues are limited, so there's not, like, unlimited number of issues. So this draft try to quantify the the issue classification. Does that another contribution this young model want to want to make is to to identify the issues, all the issues that that that may impact the service assurance. And this is the issue management workflow. So it's it's basically the the the key here is is so called issue server. So that that server basically would the objective is to generate the the the the the young model issue and report it back to the OSS. So the the the the the the OSS or it can be viewed as a as a client that consume the the the issues that identified by the issue server. Right? This is the first iteration of our YARM model. It basically, this is two parts. One, it define what issue is as a as a data model, and another part is the the remote procedure calls that defines the operations. But I I I noted in on the slides that it's still working in progress, so we need to define more operations on the issue management. And lastly, what's the next step is basically this is the first edition of the of the draft. So we request our community, the the the WG members to review and comments and discuss and contribute. Thanks.
[01:39:33] Presenter: Questions?
[01:39:43] Speaker 16: Daniel King. Hi, Henry. Thanks for this. It's looks like a really interesting piece of work. So, yeah, you might be aware that in TEAS, we've got this sort of ACT and POI applicability document and now service assurance documents as well. Right. We have in the service assurance document, we have tried to kinda reference some of the tools and building blocks that we can use from c camp. Even, obviously, it's a TEAS document. And I've just kind of scanned through the document. I haven't read read it. I guess it's 00. Yeah. 000. Yeah. Okay. So I'll look through that now, but I I think it's if you could look through our TEAS document and see where this piece of work kind of fits in, if if it's something we should reference. I mean, generally, we'd we don't like to reference anything that's not a working group document already. But if it's if it's something that you think is an informative reference for RT's document, yeah, we can absolutely
[01:40:38] Henry Yu: take it. Perfect. Thanks for the comment there. Yeah. I will look into it.
[01:40:44] Daniele Ceccarelli: Alright. Just love thinking. I was wondering if this goes beyond the t because issues could have relationship with the t or not. But I'm not aware of any work other than the work done in in this. So the the question would be, is is there any other work that has a wider scope than the traffic engineering? Are you aware of it or not? Maybe knows the answer.
[01:41:19] Haomian Zheng: Yeah. I I think we have two options on the table at this moment. Firstly, is make it generic in into TEE, and that would be a larger scope than our working group. So second way or maybe more realistic is we can restrict or we cannot restrict. We can focus on how to deal with SRA assurance in layer one network, layer zero network so that it perfectly fits here.
[01:41:48] Daniele Ceccarelli: I think both options are are valuable. Yep. Pick one.
[01:42:01] Christian Schmutzer: Christian. Yes. So I'm actually working on a quite similar topic, which is not regarding the incidents itself, which is more about, like, scheduled maintenance causing incidents and stuff. And I've been asking my question if this is really, like, something fitting to the the focus of CEACAMP in that way because it it it's more of it is an operational question. And, also, I see in that draft a lot of similarities, for example, from other standards that are out there like the Amplify 175, for example, which specify very similar attributes but in a slightly different way. So it might be worth looking at the other stuff that is already out there from, like, other perspectives that we're not ending up with, like, in the end, three specified ways of almost the same but having things slightly different. That's just
[01:42:57] Henry Yu: Right. Thanks, yeah, for the comments.
[01:43:02] Ramon Casellas: Thank you. Thank you.
[01:43:08] Daniele Ceccarelli: We have a we are a little bit late. Have seventeen minutes and two presentations to go.
[01:43:25] Yan Xia: Hello, everyone. This is Yan Xia from China Unicom. I'm presenting OSPFTE extensions for computing capability advertisement draft on behalf of our authors. It's a new draft. The authors are from China Unicom and UPT. I'd like to present the motivations. First is why is computing capability information needed? Optical networks are unaware of computing capability, which may lead to the selection of AIDCs with insufficient computing resource. And the worst of many is to run mismatch between the static communication bandwidth and the dynamic computing demands. So why we use OSPFTE to carry computing capability information? Cost JNPR's ASAN optical networks already used in OSPF TE to distribute the TE information. So we we use the or pack or ISA floating weights in the OSPF error instead of propose another protocol. If OSPFeet as distributed advertisement, the machine for selected AIDC metrics, it leads to two questions. The first is what kind of information should be considered? I think the information should be scoped, obstructed, and operator control. It's not a full computer inventory, and selected metrics should be relevant to the placements and past computation. So how should OSPF be extended? The authors made a minimal extension, and it's the use of the normal OSPF t floating, await the changes to packet types, adjacency, and the database exchange. It defines a dedicated computing capability or pack as a for selected AIDC metrics through the top left and left TROs with way it's clear processing and the validation rules. Next slide introduce the scope of this work. In scope is OSP of TE advertisement or selected the ADC computer metrics, Teptan, OPEC, LSA, and the TRV, sub TRV encoding, and the distribution ways in OSP of TE project domain. Autoscope is how an AI display interactively collects GPU memory, storage, and the task related information. And a specific path selection algorithm or orchestration policy in the Verso auto scope. And so what our draft propose? We introduce the computing capability, opaque LSA, by defining a new opaque type. Low opaque ID is 12. It's used the standard OSPF or LSA header with the LSA type 10 to floating within area. The playlouds include three in top left TRE, GPU basic information TRE, GPU performance theory, and the globe computer performance theory. First is GPU basic information theory. It's describe the static or slowly changing GPU type of properties, Separating the slowly changing information from the dynamic information helps reduce the possible updates. The app helps reduce the unnecessary updates. The the the the for a fixed the fixed field that continues the AIDC ID, gateway ID, and the client side port ID. And this field is built to the computer information computer information to the corresponding AIDC and the optical network optical port. The other attribute is carried in the GPU attribute or sub DOAs. The GPU attribute to sub DOA in contains the four groups. The first group is related to the hardware in if you include the GPU vendors and the GPU model. The second group is the network related metrics that it include the link layer protocol or transport protocol. The third group is software related metrics. It includes the operating system, GPU 12 version, GPU compute computing framework, GPU collective communication library. We work on feedbacks on whether these metrics is appropriate to advertisement. The second top left is AI DC GPU performance tier. Right? It describe dynamic GPU and associated NIC states. It include the GPU memory capacity and bandwidth of GPU associated NIC, GPU utilization, GPU NIC states. The third top level TRA is AIDC Globe compute performance TRA. It's described as the AIDC label memory storage and the summaries. We're looking to merge the two top left for sub tier related to the in the last division. The next is origination and processing. Origination can be triggered by adjacent four states, add this exchange, and the source change. So it's called across the crossing, provide refresh, or local policy. And the servers use normal opaque LSA floating processing and the flow the acceptor LSA by type 10 rules. Unknown and the are ignored. The from my former, the field are valid and the.
[01:50:44] Daniele Ceccarelli: I'm I'm sorry to interrupt you. You have one minute, and we have three people in the queue. Maybe you wanted to take the discussion Okay. The questions.
[01:50:53] Haomian Zheng: Oh.
[01:50:53] Daniele Ceccarelli: Okay. Cool. You are we are at the next step. Perfect. Okay. Just wrap up, and then we can move forward with questions.
[01:51:00] Xin Li: Okay. Thank you.
[01:51:03] Fatai Zhang: Okay. Questions. Yeah.
[01:51:05] Daniele Ceccarelli: Perfect. So first of all, thanks a lot for a no SPFT draft. I was missing it. I had enough of young. Second, I'm happy to see Adriana to the mic because I was about to to call him and Oscar. So I understand that this is something that is applicable to optical networks, but the type of information that you are advertising, it's something that, in my opinion, belongs to Katz. But I'm not sure cuts as the authority to define OSPFTE extensions, which falls into TEAS scope. So I would say that this is a mix of cuts and TEAS, but for sure not sick camp.
[01:51:53] Adrian Farrel: Hello. I'm Adrian Fowl. I'm one of the chairs of the cats working group. I think you're looking at an interesting problem and you're looking at an interesting potential way of solving it. As Daniele says, you you're you're very unlucky. You have fallen in the crack between three or four working groups because there's Ts, LSR, Cccamp, cats. I would suggest that your starting point is to go and read the cats documents and understand their work on compute capabilities and compute metrics.
[01:52:37] Xin Li: Yes.
[01:52:39] Adrian Farrel: And then see, well, how are your proposed metrics different from their proposed metrics? Should you be giving them advice about changing their metrics? Should you be learning from their work and putting that into your draft?
[01:52:57] Yan Xia: Okay.
[01:52:58] Daniele Ceccarelli: And then once you have a good grasp on the metrics, the way that you are advertising them seems to be the right way. But maybe that's something that falls into into this maybe or r s l LSR.
[01:53:14] Yan Xia: Okay. Okay. Done.
[01:53:16] Donald Fedyk: Hi, Don Fetek. Just your point there, discuss whether selector metrics are appropriate for OSP FTE. I
[01:53:25] Presenter: think
[01:53:25] Donald Fedyk: you could look at the things that you're advertising and just describe the frequency and the distribution of where they're needed to make those kinds of decisions. Because on the whole, there's a lot of things that I would say don't belong in there. And the question is, like, do some of them? Maybe. But where else could you go? Like, you're asking the question, there's OSPFTE, but what else could there be?
[01:53:57] Yan Xia: What else could there be? I think we can discuss this question on the mailing list.
[01:54:05] Daniele Ceccarelli: That is great. Yes. Yes. Thank you. Thanks a lot.
[01:54:25] Jun: Hello, everyone. I'm Jung from UPT. After IETf-one hundred twenty five, we substantial substantially restructured the of both ONC drafts. The boundary is not clear. We reuse ACTN for for transport control and add only the computer computer functions needed for joint lifecycle coordination. We have three new author join joining us. I will be getting I I will begin with the the new name and the user cases define a narrow scope. The rest of this presentation focuses on the the other two changes, an ACTN based architecture that supports centralized and distributed deployments and the lifes lifecycle workflows for both deployed deployments. Before showing the architecture, let's first identify the gap. And computer scheduler knows the GPU availability, but but not whether the optical resources are ready. And an optical controller knows the net network topology and variable path, but not whether computer resources are ready. What's missing is what's missing is joint life joint life cycle coordination between across the two domains. Once you fill this gap before traffic starts. For op for optical side, the ACTN have the ACTN already provides the transport control foundation we need. It covers service expression, abstraction, and multi domain coordination, and transport motoring and provisioning. ONCO retains the ACTN controlled structure and reuses the optical MPI and the PNC as it. We focus only on the missing compute control and joint decision making functions. So ONCO had three capabilities. First, abstract compute state. Second, reserve and log compute resources. Second third, select compute placement together with a deterministic connectivity. This these are functional extensions, not a replacement for ACTN. The next slide where maps this capability to ACTN and and shows a boundary and shows a mini num boundary. The ASR design has the CNC because it carries a compute and an optical intent. So AGI, it's therefore enhanced to CMI. So joint optical computer orchestrator is enhanced to MDSC because it keeps ACTN's translation, abstraction, and the coordination role, but coordinates computer domain in addition to optical domain. The optical MPI and the PLC remain unchanged. The the only new bound the only new source bound on the branch, it's or consists of JCI and the CPC. This branch exposes compute state and control resolution or locking and release. This map here is clear in the centralized architecture. The ACT hierarchy remain remain visible. The ASOs and the AI service intent to through AGI. Translate it into into demand and and obtain the optical optical status through MPI and and the com computer status through DCI. Then selects endpoint endpoints and deterministic connectivity. So the the service starts only after compute and optical's results are ready. The same function can also be placed closer to the edge. The only only translates the AI service intent and relates the demand to local CPC. Local CPC reports its compute compute status through OCGW deployed to deployed at the edge of ADC. And OCGWs OCGW translated the demand into attributes that can be distributed by the optical control plane. The same the same the same distributed chain can also handle the the adjustment pass the recovery and the results release. Any comments on both drafts are welcome on the. Thank you.
[02:00:44] Daniele Ceccarelli: Thank you. Thanks a lot.
[02:00:46] Haomian Zheng: Yeah. How many how many I'm trying to be brief. And this work these two works together with the previous presentation shows a signal that the CCM or ACTN O and people are starting evaluate the its usage in the computational aware scenario. And but we are having a quite different protocol stack running compared with switches or or routers. So we need better mutual understanding on each other, but this is a good starting point so we can kick off the work.
[02:01:24] Daniele Ceccarelli: Yes. No. I agree with that. There is I mean, while the previous document was something that was, as I can said, falling into the cracks of different working groups, I see this one more optical optical transport and network specific. So I see I see no issue from that point of view. And thank you for the for the work mapping the ONCEO parameters, architectural components, and the CTN components. That was very clear. I mean, that's one of the feedbacks that you were asking for from the working group. And from my point of view, that was clear. Thank you.
[02:02:07] Oscar Gonzalez de Dios: Thank you.
[02:02:13] Daniele Ceccarelli: Late as usual, but we made it. Thanks, everyone. See you in San Francisco. Maybe.
[02:02:24] Ramon Casellas: It'll be. We are welcome.
[02:02:27] Daniele Ceccarelli: If you're a little harder to come.