**Session Date/Time:** 16 Mar 2026 03:30

**Chair 1:** We are asking that because we have a remote presenter who is not yet connected. In case he doesn't connect, we could anticipate one presentation from tomorrow and move it to today.

**Chair 1:** Yeah, yeah. I wanted to keep you tomorrow because tomorrow is super packed and you are very fast. That's the reason why you stayed tomorrow.

**Chair 1:** Any other volunteer?

**Chair 1:** That's strange, Ito.

**Chair 1:** Okay. Let's start. So, yeah, thank you. Good morning, everyone. So, welcome to CCAMP session and also welcome to Shenzhen, China, a young, beautiful city. And, you know, I really hope that you all will enjoy your trip in Shenzhen because I'm a local co-chair. So if you have any questions about Chinese food or shopping, please talk to me. I'm happy to help. Because, you know, in Shenzhen, we have very, very cheap but high-quality electronic products in Huaqiangbei, which is not far away from here, less than 5 kilometers. You can just take Metro to be there. I think it's a good place for you guys to buy something there. I'm not advertising for Shenzhen, yeah. It's up to you, yeah. Okay. Back to the meeting. Yeah. Let's sorry. 

Let's start from the Note Well. I think this is some information, you know, about the manners, about, you know, IPR policies. I think you all are familiar with the IPR policies, otherwise please, you know, read some, you know, documents mentioned in this page. 

For the meeting tips, I think you know, this session is being recorded, you know, as always, not because it's in China we record this meeting. So, for the in-person participants, please make sure that you sign into the session using the Meetecho Lite client and also use the Meetecho to join the mic queue. And for the remote participants, you know, please make sure that your audio and video are off when you are not speaking. 

And, you know, there are some link information about Meetecho and I think you know how to use the tool. 

And then for the minute takers, I think if anyone, you know, could help the chairs to capture some minutes, that would be much appreciated. And for the blue sheets, nothing to do. Yeah. And there's a reminder on the IPR process as always. Yeah. So we always, you know, ask the contributor or authors of the draft to respond to the IPR polling as soon as possible, otherwise it will delay your draft to move forward. 

So this time we have two sessions, one hour per session. So this is the first session and you know, for this session actually we mainly focus on the working group drafts and for the second session we mainly focus on the individual drafts or new drafts or some new ideas. Yeah. It's fine. Thank you. 

I will cover this part, which is a review or overview of the status of the work in the working group. So the first point to cover is this chart that we also presented in Montreal with the dependency of some of our work with other work in, mostly in TEAS. So I would like to call Haomian to explain this, please.

**Haomian Han:** Haomian, Huawei. Thank you. Yeah, actually we first created this diagram in Madrid and we updated this, and unfortunately we didn't move any document, remove any document from this slide, but we only increased the number of dates. But it doesn't mean we are doing nothing, but we actually see the key blocking point, TE Types, is now submitted into IESG and I believe there would be some good output soon to unblock the rest of the document. Thank you.

**Chair 2:** Moving forward regarding the last call process, we have, well in the Wiki you have documented what is the process that we do for prioritizing the different drafts. So we have a number of them. We usually identify three for both working group adoption and working group last call adoption. So now we started to run the adoption of the draft from Bin that will be presented later on and we run the IPR poll and the next will be the adoption itself. And we have, as the priority the first priority after that, the Client PM YANG, so the PM streaming is on the way, and second will be the PM YANG. For working group last call, we have, well, the Flexi-Grid YANG model is ready, so will be, I don't remember if we started as well or will be soon to have been started as well the working group last call. And then the Interface Parameter YANG is the one in the queue. 

So regarding document status, there was no recent RFCs from Montreal till now. There are a number of documents in RFC Editor queue. There are some MissRef due to the dependencies as well for the RFC 9383 Layer 1 Types, Layer 1 CSM and OTN Topo. And the IESG is processing now the [draft-ietf-ccamp-optical-path-computation-yang](https://datatracker.ietf.org/doc/draft-ietf-ccamp-optical-path-computation-yang) document as well. So Kethan is in the queue, so Kethan, do you want to comment?

**Kethan:** Ah, yes. I just wanted to update that the optical impairment has been approved by the IESG. It was just waiting for some last bit of follow up. But as of now, it's, the approval will come out. Secretariat is busy and it will go to RFC Editor queue. Thank you, everyone, for that long and lot of work that got done. Thank you.

**Chair 2:** Thank you. So there are a number of working group documents in the agenda. We will cover them in this session. Uh, for the status of the rest of the working group documents that are not presented today, we have updated the status for those that have reported that in the Wiki. So you can go there in the Wiki directly and check the status. We will do this regularly so that the fresh information is in the Wiki accessible for everyone. 

So regarding liaisons, we received a number of them between Montreal and now. We have this liaison statement on information modeling and data modeling coordination, from ITU-T if I don't remember wrongly, and there will be a meeting of SG15 on that and Deborah and Scott will coordinate the response with TEAS for this. 

The last point to cover is the charter update. The IESG is deciding on the working group charter update. It's scheduled the telechat meeting for beginning April. All the comments have been collected so far, so the fresh, let's say, reading of the charter is available, well, in the GitHub. We have not put here the link. I will put later on in the chat so you can access directly to it and you can basically go through that. And with this, I think we can start with the first presentation. I will share the slides. 

Just one note. We have two sessions super packed. Try to make the best usage of your time. I know you are eager to present the, to present your work, to present your slides, but if you manage to save some time for discussion, that's a much more useful way of our face-to-face time.

**Chair 2:** So Gabriele, do you want to present? Is Gabriele here? I cannot see Gabriele. Or who is the presenter? Ah, okay, I will pass him as a presenter. Perfect. Gabriele, you have the slide control. You can start. Gabriele, are you there? I see you in the queue, but we can't hear you. Maybe we can move to the next presentation while Gabriele tries to recover the audio. The next one is Nigel and I don't see him online. It's going to be a quick session. Sergi is in the queue? No. Let's go for the third slot then. Aiguo? Oh, we have it! Who's here? Yeah, yeah. That sounds like a very quick session. 

Okay. So, this is for an update on the YANG data model for WDM tunnel. So, a brief update. So we don't have any YANG model and text update since the last revision because we're also, we're still having an ongoing discussion and on the technical aspect of modeling the 3R regenerator scenarios. So we have still going through some scenarios, we're still living additional scenarios to be discussed. And the main point is to identify all those key scenarios and whether there's any edge cases that we could, you know, edge cases and proprietary use cases that could be left out for standardization. 

So, yes, so here we picked some typical regenerator scenarios that we have considered. The first one on the top is the basically a single wavelength 100G Ethernet over a single OTSI with a regenerator in the middle. And there we consider the type of digital termination, the chain of digital termination at the source destination, which needs to be matched. And then there are different options for the regeneration layers. 

And so those scenarios marked as to be discussed, we still need to go through that. So the second one is the ODU4 tunnel segment over a single OTSI with 3R regens. And, yeah, scenario three and four are still to be discussed, which involves an ODUC4 service over single OTSI and also an OTN OTSI service. So each of them will have different type of regenerator layer configuration as well as the digital termination at the source destination and at the regenerator nodes. 

Okay. So, yeah, this will become more complicated. We are considering like 400G service, Ethernet service, or a 4 by 100G multiplexing service over a single, either a single or multiple OTSI, which goes through the same regenerator via a single regenerator group or multiple regenerator groups. 

Okay. So what we have identified so far is we need to develop some YANG entities for the definition of regeneration layers and also the type definition and also as well as the sequence of digital termination that's to be characterized on the source and destination that which needs to be matched against the regen nodes and then also the type of inverse multiplexing that needs to be defined as well. 

So the next step of this draft is we are will need to complete the review of all the regenerator scenarios to be covered by the standardization and also improve the text by adding descriptions about those regen scenarios and also improve the text on the tunnel provisioning process and also as suggested by the previous discussion to add some diagram to illustrate the relationship between this model and other ongoing working group documents like optical impairment topology, which has come to an end for IESG and publication, as well as the 9383 bis. And then also there's a companion document for optical path computation, which needs to be aligned with with the modeling of this draft once it is done. So on the YANG model end, we're to define those definitions according to the gap analysis. And also there are a few routing area directorate YANG document review comments which still left to be resolved, which is being tracked by GitHub issues. And then also some further enhancement on the definition of the RPCs and then additional work in WDM path computation and also on the pluggable management control document, which can introduction the additional additional gaps that needs to be addressed by other documents including this one as well. 

Yeah, so that's pretty much it for an update. So we will, as we said, authors will continue to discuss this document over weekly calls and then we will publish an update. Questions? Okay. 

**Chair 1:** So we will move to your next presentation and then we will go back to Gabriele and Roberto if we got the confirmation from Roberto if Gabriele's connection doesn't come back, Roberto will do the presentation. Sounds good, yeah, save me a trip. 

Okay, so yeah, this is an also an update on the framework for OTN slicing. So we have skipped a few updates on the last couple of IETF sessions and this time we have present some updates after a review among the the authors and with the working group. 

So what we have updated for this update this version is we addressed some review comments as tracked by the issues, which has been long due for an update. And then also we have adopted and aligned the concept of the NRP with respect to OTN slicing. Basically we have defined the process for OTN NRP realization based by using direct marking on the native OTN TE topology and rather than creating, allowing, requiring to create abstract topology on top of the native OTN topologies. So this will help remove the need for an extra layer of topology and then, yeah, and simplify the process for NRP realization. And with that then we have also updated the example figure that's in the in the document which previously shows two layers of topologies and now being reduced to just one layer of topology but then we also added up the marking of the NRP onto the associated TE links associated with different OTN slices. 

And then we have also done some editorial improvements to the text. Okay, so the YANG model updates, like said, in order to align this with the NRP concept, we have changed the renamed the what we call the slice ID as NRP-ID because the well, actually for the MPI model which is southbound to the to the controller and this is actually used for NRP realization and not not necessarily for slice configuration at the MPI. So yeah, as as you see on the right side, the the red box shows the changes in the model. And then also because because we choose to do the marking of NRP identifier directly on the native topology with the TE links, so we don't need to specify the link reference for each of the each of the slices. And then we removed because of that, we removed the slice link reference from the MPI model. 

Okay. So we still have a couple of open issues. Basically, before before, while we are making the changes for this version, there's also a recently adopted working group documents on the composite slice in TEAS, which proposed the solution for the realization of multi-domain network slices as well as for hierarchical network slices. We believe that so we're trying to evaluate what's the impact of this model against the OTN slicing. And at this point, it seems to to us that it's not clear whether the scenarios described in the composite network slice is is actually for hierarchical network slice or for for hierarchical NRP because it's whether it's talking about realization or it's talking about the actual network slice. So for the current solution that we have with the OTN slicing, it supports multi-domain NRP as well as hierarchical network slicing. However, the case for hierarchical NRP is currently not supported because we don't we don't deal with this hierarchical NRP at this point. So basically, we need some further discussion with the authors of the composite slice to decide if we need to support the hierarchical slicing also for OTN slicing. And fortunately, one of the co-authors of OTN slicing is also a co-author of the composite slice. So we need to carry out the discussion later on. 

I see Adrian raised hand. 

**Adrian Farrel:** Adrian Farrel. Um, yeah, I I think you've got it exactly right. I don't even begin to understand what a hierarchical NRP is. I mean, I understand hierarchical virtual networks, but in each network you're operating as a network and the NRP is just a partition of that network. A slice is kind of like an end-to-end service and then when you go hierarchical, you're doing a sort of aggregation or carrier's carrier type thing, which is more of a concept even then than than a thing. 

**Aiguo:** Okay, yeah, that sounds like sounds like right. And and as we said, we need to discuss with the author to determine if that would be the case and then we can clarify. 

Okay, so the next step is to address those open issues and then we'll continue with the draft review process which we have already started and and some changes have been made. And with that, we believe that once we have resolved the the issues and completed the review process, I think the draft is ready for working group last call. So as said, we have the GitHub repository and we meet bi-weekly on Thursday, so you are more than welcome to join the discussion and complete help us complete the document. Yeah, that's it. Questions or comments? 

**Chair 1:** There is a comment from Kethan on on the chat, which is exactly the one I was willing to make, which is the hierarchical NRP topic is is something that is related to this document but is a discussion to have in in TEAS where the NRP is defined. 

Another comment is about the creation of the new working group ONSON, which was formerly known as ONIONS. Tomorrow, if I'm not mistaken, there will be a BoF. So if the working group is created, this is one of the candidate documents to move to ONSON because that's among the things that ONSON will cover, we have abstraction and net-slicing has been identified as one of the topics that fit fit there. So before moving to the working group last call, we need to understand if if the working group is created and if this is the document to move there. 

**Aiguo:** Okay, I think it's also good to understand the scope of the new working group because we have also the technology-specific part which belongs to CCAMP. 

**Chair 1:** Exactly. It could also be that we need to split the document. Adrian? 

**Adrian Farrel:** Adrian Farrel. No. Yes. Look, if the working group has got a piece of work that's ready to go to RFC, let's not wait on the possible creation of a future working group that might adopt a TEAS document that might then cause this document to be adopted. You know, we've got work, it's finished, we move forward. 

**Chair 1:** In any case we have dependencies on the TEAS document. That's sure. 

**Adrian Farrel:** But you know, when we're done, we're done. We're not waiting for other stuff that may never happen. 

**Chair 1:** Okay. Kethan? 

**Kethan:** Yeah, so just on the ONSON part, there has been discussion about this, and let me say that these things will be worked out if and when the working group gets formed. There is no dictate or a mandate that work be moved that is already in progress or is sufficiently advanced. Those are coordination things which will work out. So, just wanted to clarify there from the discussions that we've had within the IESG. 

**Haomian Han:** Haomian from Huawei. Yeah, actually I talk with some ONSON guys and that was previous ONIONS group and they focus a lot of data model abstraction, but mainly on the packet technologies, that's what I heard so far. We need to recheck the charter but this given this work is focus on OTN slicing, I believe there should not be any dependency on that. And I'm not in favor of creating complicated dependency anymore. Thank you. 

**Chair 1:** Yeah, I mean it's good to have this discussion but we have to wait for for the working group either to be formed or not and the final version of the charter to understand what will be there or not. 

So, we are ready to try again with Gabriele for the first slot. Thank you. I saved some minutes, right? 

**Chair 1:** Gabriele, you are in the queue. You are allowed to share audio, video. No, it seems it doesn't work. So Roberto in the meanwhile volunteered to give the presentation on Gabriele's behalf. Let's see if your connection works, Roberto. Same problem. It seems that they can hear us but we cannot hear them. I open the mic and camera but I end in the queue. Okay. Try now, Roberto. 

**Roberto:** Trying again. Oh, now it seems better. Can you hear me? Yes. Roberto, yes. Yes, I can hear you anymore. No, no, I can hear you. Okay, fine then. Okay, let's see the video. You should have now the control, Roberto. 

**Roberto:** Okay. Can you hear and see me? I can start? 

**Chair 1:** Yes, please. 

**Roberto:** Okay, okay, good, good. Thank you. We finally managed to get connected. So I'm Roberto Manzotti and presenting this draft for the management of configurable DWDM optical interface on behalf of the other authors. The draft should be now pretty mature. We already presented this slide with all the draft relationship with other RFC and work in progress in CCAMP. I will skip quickly this slide, we are just keeping it for reference. Let's move quickly to the update on what has been done since IETF 124. We are now at the point of completing the RTG directorate review. We addressed the last issue open from the YANG doctor review and basically we close the pending issue but due to some time constraint for presenting the slide here and we didn't fit to fix everything and we have a pair of leftover that now are tracked by two new smaller issues that are tracking the last change pending. 

With me go to the next slide. More in detail what has been done on the YANG model. We had one main issue that was a leafref rewritten leafref that was pointing to a read-only leaf that has been fixed following the YANG doctor review suggestion to use require-instance false since we need this read-write leafref for the configuration of the operational mode of the interface. We standardized the YANG formatting as suggested by the RTG directorate, improved the description of the TCA definition and also added the must statement to avoid that raise and clear threshold can become identical. And there are other minor fix and clean up all over the model. 

For what concerns the document, all the nits and suggestion from the RTG directorate review has been fixed and we also added an appendix to better explain the behavior of threshold crossing in the model and added also the YANG prefix table that was missing before in the document. And more or less this is all. So what we have as next step is to address the latest two issues that we have still pending and then go for the WG Last Call. Any any question? 

**Chair 1:** I have a question, Roberto. Relationship with the [draft-ietf-ccamp-actn-wdm-pluggable-modelling](https://datatracker.ietf.org/doc/draft-ietf-ccamp-actn-wdm-pluggable-modelling) model, the pluggable's model. So do you think that we can move this work forward and then the pluggable's work can adapt to it, or do you think that there could be impacts on this document deriving from the pluggable's work? Because I don't want to risk to go for a bis immediately after the publication. 

**Roberto:** Yes, we so for what concern the attribute to use for the configuration and monitoring, I think that we are pretty close between this work and the pluggable work. There are a few more attribute that has been identified in the pluggable activity, but they it should be possible to add them basically to the to the current model of the DWDM interfaces from that side, both from the configuration and also the operational aspect. So it it should be something that can be added with an augmentation. What is maybe a bit different from the current discussion of the pluggable work is how to handle the performance monitoring. In fact here in the interface we don't have a real performance monitoring engine. It's mainly monitoring of the data with the related threshold but just in real time so live data. While probably in the pluggable work there is some so there is a part of the document that also look at the possibility to integrate a real performance monitoring engine. But I in my opinion also that should be something that can be augmented. That's my opinion. 

**Italo Busi:** Italo Busi. Yes, I think on the bis I have a mixed feeling. I've done a bis, couple of bis, and it's really painful. And was looking in the room, unfortunately we don't have, I didn't see Med and Mahesh, but I think what's the right thing to do in my opinion is to speed up the new process and avoid the bis because the YANG model, I don't know, we never finish the YANG model, there is always something to add and so as Roberto said, maybe the performance monitoring can be an augmentation but if you need to add one attribute, it maybe be a bis. But if the bis is a ten years work, that's a problem. And but then you never finish doing the version one of the YANG model because you never know whether you need to add something. So what we really need to do is to have a better way to do a revision of a YANG model. I think as Roberto said, this work is quite stable and we put this if we find two-three attributes that can be added before working group last call, why not, but we don't need to wait until all the gap analysis is finished and they arrive, we never go out. But the risk is to have a bis. Exactly. 

**Chair 1:** The ideal way would be to build the model so that it can be augmented. If there is something that comes up from the pluggable's work that can augment this model, that's relatively simple, we don't need a bis, we just write a new document. I was more worried about things to be changed. But it's not changes, I think it's the fact that you add an attribute which you discover that you need because of the pluggable work but is actually not really applicable only to pluggable, can also be applicable also to non-pluggable, so why it should go into another model, it belongs to the base model. It's just that we forgot to do that in the first round of the base model. That's what I think is going to be most of the majority. Some of them like performance maybe you can say okay, this is a completely new topic, it makes sense to have an augmentation because maybe you don't need to implement performance everywhere. But if it is just an additional attribute which apply to both pluggable and non-pluggable, having an augmentation model just because we published the first version before we discover the attribute looks a little bit strange from a YANG architecture point of view. This is where I think the bis really needs to be, we need a better process for the revision of the base YANG model because augmentation is good to add but there should be some modularity design beyond the augmentation, not just oh, we forgot to add one attribute. Thank you. 

**Kethan:** Yeah, so just on the ONSON part, thanks a lot for bringing up this issue and this is a real issue. CCAMP as a working group that is doing so much YANG work, and recently we have done 100-plus pages of like one of them was a bis, so I hear your pain. Please go to OPS, I think it's OPS working group where this new process and how to do this is being discussed and participate there and try to get this process streamlined. There has been discussion on this in within the IESG. My personal view is that YANG is actually code and we are trying to document code in RFC. When it comes to specifications, we have this ability to do patch on specifications, right, just by having a RFC doing some point update and we get it done. This is not possible with YANG because YANG is code and this whole thing. So there may be different ways to doing it, but please be vocal and active and participate in the OPS area initiative to address this problem. 

**Chair 1:** Okay. We can go to the next presentation. Thank you, Roberto. 

**Bin Yoon:** Hi everyone. My name is Bin Yoon from ETRI and I will present the update to the YANG data model of performance management streaming. Okay. This document's in the progress for working group adoption. I believe, we believe the document is stable and key updates: we add one new author from the WooriNet, a small Korean vendor, and we also add three contributors from all of the three major Korean operators, KT, SKT, LG U+, for their operational feedback. We also had minor technical update to the YANG model for the count thresholding. 

Okay, as a remind, this slides give you the overview of this document and actually this document started the requirements of the collection and thresholding based on the ITU-T G.7710. And this requirements represented through the two types of YANG modules in this document. PM measurements modules and PM capability modules. And the PM measurement modules defined three measurement methods: counter, snapshot, tide-mark. And this version's updated the transient threshold and standing threshold. Based on this YANG modules, the equipment's operated and then the blocks of the YANG data stores supported YANG module and capability to the external system and internal functional blocks. And the subscription notification function delivered the streaming data to the external systems and client and the subscription procedures between the server equipment and clients worked based on the IETF push model and including RFC 8641 and RFC 9196 for advertising supported capabilities. And then based on the information, client consumed this information to evaluated performance of network node. This is the overview of this document. 

Okay, let's go to the updates in detail. The transient thresholding and the left diagrams has only one single thresholds. And the threshold event is triggered when the measurement values is crossed the thresholds. And then we suggest that the transient thresholds are required only one single threshold minimum. However, the previous version defined two types of threshold and the low and high thresholds defined in the YANG node. And so we simplified the two thresholds into the one single threshold called transient threshold. And the standing threshold in the right diagrams has two types of threshold, standing threshold and recess threshold. The standing threshold operate in the same as the transient threshold. The threshold event is triggered when the measurement value reaches the measurement values reach the threshold. And then after thresholding, the equipment continuously monitored measurement value. If the measurement values drops below the recess threshold at the end of subsequent intervals, the recess threshold event is triggered to report to the client. We updated YANG description statements for the standing threshold. That is the update part of this version. 

Future work: we continue the review YANG model and document text. Welcome to review the feedback and contribution from the CCAMP expert. Anyone interest, please join us. Thank you. 

**Chair 1:** Thank you. As you said, we started the adoption process with the IPR polling and then we will do the process. We have Minshuo in the queue. Sorry for misspelling your name. 

**Minshuo:** Yeah. Hi Daniel. I'm first to on-site IETF. I'm Minshuo from Huawei. And I want to ask for the transient and the standing threshold, do we have examples in our document to further explain the details? 

**Bin Yoon:** About the use cases? Or the threshold use cases? 

**Minshuo:** Yeah, something like use cases. 

**Bin Yoon:** Yeah, yeah. You can see the some example codes in my document. 

**Minshuo:** So please can you for the previous slide for the transient and standing threshold. Yeah. For the standing threshold, I'm wondering if it is useful a period for performance monitoring during this period, the threshold may be change and you mean the performance monitoring task is standing for a period, right? 

**Bin Yoon:** Yes, and this thresholdings occur during the count measurement. Count measurement you know measure accumulated events and so we can set the threshold value and then measurement when the measurement value is cross the threshold and event is triggered. It's like a yeah, that is the work. 

**Minshuo:** So the count method, it is one of the types you mentioned, the count, the tide-mark, is one of the three types of you mentioned in the document, right? 

**Bin Yoon:** Three types of measurement method. Here is mainly is interested in the count measurement, not relate to the others measurement method, tide-mark or snapshot. 

**Minshuo:** And the transient thresholding is used for the tide-mark. 

**Bin Yoon:** No. Transient is relate to the count measurement. 

**Minshuo:** Yeah. 

**Bin Yoon:** And your question is? 

**Minshuo:** I'm wondering what type is the transient threshold is used for. 

**Bin Yoon:** Yeah, yeah. Okay. From the application point of view, and the transient agent aims to capture the instantaneous event of the threshold. Okay. And on the other hand, standing thresholds is designed to detect the persistent time of the threshold. That is the main difference between the transient threshold and standing threshold. 

**Minshuo:** Okay, okay. For the transient is maybe for one-time threshold crossing event. 

**Bin Yoon:** Yeah, yeah. Yes. 

**Minshuo:** Okay, okay. Thank you. 

**Chair 1:** Thank you. So, I'm checking the list of participants. I don't see Nigel. So maybe we can anticipate one of the presentations that we have tomorrow, either to retry with the presentation on pluggables or to leave more time to the presenter tomorrow. Anyone willing to give his presentation today? Scott, maybe you said you were willing to do it? Present your draft now? 

**Scott:** As you wish. 

**Chair 1:** Please, so that you have for sure more time today than tomorrow. Tomorrow is fully packed. Well, I'm Scott Mansfield, Ericsson. I will present be presenting shortly the latest work that we've been doing on a bis of the microwave radio link module. And there I'm done. I can go. But I'm not sure they show up among the slides that we have. This is it. 

Yes. So, one of the first things that you will notice is that we changed the name a bit to put in CCAMP just so that people knew which group we were talking about. So this is the data model for microwave radio link. What we would like to do and what we've been doing for the past couple years now is looking at RFC 8561, finding some issues that need to be addressed. There has been some work that has been happening in other groups like ORAN that are using the microwave radio link and there's been some inspiration from there that we're pulling out to put into the IETF draft. We have established the use of GitHub, so thanks to Martin and those guys that did all the Markdown things for that, we really like using that. And that is where if you're interested in the work that we've been doing, we do track issues in there and you can find the entire history of that. So what we've been doing, we also have meetings that happen every Thursday and we've been doing those for quite a while as well so that we can continue to increase our understanding of the microwave models and to make sure that we have everything discussed with amongst the group that is doing the discussing, which you can see. So if you look at the minutes, we capture minutes every meeting with who's there and all those issues. 

So the recent changes that we've been making is that we noticed that oh, there's a new common YANG data types module now, so we need to update that. And we added some leaves for and this is all if you're into microwave, you understand what this stuff means, expected far end ID so that the near end can check that it's connected to what it's expecting to connect to. And there's some work on coding and modulation on an identity, we added a new identity for that, but there's other discussion, and this is where we would like to have some more microwave people engaged as well, to look at all of the identities that we have for coding and modulation identities and rationalize it. So that's another thing that we're doing. Lots of editorial changes to fix some things. And then we change the name of the draft. 

So where we are now is there are these are the major open issues that we have related to our work and the longest standing one is the banding carrier aggregation work. So if you're interested in in that, please join and take a look at what we've been doing there. So those are all of our current open discussions. And so our ask is our very simple ask is to please join and I would really like to elevate this to a working group document either this meeting, next meeting, whatever, just so that we can get some more eyes on the draft. So that's and it's a very mature, we've been doing this for a little while now, there's good engagement on the calls. If you're interested in microwave, join the calls and contribute to the GitHub. So that's my presentation. Thank you. Any question? No. So there you go. No problem. Anytime. 

**Chair 1:** We are almost on time. We don't have any time for for further presentations, but we will wrap up and reconvene tomorrow where once again we will have a very packed agenda. So please try to shorten your presentations and leave room to Q&A. We will try again to reach out to Nigel and put in back on on the agenda to have an update on the pluggables work. In that case it would be the first one. And that's it. See you tomorrow. Thanks a lot. Thank you.

---

**Session Date/Time:** 17 Mar 2026 03:30

**Speaker 1:** So hello. Hello, everyone. We would start, we will start the second session of CCAMP in this IETF 120 meeting. So we covered yesterday all the admin slides. We will just go today through the admin one. Oh, just one second. I need to... okay, we will go just to the Note Well. So basically to remind the participants here, the correct behavior in the participation, the professional behavior with the rest of participants. And basically that all of you should be aware of the IPR things that rights that apply to the whatever content that you can present here or you want to comment. So being said that, a further comment is a change on the agenda. Yesterday we could not cover Nigel's slides. We will cover in as the first slot today. And yesterday we covered the ones from Scott. So the last item in the agenda is removed for the session of today. So with this, if there is no any agenda bashing, we can we can move forward. Okay. Nigel, do you want to have the control of the slides?

**Nigel Davis:** Yeah, if you don't mind. That should be able to do that. Yeah.

**Speaker 1:** Okay. Give me just one second. We will share the slides and give you the control.

**Nigel Davis:** Thank you. Okay, thank you. So, first of all, although my camera says it's on, it won't let me share, so I can't see you. I can't see me, but hello, I'm here. And thanks to chairs for and to Scott, of course, for rearranging the session and apologies for not being able to manage my calendar properly. I'm presenting data modeling and gap analysis of optical pluggables in packet-over-optical networks on behalf of the team there. Rezak can't be, can't present today because he's buried elsewhere, so I'm presenting on behalf of him. Let's see if it'll go... good. So it says progress since IETF 123. I can't subtract either. It's 120, obviously. Since then, we've had working group adoption. So there's the draft, I've put the links in here. Work is on GitHub. We've had ongoing calls for a while, obviously, as you know, as we presented last time. We're continuing to do that. Our work's been done primarily initially around the Google sheet. We continue with that sheet as a detailed view of the pluggable attributes that we went through a long time identifying all possible attributes that we could see on the optical side. I'll speak on that very briefly later. We've looked at the capability attributes. I think we've gone through those, essentially they're complete. There's a couple that maybe we need to refine a bit further, that's the description of things, attributes that describe things that the plug can do. And then we've got a few configuration attributes and a lot of PM and state attributes which we're working through at the moment to close any remaining issues. That list has a number of gaps again in it. So we're finding things that we need to add. I'll explain to one moment. The gap analysis document itself, or section itself, is being updated and refined. I realized I can't see the timer anywhere. I don't know why I can't. Anyway, I thought I'd better... okay, I'll keep an eye on... give me a minute, give me a warning when I've got to a minute, and I'll, if I get that far, and I'll, I'll then stop. But... and we've put on a sort of second pass of that. The key thing here in the gap analysis now is to provide guidance on how to address the gaps. If I move on... let me move on... no, apparently not. Click. Oh, nothing's letting me move on anymore. Oh, yeah, there we go. Good. It's a big delay, I think. Hopefully I didn't move on too many slides. Let me just make sure I didn't go too far. What's the next slide? One second, sorry. Yeah, okay, good. So the goal's to reuse existing IETF YANG models. We're not intending to develop new models unless we absolutely have to. So we're identifying gaps in those existing models. And the group's work is to complement those existing drafts and work. And as it says in that second sub-bullet, if we do agree that there are no existing models for something, we will start new work. We're not seeing any reason to starting new at this point, although then when I talk a bit later about other aspects of the plug, we may find things we need to do in those areas. The gaps have been agreed and we're adding attributes as appropriate. A key observation is that the work's focused on the line side, so the photonics. And the properties we've discussed really are generally applicable to photonics. So although we're under the heading of pluggables here, we're looking at the optics of the plug primarily and of course the optics are optics. So on that basis, this has sort of helped us add to or keep that aim of adding to existing work. Let's see if this will move on or not. I've clicked it, it's not doing anything for me. There, it's very slow. Okay. So the structure of the draft, the main goal of this is the gap against that list. There's as I said earlier, capability, configuration, state. That list, there are very few config properties. There's guidance, some guidance on how to fill the gaps, and we're relating to the work that the operators have been doing in their use case document which Oscar has been leading. And if we find other stuff, which would be beyond work, so if we're looking at other areas perhaps, then we might need to broaden the activity, look at the use case document to drive that to make sure we're not going well beyond what we should be doing. We then introduce new subsections in the document to cover those new areas. Obviously look at examples of gaps, sorry, areas for example in services and so on, which we're not expecting to have to get into, but could be in that area. We'll create subsections in the draft to cover those. And if we do need to do this, we'll have to assign people and so on. So it will probably be more extensive when we're going to try to scroll on. Yes, good. So ongoing work in this document, this area. We're refining the gaps, looking at the parallel Google sheet, developing YANG models as we've said and looking at other aspects of pluggables. This is where we'll be going to. This is what I want to expand a little bit. So our focus has been on the optics. There are other challenges in the pluggables that we need to look at. One is the backside of the plug, so the bus from the plug to the host. We haven't looked at that in detail. Traditionally, in our work here and in other bodies, we wouldn't tend to model that sort of thing because this is internal detail. So if you look at the way we traditionally model devices, you model what you can see from the outside. So the bus is very much like a backplane essentially. So you wouldn't normally touch that. But here there's a vendor boundary. So that might be something we need to look at. So it's an inter-vendor interoperability boundary. The second thing is again on the multi-vendor aspect is dealing with the properties as maybe the plug definitions in CMIS or the available information from the plug in the CMIS work as that expands. They may add new properties, add new capabilities and so on. And that might be happening to a plug in the network where the host has not been updated to cover that. And the question is how do we deal with that situation? There's another group that's working in conjunction with people from IETF and TIP and OIF, Telecom Infra Project, sorry, and OIF, the Optical Interworking Forum, I think, to look at how that might be handled and how that challenge might be handled. And also the proprietary properties on the plug would be potentially difficult to get out of the plug. So those are areas we might need to work on as we move forward. As I said, another group is covering that in some detail. And then also that sort of works on where the capabilities might be needed. So obviously the plug can express capabilities, but in addition to that, when you're planning to incorporate a plug, if it's not a basic ZR or ZR+ plug, if it's got some special properties in it, then you'll be planning those ahead of time. And therefore the capabilities simply arriving from the plug aren't necessarily sufficient. So you haven't put the plug in yet, so you need to understand how to get those capabilities and make those available. So those are areas we might want to look at in the next steps. And as we said, if there's other stuff beyond that, those are still within the scope of the group because obviously they're related to pluggables. But if we're beyond that, then we need to pull in other stuff, broaden the mandate and so on potentially. So I think that's essentially all I wanted to present. Again, thank you for letting me present today rather than yesterday. So, any questions? Any questions? Nigel, thanks a lot.

**Nigel Davis:** Thank you. Is that a question or...?

**Speaker 1:** Nigel, thanks a lot.

**Nigel Davis:** Thank you. Is that a question or...

**Rod Van Meter:** Hi, Rod Van Meter. I did just stick my name in the queue there, it took me a minute to find it. Sorry, I'm not a normal participant in this group, so I'm pretty far out of the loop on this. But the Google sheet, is there any reason that that's not globally readable? How do we get access?

**Nigel Davis:** Oh, that's interesting. There's a link in here. Can you... have you tried the link actually? Try the link in the pack.

**Rod Van Meter:** I tried the link from the slides and the link from the slides tried to put me into editor mode and asked for access...

**Nigel Davis:** Oh, maybe I put the wrong... I may have put the wrong link in the slide. Sorry, I grabbed that the other day. I could... you should have access to read it, I believe. So we can make that available. It's not supposed to be private, so we're not trying to hide. So maybe I'll...

**Rod Van Meter:** Thanks, I'd like to take a look at it.

**Nigel Davis:** Yeah, of course. Yes, of course. Thank you.

**Speaker 1:** Okay. This is Xing Zhao from CAICT. And this is a new work and today I will present the new work on behalf of all the authors. And the title is "The Integration of Network Management Agents into ACTN-based Optical Network". So, firstly we can have a quick background. And we proposed the AI-based network management agent draft in 2024 and the latest version is 04. And now we are trying to ask for adoption of the working group. And here, NMA calls the AI agents for network management and it's a new network management entity which have the capabilities to create autonomous closed-loop. So that's the basic background. And why do we propose this draft in CCAMP? Because we believe that the existing ACTN framework lacks higher level autonomous capabilities. And we all know that AI agents are really hot and are widely accepted in the industry. And also we already have the NMA work in NMOP. So maybe we thought maybe it's the right time to explore the introduction of NMA functions into ACTN-based optical networks so as we can achieve high-level autonomy. And this draft will define the NMA enhanced ACTN framework, define new interface requirements, and describe some typical use cases. And this draft will not define specific agent implementation details or any interface protocol or model definition. So we thought those are works need to be done in other drafts. And first let's take a look at the NMA enhanced ACTN framework. As you can see, the NMAs are embedded as some enhanced components into each layer of controllers. So we can have the enhanced CNC, enhanced MDSC, and enhanced PNC. And also the CMI, MPI, and SBI need to be extended either. So here we want to make clear that the NMAs are introduced to augment the ACTN framework but not to replace them. And we choose this integrated design to ensure backward compatibility because we think that that is really important. And as you can see, there may be multiple agents on CNC or MDSC or PNC. So we introduced the agent proxy mechanism to manage the multi-agents to multi-agents communication. So the proxy is for implementing the enhanced CMI or MPI and it will allow NMAs to register capabilities and advertise to others. And it will be a gateway for NMAs to communicate with external agents. So that's why we think it's very necessary and it can avoid the multi-agents access conflicts. So this picture gives a more detailed illustration of the deployment of NMAs in PNC. As you can see, there could be multiple NMA instances and they can interact with the existing ACTN functional modules through standardized protocols or like MC P or something like that. They can also through the private API. So the existing ACTN functional modules will expose their capabilities as APIs and NMAs can invoke those APIs. And about the interfaces, there are five kinds of interfaces. The first two are the extended CMI and MPI. They will be enhanced from the traditional transactional interface to agent-oriented conversational agent interface. So they also need to maintain backward compatibility and full support all the functional capabilities of the original CMI and MPI. I will talk about this in the next page. And the third is the extended SBI, it's out of scope of ACTN discussion. And the fourth is the interfaces between NMAs and existing ACTN functional modules at each layer. Since it is an internal API, so we are not considering considering it. And the fourth is the interfaces between NMAs within the same layers and they are out of scope of this draft too. And this page gives a more detailed description of the inter-controller NMA interaction between MDSC and PNC. There could be two scenarios. The first scenario is there is no NMA deployed at a certain layer, like if MDSC has NMA but PNC no, or PNC has NMA but MDSC no. So in this scenario, the NMA can still interact with the peer controller through the original RESTCONF mechanism. So we don't need to do any additional modification. And the other scenario is MDSC and PNC they both deploy NMAs. So in this scenario, the NMAs can communicate with each other through the eight-way communication over the extended MPI. And they can also interact through the RESTCONF mechanism. And in the last we also provide three use cases including the service provisioning and service assurance and fault handling. And those are three typical use cases of NMA in optical network. So we want to show that by after the introduction of NMA, it will help the automation of task processing in optical network. Okay, let's move to the end. In the next we will keep improving the content and we look forward to your any comments or contributions. And we hope it can be a starting point for all the AI or agentic work in CCAMP. And that's all. Thank you. Any questions?

**Speaker 1:** So, actually I see that there is a lot of stuff in this draft. Some of it is CCAMP-specific because it touches the CCAMP layers that we have in ACTN and some of it is NMA-specific. So probably the best way to progress the work is to keep it together, not split it into different documents yet. But we need to understand in the future as this work evolves if there is anything that can be generalized and made available also to other other working groups and other technologies, right? You get my point.

**Speaker 2:** Yeah, sure.

**Speaker 1:** Okay, thank you. So, given also the fact that the NMA framework is in NMOP, maybe there is some material that probably could better fit in that document instead of this one. But I mean as of now let's work on the material, let's put it together and then we will see where to split it. It is more a future looking type of type of comment mine.

**Speaker 2:** Thank you.

**Haomian Zheng:** Haomian speaking. And yeah I do believe this is a good starting point and to answer Daniele's point, I believe because we have a lot of optical-specific parameters and to be assured or to be handled in the use cases, I believe this is where our working group will finally landing as a solution, but not in this draft. This is just the starting the work.

**Speaker 1:** Yes, yes. At least a portion of of this work fits here, absolutely agree. Thank you. Thanks a lot.

**Speaker 2:** Thank you.

**Speaker 1:** And guess what, we are already late.

**Minxue Wang:** Hi, good morning everyone. I'm Minxue Wang from China Mobile. Today I'm going to present the framework and applicability of the computation-aware traffic steering in optical transport networks on behalf of the authors, Audi and Felix. So we highlight how the OTN technology is used to implement the computation-aware traffic steering, CATS. and want to extend the CATS thinking into the optical transport transport domain. And now multi-site compute services are now very common and the best effort to dispatch the to the nearest site is often not enough. So it brings the deterministic transport into discussion. So the pure packet-based steering may not meet the strict latency, jitter, and determinism targets, so especially in the congestion scenarios. And the use cases is some workloads both need the awareness of compute stage and awareness of network stage. So user cases including the AI large model training and some AI inference jobs, and high performance computing workloads, and also some business services. So what our ID propose is to take the great concept and functional components of the CATS WG framework and then use OTN to complement packet-based CATS and combine compute metrics with the optical layer metrics and establish an end-to-end hard isolation for the demanding service flows. And the service flow can be mapped into the optical containers such as the ODUk, FG-OTN, etc. and the path selection may consider the deterministic path latency and wavelength continuity constraints and optical link performance and compute resource state, etc. So for the key building blocks, they are all defined already in the draft IETF CATS framework, which is quite stable. And for like the service-side service instance, service contact instance. So the key point is to to collaborate with compute metrics with optical layer metrics. and finally we get a CATS-aware OTN edge nodes. So when the service is identified by an CS-ID and metrics both before both from the network and the compute side, as then distribute to the decision points. and we can choose the best instance and optimum path by the ingress OTN. and the traffic can be classified and mapped into the optical layer and finally delivered to the expected service instance. So what we'd like from CCAMP, we need a deeper thinking on the deployment decision making based on some metrics like the computer side service status, GPU, compute load, memory availability. and from the optical side the latency, wavelength or time slot availability and the link qualities. and also some operational questions like the deployment and OAM and interaction with ACTNs and some security and confidential of the metrics. So next step we believe that CATS is an valuable application for the CCAMP technology for the deterministic and high bandwidth services. and we welcome the feedback and contribution. We request all the CCAMP members to review and comment. So thank you. Any questions?

**Haomian Zheng:** Haomian speaking. Not a question to you but a kind of common idea on this document and the previous one we see some commonalities and that is demonstrating the common interest on working on this kind of computation-aware, whatever kind trying to move the optical networks together towards the computing and the storage. So the chair mentioned the CSO work 10 years ago and maybe we also have the ALTO work and I would like to a little bit clarify saying that that's not ended as ACTN, but we only started the network part of the CSO and ALTO through the ACTN. But the computation part is never done and when the CSO orchestration is just exactly the the thing we need to coordinate among different perspective. So I believe maybe we need to review the work again and see we are not starting from scratch but we have already a good foundation to look at and at this moment people are encouraged to have this kind of gap analysis, especially towards the CATS metric and then drive the our technology forward to embrace those kind of trends. And I'm not the dog old enough, but maybe someone can correct me if they have more history. Thank you.

**Speaker 1:** Thanks Haomian. And a comment from my side which is I really, really liked the slide 7, the one comparing CATS and and this work because this is exactly the best usage of our face-to-face time because building that for a for a reader takes hours reading the documents and understanding the comparison, so providing this type of work is something that is extremely useful. Good job, well done. No other questions? Next one.

**Nigel Davis:** Sorry, it's actually unrelated to this presentation, it's back to my presentation. I fixed that link, so if you could try that link again it should give you access to the sheet.

**Rod Van Meter:** Got it, thank you.

**Nigel Davis:** Okay, thank you.

**Yanxia:** Hello everyone. This is Yanxia from China Unicom. I'm presenting the YANG data model for FG-OTN network draft on behalf of all the authors. The authors are from China Unicom, Huawei, CAICT, and FiberHome. The main ideas about this work is describe the control interface requirements of FG-OTN and three scenarios that requires special consideration, and we define three YANG data models for FG-OTN. So the main changes from version 4 to version 6 is we add a new FG-OTN types YANG model to define the FG-OTN related types and have some update some changes to the FG-OTN topology model and have minor changes to the FG-OTN tunnel model. And we also updated the description of the multi-domain FG-OTN hitless resizing process and some editor updates. So what to be added in the FG-OTN topology FG-OTN types YANG model. We to identify the FG-ODUflex tunnel, we add an identity FG-ODUflex based on the layer-1 types. So what changes bring to FG-OTN topology and FG-OTN tunnel model. For the topology model, we add a when statement making the FG-OTN bandwidth under the max link bandwidth and unreserved bandwidth, making it applicable when only when the audio audio type is FG-ODUflex. To consistent with the changes done on the FG-OTN topology, we move the FG-ODUflex bandwidth under the in the FG-OTN tunnel model under the OTN bandwidth container with a when statement at this place. This is the YANG model to describe the bandwidth of links which can support FG-OTN. In this version we define a new data type TS-list in the topology model to describe the string pattern. The data type of the audio TS number has been changed from u-int 16 to TS-list. For the max link bandwidth remains unchanged, as the previous slide state we add a when statement at this place. For the unreserved bandwidth, we add a FG-OTN bandwidth leaf under the audio list to describe the FG-OTN bandwidth before the server layer ODUk is setup. And to better display and understand the FG-OTN topology model, we give some example of link bandwidth at this slide. The bandwidth between node A to node B is 10G and we allocate the audio zero for to support FG-OTN. So at step 1, no server ODUk are setup on the link between node A and node B. The max link bandwidth and the the the the FG-OTN bandwidth under the max link bandwidth and unreserved bandwidth are all 2500. At step 2, after one server layer ODUzero has been setup on the link between node A and node B to carry FG-OTN traffic, the max link bandwidth remains unchanged. For the unreserved bandwidth, the FG-OTN bandwidth under the audio list changed to 1250 and at this step we need a list need to report the the server layer audio type and server layer audio types TS and the FG-OTN bandwidth remains on this server layer ODUk. And we have upload the the JSON code to our GitHub. Next step we will give a example at step 3 once a FG-ODUflex tunnel has setup. This is multi-domain for FG-OTN hitless resizing process. We changed we update the resizing process scenarios in 6.2.3 and update the hitless resizing process in the appendix. One point we want to impress is that the reverse direction bandwidth resizing will be triggered automatically by the data plane. and the other point we want to impress is that the only the source controller allows report the bandwidth adjustment state to the coordinator after the adjustment is completed, regardless it is success or failure. I think we think the open issue are not blocking for working group adoption and can be addressed as part of the working group development process, so we request working group adoption. Next we will continue the discussing on our discussing the open issue on our GitHub including more discussing on the FG-OTN over ODUcn and we will update the JSON example for FG-OTN topology and include the JSON example in an appendix. And also have some additional editorial improvements to the test. We also have a biweekly meeting on Wednesday and welcome other people to join us, welcome to contact with us. Thanks. Any question?

**Minxue Wang:** Hello, Minxue Wang from China Mobile again. And this draft is for the path computation extension requirements for the fine granularity transport network. So we have already presented this draft in PCE and they need the requirements from the CCAMP. So we also present previously in CCAMP and we have the comments to coordinate with the GMPLS and PCE. So and after that we update the requirements draft and coordinate with the GMPLS and PCE. We add some co-authors and update the ITU-T recommendations and add the FG-MTN network layer structures because we also do some FG-MTN pass computation extensions. So here in IETF 125, we also got some specific extensions for both FG-OTN and FG-MTN topology resource information reporting and path setup in the PCE working group, so we'll present this afternoon. And here's the requirement. So with the proposal of the new service demand transport technologies of the OTN and MTN are both moving towards the fine grain hard slices. So in ITU-T has a series of the recommendations of the FG-OTN and FG-MTN. and this document is mainly focus on the requirements for the path computation and control for the fine grain transport network. So and proposed to extend the PCE to meet the fine grain transport requirements. first so there are some vertical industries and dedicate line services have the higher requirements on the isolation, security, and reliability, but with the smaller bandwidth and fine grain TDM technology can provide the flexible 10 megabits bandwidth for these hard slicing connections. so we update the FG-OTN and FG-MTN recommendations. they have a series for both support sub-1G clients overview and FG layer architecture, interface, adaption, protection, equipment, etc. So for the future massive fine grain transport channel connections, how to effectively perform this end-to-end path computation and control will be an important topic. and and for the reason and requirement why we need the path computation in fine grain transport, there are mainly two reasons. First is the number of the fine grain TDM channels is significantly increasing compared to the traditional connections so based on the wavelength or ODUk or traditional MTN with the larger bandwidth. so like on one 5G MTN channel, it can support up to 480 FG-MTN connections and on one audio 2 channel can support up to 955 FG-OTN connections. So within one device with a switching capability of several gigabits can support the fine grain channel connections of tens of thousands or even more. and second according to the service requirements, the fine grain passes may change frequently and dynamically. and one fine grain channel can carry and correspond to a certain CBR or Ethernet service rather than serving as a large optical channel. So when the services appear or end or its bandwidth changes or the destination address changes, they will cause a change in fine grain channels. So as a conclusion, compared to the traditional optical networks, the fine grain transport networks require more quantity faster and more flexible path setup and removing capabilities. and we think that centralized computation model of PCE architecture is an solution for the fine grain transport network also. The use cases including like fine grain path setup, resource management, update, removal and some service awareness and mapping at the P-node. and the requirements of PCE extensions mainly include PCE-PLS to enable the collecting of the link state or the resource and path calculation calculation request and reply message to include fine grain channel attributes, these are two parts. So next step we believe that path computation of the fine grain transport is required now. So and this draft is mainly proposed the requirements to extend the PCE for the fine grain transport. and the specific extension will part of the PCE and will apply in the future. So any comments are welcome. So thank you.

**Fatai Zhang:** Fatai speaking. So one comment, so a few minutes ago before this session I, you know, talk to you to confirm that this draft covers both FG-OTN and FG-MTN. But you use, you know, FG transport in the title and abstract of this draft. Actually ITU-T only defines FG-OTN and FG-MTN, they don't define FG transport. This will confuse people, so I think you can describe FG-OTN and FG-MTN explicitly. Yeah, thank you.

**Speaker 1:** And a comment also from my side. So I I missed your presentation in in PCE just just to clarify. So this draft is meant to be in PCE because it's PCEP requirements, right? So it's presented here for information and to get feedback. You are not planning to have it moving forward in CCAMP or...

**Minxue Wang:** I plan to move it forward to CCAMP because PCE says that the requirements belongs to CCAMP. and they are just co-authors to get confirmation from CCAMP about the requirements of the PCEP extension.

**Speaker 1:** Well typically PCEP requirements are defined in PCEP, I don't know. We can talk to the PCEP chairs and find an agreement.

**Minxue Wang:** Yes, because they they are just co-authors to get confirmation from CCAMP about the requirements of the PCE extension.

**Speaker 1:** Okay.

**Minxue Wang:** Yes, so they bring this draft to CCAMP.

**Speaker 1:** Yes, but ask for confirmation on requirements doesn't mean that the draft belongs in CCAMP but I mean that's an offline discussion we can have, no problem. Thank you. I agree with Minxue, PCEP requirements for this technology should go to both groups. Right. That's true.

**Sugang Xu:** Can you see my slides?

**Speaker 1:** Yes, just a second we are giving you the control. Sugang, you have the control now.

**Sugang Xu:** Okay, let me control my slide. Okay, great. So my name is Sugang Xu. it's my player to present our draft. here is the draft focusing on the WSON related work falling in the landscape of the WSON. it's related to the information sharing of optical impairments in a multi-domain scenario. large-scale multi-domain WSON network support end-to-end optical pass and along the optical pass, the optical impairment accumulates across administrative domains including OSNR, GSNR degradation, non-linear noise, dispersion, and so on. in these impairments can significantly reduce the quality of the signal, eventually lead to the service degradation or failure at the receiver. Well, existing RFCs and internet drafts support impairment aware path computation provisioning and validation, but in the life cycle of the light pass, we have also the impairment monitoring and the restoration and so on. Those issue are still remain challenging I think. so we raise this question in our CCAMP for further discussion. since the data is critical for any design of analysis, so we first see we need cross-domain performance data sharing capability within WSON to offer measurement estimation information to facilitate cross-domain monitoring and analysis. Here is the slide further detail the requirements for cross-domain performance data sharing. within the diagram we can see when signal degradation here, can I see my mouse? Well, anyway. when signal degradation along the multi-domain optical pass, the receiver at the right-hand side may detect a drop in signal quality such as OSNR, Q-factor, and something else. If the accumulate degradation exceeds the threshold at the receiver, the service may fail. So at that point operator must identify which domain contributes most but the information collect at the receiver might be might be insufficient. So we can see we need a cross-domain performance data sharing to offer more data for analysis such as degradation analysis and fault localization. And we identify two primary use cases which facilitate such kind of cross-domain performance data sharing. The first use case is faster restoration. when signal degradation fails, at the right-hand side, the the receiver will detect the failure and trigger an end-to-end restoration. that be fine, at least we have such kind approach, but might have a higher operational cost because we will need to involve a lot of process in this restoration. But on the other hand as an improvement if the affected domain, for example, domain B can be identified, the restoration can be performed locally and quickly, for example, between the border nodes within that domain. The second use case is SLA responsibility attribution. Say if the performance degradation affect entire end-to-end pass service, in that case the operator need to know who have the the most responsibility for this field. In that case if we have the data collected by cross-domain performance data sharing, the performance can be analyzed together to identify which domain contribute most. For example, domain B will have the more responsibility for this. In that sense, the use case show that the benefit say the collaborative analysis can provide the quantitative and objective evidence of degradation contribution from different domains, helping to clarify responsibility and reduce disputes. However, we need to consider more constraints within this problem. So here we identify two key constraints. The first one is limited observability at boundary nodes depending on the architecture design. For example, within the domain B, if no monitor device is placed at the boundaries, so we cannot use the telemetry information directly from boundary but we need the performance monitoring and telemetry and estimation capabilities within that domain which might be limited in terms of both measurement accuracy and temporal resolution due to the higher computational complexity and load. So that's why it's very important to consider such kind of constraints. Another constraint is confidentiality. In addition to the internal topology, the detailed physical layer information such as optical parameters of optical devices cannot be shared. So we have to consider the detailed cross-domain sharing must rely on abstraction and aggregation as a generic guidance. Oh, here let me review my talk. Our motivation is to raise a discussion in CCAMP. So because we think there's very important to find the fundamental assumption on constraints. Well, we didn't find any documents already on this issue, so we need to create the foundation on constraints firstly. we expect feedback, guidance and collaboration in CCAMP. but the first thing for us is please let me seek the kind opinions from our CCAMPers whether such kind of work is interested or beneficial to be discussed in CCAMP. that's all, thank you.

**Italo Busi:** Hi, Italo Busi, Huawei. I have a question for clarification and depending on the answer and the comment. domain A, B and C are three different vendors or the same vendor?

**Sugang Xu:** they might be different or same vendors.

**Italo Busi:** same vendor. So why do you split into three domains?

**Sugang Xu:** actually they are three operators, they are running different domains. Actually domain A, B, C will be owned by different operators. It's kind of a multi-domain scenario.

**Italo Busi:** It's a multi-carrier scenario at WDM layer?

**Sugang Xu:** Yes.

**Italo Busi:** Okay. Never heard about that. Okay, good to know.

**Speaker 1:** Thank you. I am Daniele from Futurewei. So yeah, I think you probably the same as Italo mentioned. So basically you are saying those belongs to three domains three operators with no like common orchestrator or multi-domain orchestrator on the top, right? Yeah that was a bit different from what we have dealt with because in in the current ACTN framework, we have a multi-domain MDSC on the top for multi-domain coordination. So now you're more talking about the east-west sort of communication between different domains, if I understand correctly.

**Sugang Xu:** Yes. So I'm not sure whether our focus in CCAMP will be extended or not. But anyway, I think it's quite a practical issue when WSON should be pushed to the market. that be a problem for interconnection among different operators.

**Speaker 1:** Yeah, I would say this is an interesting scenario but also the the fact that you are doing cross-domain at the WDM layer, that's also unique. Probably need to think about that. It will be very good to have input from operators because it's whether operators are peering at the WDM layer and at AS and that's new to me so that's why I would like to hear input feedback from operators about where this type of deployment scenario is actually existing. But thank you.

**Sugang Xu:** Thank you so much for your comment. Actually we expect any feedback comments guidance and collaboration within CCAMP.

**Roberto:** Hi, hello, I'm Roberto speaking. I think this scenario is probably coming from the IOWN Global Forum that is one of the probably the unique place where I heard about the peering between operator at the WDM layer. Right?

**Sugang Xu:** Yes. actually here is a discussion within IOWN community, but how to say, we are for sure we are doing the research work is a little bit far from the current step. But anyway, I think in the future we must face to such kind of a problem.

**Roberto:** Anyway is an interesting scenario that it's good to look at. Thank you.

**Sugang Xu:** Thank you so much.

**Speaker 1:** Probably it also depends on how you define a domain.

**Sugang Xu:** Yeah, but it's the same vendor I understood. So it might be our concept of domain is different.

**Speaker 1:** Sorry?

**Sugang Xu:** No, I was saying that this is an unusual scenario but probably the word domain is used in a different way than we are used to in the sense that when we speak about the different domains, we speak about different controllers, different vendors, different everything. Here there are a lot of things in common so I don't know, maybe it's a particular type of domain, that's that's what's what's creating a little bit of confusion.

**Sugang Xu:** thanks so much for your comments and let me contact with you for more seeking your kindly opinions.

**Speaker 1:** Thanks to you, thanks a lot.

**Sugang Xu:** Thank you so much.

**Speaker 1:** So we have seen a lot of requests for working group working group adoptions. We are sorry that we didn't have time to do polling because we already had a super packed agenda and as usual we are a few minutes a few minutes late. We shared yesterday the list of priorities that we identified, the top three top four for working group adoption and working group last call. So we will continue with that and we'll add new new drafts to to the backlog. Thank you, thanks a lot. That's it. have a good rest of the week and goodbye. Bye bye.