Session Date/Time: 20 Jul 2026 14:30
[00:00:05] Diego Lopez: Congratulations.
[00:00:09] Emile Stephan: You got you got a bit long, but No.
[00:00:13] Diego Lopez: The problem is at 3PM.
[00:00:24] Emile Stephan: Good work.
[00:00:53] Rob Wilton: Okay. Alright. So good afternoon, everyone. So we're hitting 04:30. So about time to start our last session of the day. Appreciate you all had three long sessions. And the door's been closed. Great. So welcome to the green working group. Hopefully, is where you want to be. If you're if you're not expecting to talk about green stuff, then you're in the wrong place. I expect people will come in a few minutes. I'm Rob Wilton, and I'm one of your chairs. And my co chair is
[00:01:29] Diego Lopez: Diego Lopez, which is the other one. Well, you are going to to make the the the introduction. So
[00:01:36] Rob Wilton: Okay. So you know, I've got this clicker. So let's do it that way. So the note well, you've seen this a few times today already. Please take the time to read. I'll leave leave it up for a few minutes in time. It's important to understand that this says what your rights are in terms of participating in IETF and in these meetings. I want to pull out the fact about the professional courtesy and things. We we haven't had any issue had any issues in this working group, but if you have any concerns, it sort of describes some ways to people to talk to, and you can come and talk to Diego and I if you need to. It's also worth pointing out that there's IPR considerations in terms of what you provide into ITF. So if you have any of those concerns, you have patents on on your work, you want to make sure that you understand what those obligations are before you rework the IETF. And if you need any help with this, any of the text on here, can come talk to us or the directors. The agenda for today is we've got a two hour session, and the work's sort of split almost roughly an hour now. So we've got the first hour and a bit is the introduction and then discussions of the adopted works of these items we're making progress on, our core deliverables. So we've got an update on the terminology, the use cases, the framework, and the power and energy model. So I think we're making good progress towards our sort of core initial milestones in terms of adopting this work. So we'll hear more about those today. So that's good. And then we in the sort of second, not quite hour, we've got some other work that's sort of tangential and in of interest to green. So some more model updates, PETRA green API, and this ISAC utilization. So so both of these have been presented a few times and will be presented again here. So I think that what we would like is the working group to consider whether this work is something that should come into the working group. So that's what we'll be discussing there. And of particular notice, we don't want this to sort of take over the core deliverables. So we don't want to lose lose our focus on those, but looking at the additional work we might have to do over time. And then we have some new proposals of other ideas and work that might be of interest to the working group. So again, those will be presented towards the end. And finally, there's time available, which I think the quality will be, there's an OpsWG IPFIX energy consumption model that will also be presented here. I've got a few minutes to wrap up. So working with status comes first. So we're progressing well since Shenzhen. I've said the use cases, terminology framework, and the and the base device yang model have all been adopted. And these are the core deliverables except to the fact that I think that we also want to adopt a controller level of the model to go with the base device model. So the team that's working on that base device model is also working on the controller model, so we'll hear more about that today. We have been having these meetings every two weeks to discuss the data modeling and things, and mostly that meant that over time that that membership has dwindled somewhat to point to point where it's been mostly the authors plus Diego and I plus one or two other participants. So we chatted with the different authors about whether they want to continue those, and they still find them to be useful. So the plan is to continue those, but it'd be good if we had more people coming. Those meetings currently happen actually, it should be on here. They they currently happen around is it 3PM, 2PM?
[00:05:13] Diego Lopez: 3PM 3PM c t.
[00:05:16] Rob Wilton: Yeah. So two p 2PM. 2PM UK time, which is either GMT or summertime, and that's happening two to 4PM every other week. I think there's a question as to whether the timing is causing issues to people or whether what other ways you can get more participation in here. So I think if anyone here would participate in the in those meetings and it's the time that's causing an issue, could you let us know? And then we'll maybe repoll for a different time. But at the moment, most people are coming around European or Qina time zone, so it seems to be reasonable.
[00:05:48] Diego Lopez: Oh, yeah. Just just one note. Take into account that this is not the lightweight design team meeting altogether. But the idea is that precisely most of the of the time is about open issues that that the the design time fine the design team, sorry, finds and that they they that they want to get, if not formal consensus at at least to get some initial consensus from the group, The more we we the more people we have, the better and the faster we we will go. And as Rob was saying, if if there is anyone that feels that that that time of the day is totally inappropriate because of time zones or whatever, let us know when we can we we will try to to find a better time.
[00:06:38] Rob Wilton: And I've also mentioned on the previous slide, again, we've got some presentations about extending the wider modeling of other related work. So again and that also includes outreach to other forums that are doing energy related work, but we aren't to lose our focus on delivering the core core work. No effects on. Please please try and review the documents. That really helps us progress the work forward, especially the ones that have been adopted because we want to try and get that that work to progress and get it finished and move on. At some point, we'll start getting pressure from the ADs, our AD to sort of get this work completed. But we're making good progress, we want to count on that, please. In terms of reaching out, we've had some interactions with other sorts of incoming liaisons from various people. We've also had some interactions with LSR a bit in terms of some work to do with energy related gang models in some of the routing working groups. I think there's some more coordination required there. So I mean, see Tony Lee's in the room, he's one of the main proponents of that work. I think what we're trying to do is find the balance of not slowing that work down or blocking it and allowing it to progress, but also making sure that whatever definitions it uses are aligned or ideally reusing the ones in green. So I think it's balancing that. So I think that we will have some more coordination related to that as that goes forward. And the aim here is just to sort of avoid any misalignment. We don't have these different terms defined twice in two different ways of being incompatible is what we're trying to achieve. And then not to forget external liaisons. So we can make outgoing liaisons to other places as well to make them aware of the work we're doing. So so that is also possible. If people think that's useful or have particular ideas, then let us know. And if you're willing to help actually draft those, that's also appreciated. And one of the ones that Diego has put in there is that some of the recent a European Commission activities were identified during the adoption poll, the framework draft, and things. So I think we need to check that.
[00:08:49] Diego Lopez: Let me let me try to clarify when we're talking about this. It's about making other bodies aware of what we're doing here. And this is important. So or we initially, we started I remember, well, I I we started some kind of broadcast, some statements about people being aware of what we're doing. But during the adoption call for the framework draft, we got noted, and Marisol has this as an issue, right, in the that there was a collection of relevant standards that is being performed by by other bodies, and they are not mentioning what they're doing. And I believe we believe that this would be important. The idea is that if there is no disagreement in the room, we will prepare some text for as as a liaison statement, and I will share them with you and and send it if you are there is no objection. It's simply simply that. You know? It's not that we are attending doing anything just to build awareness of what we're doing. And
[00:09:55] Rob Wilton: so the next steps, I've already mentioned this. This might change, but we plan to continue the design team light meetings effectively as discussed. I have got the time to move down here. Not not Monday, March 30. That should be updated. And then we also open to holding virtual interims on particular topics if that's So let us know if there's things you want to do. And then the last slide is basically some related green work that Diego's
[00:10:17] Diego Lopez: Well, it's more related to green events as you as you know. Well, it just hasn't been inspired by that idea that that Rob shared with me this morning that it happened on a green on a green carpet. And, well, it's not only that we are I don't know if you were aware of this, but we were we were we became champion world champions yesterday. And Benoit was so nice to to remark as well that right now, Spain is at the same time the world champion for for the, well, male football and female football. So, well, to be sort, we own it. So let's go for the And it for the non so serious stuff.
[00:11:03] Rob Wilton: And it's all down to Diego. Right. Okay. So moving on to more serious things. Right. I'll find the first presenter.
[00:11:15] Diego Lopez: So first one should be Qin. Right?
[00:11:19] Rob Wilton: Yes, Qin. I need final slides. Do we have stickers? Yes, you will do in a moment.
[00:11:32] Qin Wu: Okay. Good good afternoon. My name is Qing, and I will give update of this terminology for energy efficiency and nanomanagement. The document status and current version is version zero two. Yeah. For the previous version, actually, it was upgraded in the Shenzhen IETf-one twenty five meeting. And so one of the conclusion is we will continue to progress each chapter instead of which to publish it earlier, actually. So we just before the Vienna meeting, actually, we, you know, discussed with framework author, young data model author, so we try to align continue to align the terminology. So, yeah, most of actually the draft author. So latest version, you know, that we made a change. For example, we move power factor, energy management system terminology from framework to the terminology draft, this draft. And also, we add two definition. One is nameplate power definition. The second is power source definition. And for all the other, you know, energy management system related terminology, and we also, you know, move from the framework to this chapter. And also, we add a missing external reference. So for several new terminology, add the one to get a pivot to review. First is nameplate power. This already defined in the 7326. And this actually has been called in the framework chapter in section four point o four, powers dataset. So we, you know, gave this definition in the terminology draft. And so you people have any comments or think this terminology need to improve, please let us know. And the second terminology is power factor. I think this terminology is referenced in the young data model. And so we gave the definition here. You know, we define the power factor as the percentage of value between zero and one. And also, we list the one special case. For example, for energy object, the power by direct current power source, this power factor will be considered to be one. And, yeah, there's a new definition we add. And, yeah, we hope to get some people feedback if you think anything missing or need to be improved. The third definition actually is existing definition is energy management system. We make a little bit modification for this definition since the origin
[00:14:33] Mehad: of
[00:14:33] Qin Wu: this definition in the framework, actually. We have a three node, actually, but one of the node related to the carbon report, but we think it's not fitting to the chart, so we remove this second node. And for as a two node, actually, we make some text tweak and just a minor change. So this the definition we have here. Yeah. I think, yeah, we'll continue align with all the other green worker. And, yeah, in a previous meeting, I asked a chance for existing individual report to the working group report, but we haven't do that. I think we need to follow-up. Yeah. Ask a chair to have this. Comments? Yeah. That's all from my side.
[00:15:22] Rob Wilton: Any comments or questions on this draft? It's done. So so otherwise, yes, we will help you move the repo across. That makes sense. We said we'd do that before, so we should do that. And otherwise, I think the expectation is this draft continues to progress alongside the others, and we don't want to try and last call this now. I think we'll wait until we know exactly what needs to be in it. Right. Yeah. So that's fine. So there's no other questions. Think I think we're done.
[00:15:52] Mehad: Thank you. Yep.
[00:15:53] Qin Wu: Yep. Thank you.
[00:15:57] Rob Wilton: And I think Emile up next.
[00:16:08] Emile Stephan: Hello.
[00:16:12] Rob Wilton: Thank you.
[00:16:15] Emile Stephan: So I am going to to give a bit the status of the use case draft. And so I have just one slide to say that we are maintaining a loop now with the modeling team, we are not trying to change a lot of things in the use case document. And, anyway, we will focus on the short term support you see for use cases like incremental deployment on double accounting. So we will be challenging a bit as a modeling to be sure that we can implement these use cases at least with the the current work. And one goal is to to get a first evaluation of this the implementation of these two use case in San Francisco. And another direction is to to see if the pro provenance use case that will be presented by by Marcel later can be added in the in the future version. That is for me.
[00:17:40] Rob Wilton: Nice and quick. Any questions on this document or comments?
[00:17:47] Diego Lopez: It's a short comment, Emil. A couple of days ago, there was a warning from the data tracker that the the draft the draft is supposed to to expire. Yeah. Did you did you update it? Or No. I didn't. Just, I mean, it's just to avoid that our our area director is asking us about what happens with him or sometimes like that.
[00:18:08] Emile Stephan: No. No. Seriously. Have changed anything, so I can touch it. Yeah? Or perhaps No.
[00:18:14] Diego Lopez: No. Touch it. Touch it because I'm I'm thinking about someone that is not not part of the usual suspects and connects to see what's what this guy's doing. Say, well, no. Look. The use case is the use case draft is is expired. It's a little bit
[00:18:29] Emile Stephan: What what what we did is we we focus on No. No. The framework?
[00:18:34] Diego Lopez: No. No. Yeah. I understand. Does it if you don't mind to touch it, then that's why.
[00:18:38] Emile Stephan: Not a good idea to change the use case because
[00:18:40] Diego Lopez: No. No. Sure. Sure. But this so it's not since we have this policy in the idea of the automatic just
[00:18:48] Emile Stephan: Good. It will be the opportunity to to add something on the performance works.
[00:18:55] Rob Wilton: So
[00:18:55] Mahesh Jethanandani: I give you the floor.
[00:18:56] Rob Wilton: Before you I'll leave the call. Okay. So my understanding from when we discussed before is I don't think we're necessarily planning to publish this in our CRM. And I'm not sure we were one way or the other, but our thought was this. We're trying to sort of coordinate the use cases and make sure they're tracked and agreed within the working group, but we're not necessarily gonna take further.
[00:19:16] Emile Stephan: Well, this is orthogonal. Mean
[00:19:19] Rob Wilton: We could do either.
[00:19:20] Emile Stephan: We need to to to have a reference for the use cases. It doesn't matter if we go to AFC or or not.
[00:19:27] Rob Wilton: Yeah. But I I was wondering, whether it'd be useful to do, like, a working group last call to check, to a, force people to review these and check your consensus that this is the set of use cases we should be covering.
[00:19:38] Diego Lopez: Well, I I I don't know. But for me, the
[00:19:40] Emile Stephan: the next step can be to sketch how the use cases can be implemented with the modeling. But
[00:19:46] Rob Wilton: Oh, fine.
[00:19:47] Emile Stephan: I Okay. I I don't I'm not not looking for the RFC Yep. When I work. So that is
[00:19:57] Rob Wilton: Okay.
[00:19:57] Diego Lopez: Up to you guys.
[00:19:58] Rob Wilton: Okay. Well, I'll discuss with Diego afterwards. But otherwise, I think definitely makes sense to try and correlate the use cases to what we are implementing, what's being implemented by the work group. That makes sense.
[00:20:09] Emile Stephan: K.
[00:20:09] Rob Wilton: Framework. Yeah. This this one.
[00:20:41] Marisol Palmero: For the framework from energy efficiency management, we have been releasing the version two. And thank you for all the work from the authors and the comments that we have been receiving. But since, has not been big changes on the framework as new concept. It has been just aligning to the green-yang data model and cleaning this overlap with the terminology. Many things have been moved to the terminology, as Qin was also discussing. We didn't do everything that we were expecting to do since we set next steps, but we are keeping working on it. Like this prioritization of the use cases, just we heard Emile. Let me just go a deep dive. One of the things that we have done is to review the reference model. We have been cleaning it up. I have opened just recently a couple of issues to clarify between some of the interfaces to add more information about specifically about the interfaces. One thing that we changed was this app layer on the energy management system. It was before the main network manager, and we changed it to the energy management system to align with previous RFCs. And, well, the state of the art basically is we have been working mainly on the green-yang data model for the devices, for the energy objects. And work has been just started on the controller level, and yang will introduce based on that. And, well, the use case mapping, just making sure that the framework makes sense with the use cases that we have been working on. You might see here on the version two many changes, but it has not been that many. It has been just more restructure and add more clarification. For instance, the EMAN migration mapping table that has been added, a new relationship that I will touch a bit, and Benoit will talk about that as well. And, yeah, alignment with the green-yang data model that has been recently adopted. We have been working on issues. Opening GitHub up to 15, we have been working on, and it's basically what I have just mentioned. The most important thing that we want to do in the framework is to keep the alignment with the data model from the device and what it might be coming from the controller. We might also look at the framework how things are introduced from the for the green-yang data model and what is covered there as well just to do not duplicate the work in both. The this will be looked up as well in next releases as far as the conversation advance. One new section that was created in the framework document has been the operational considerations, where we have been highlighting this inheritance for the unit multiplier and for accuracy, for the data source accuracy. Basically, the power and the energy leaves are containers are treat a bit different. Power is mandatory. Energy is optional. And how this inheritance comes for the unit multiplier It's mandatory for power container, not for energy. And by default, for energy, it will be on the measure of one. And for data source accuracy is if absent, the client must look at the parent objects, right, just to avoid duplication of sending more information across. There is another relationship that has been added, the relationship type. Basically, it's an identity file ref that can be updated. It could be including new relationships in there. Basically, we were defining only power source matter in our aggregation. We are adding a new we have been adding a new functional dependency based on some discussion on the mailer. Anthony Lee was raising this initially. And it's about the enabled by and enabling, basically, when the component might have a functional relationship with the in this case, the the the example that we are giving is about the line card and and the switch or the router that is hosting the device that is hosting this line card. There is a functional dependency that is not covered by this other relationship that were there where we might not be switching off or changing status just based on the other relationships. Basically, we closed a lot of open issues. There are a few remaining, a few ones that I have been opening just based on discussion that we have here these days. But the two at the bottom that were remaining, they need a bit more work. Diego just mentioned about this liaison discussion, and that will be addressed later. And the about the sources, read write property, read only property, this will have more discussions as well when the controller YANG data model is coming and decide how to address that issue. Basically, the device might be initiating this power telemetry relationship with the controller, and that needs to agree between the controller and the device to set up that energy object ID, basically. Next steps, not much different from what we said, but, basically, the focus next is more on the controller side to advance on the green YANG data model, and we will keep aligning with both both data models. It's going to be a different JAN data model for the controller, and Jan will talk later about that. And our way of working is creating these open issues, things that might come in the side meetings in the in not side meetings, but the biweekly meetings that we are having as well as discussions on the mailer, will be addressed through the open issues. With that, please note there are any questions, feedback.
[00:27:39] Rob Wilton: Any questions or comments from the working group? It's very quiet. If you can go back a couple of slides. We had a list of issues. I can't remember it was seven or eight, maybe. Not that one. So you got the chairs to comment. So, yes, we I think I've had a quick look at that document. I think Diego has as well. I think we need to look at it more properly. I think, if anything, it might be a minor informative reference or something. I don't think there's anything significant there. That's our impression. And maybe we I think we suggest maybe sending a liaison to them, maybe. I don't know if it's worth it. But
[00:28:18] Diego Lopez: I I I mean, it's the the point is that they believe it's it's harmless if we do it. And, I mean, liaison is only only says that we are that we are here. We are not going to commit to anything just to and while on the other hand, well, if it if what we are doing is cited, probably will will help in in aligning a little bit of the of the models. It's it's the only it's the only reason for.
[00:28:44] Marisol Palmero: My comment, you know, why I think it's needed to have, you know, a voice outside about what IDF is doing. There is a lot of looking at how green discussions are going. There are a lot of SDOs working on different aspects. And it will be good to let them know what ideas I can be looking because I think we are quite specific on what we are doing, but they could benefit as well from the discussions that are happening here.
[00:29:14] Rob Wilton: Okay. In that case then, I think afterwards, it sounds like we should potentially, again, check the draft, but maybe look at sending external liaison to them, if makes sense. Maybe we'll find out the right people to send it to.
[00:29:25] Marisol Palmero: We'll talk later, but I I know ITF is mainly technical, but now it's coming a moment where the legislation mainly here in Europe. Right? I don't talk outside Europe. But it is coming to look more into real time measurements. And I think it's an important thing to consider as well to advance on things even a bit quicker.
[00:29:51] Rob Wilton: And this is stepping somewhat outside of our levels of areas of expertise, but I feel like, again, between governments and technical organizations, it helps if we can be leading from the general discussion and telling them what we're doing and then letting them know rather than legislating in isolation.
[00:30:08] Marisol Palmero: Thank you.
[00:30:09] Rob Wilton: Thank you. Is it next? Let me check.
[00:30:23] Diego Lopez: So so soon as a conclusion, I will prepare some text and share it on the analyst just to see if to to build that, Liaison.
[00:30:36] Benoit Claise: Alright. So let's discuss the power and energy- yang module. This was accepted as a welcome document around June. And we've been pretty productive because we published three versions already. Okay. Three versions in, like, two days because there were small mistakes in the formatting, but still it's three. We've been busy. This slide, you've seen it just to set a scope. This is everything that deals with the device itself, both the reporting and power saving mechanisms. Let's look at the YANG tree. That's maybe a good overview. There are two parts. The first one is everything which is operational read only. And the second part below, this is energy control, which is read write. So the thing I want to mention in there is the relationships. If you look at the relationship there, again, it will be useful for the next slide. We have some sort of relationship, a type of it, and they go to peer ID, which is, in this case, a string. We're going to come back to this as well. We have this new relationship called enabled by or enabling, and it's somehow a functional enablement relationship, as it was mentioned in mailing list, a switch card and a dependent line card. Neither is pouring the other, neither is metering the other, so we added this one. It's actually very quick because these are just new two new identities in both directions. Something that we want to mention about relationships, and I will come back to the YANG tree. The relationships are in the operational parts. What does it mean? It means that, at least the way we put it in the draft, is that the router is going to report what it knows. It's not there to be configured to know those relationship. Because if it's configured to know to to set those relationship, it's because the controller knows about them already. So maybe it's best that the router will just advertise what it knows for sure. And those relationships are not available in the config tree. Alright. So we had a discussion in the mailing list with regarding the relationship which are on different device. Right? And we discussed what to put as a peer ID. And in there, we say something like in a draft, if you know about the UUID of the remote end, you could put the UUID. But in the end, we configure this as a string because how do we know it's a UUID? Do we know do we have mechanisms that are like LLDP or or Cisco CDP, which are telling, I'm connected to a phone and I'm receiving the UID of that phone, of that camera of so actually, we don't have mechanism like this, so we can't rely completely on the UID. The controller might know a UID, but the router itself, it might not. As a consequence, we're going to default to a string. There were discussions on having kind of a union there, but actually, a union of a UID and a string, well, this is a string and it's not even helping because you don't know if you can rely on the UID. That would come back in discussion with the controller because, actually, we need two IDs, one known by the controller and one known by the router. That's what we describe in the framework, like the router ID and the controller-known ID. So we fixed some of the Yang issues. Okay. We forgot the base unit multiplier. Okay. We should know better Yang. We mentioned the UID again. No need to repeat this. We put, as Marisol mentioned, a default value for the unit multiplier. We are kind of concerned if you've got a lot of energy object that we need to multiply leaves for the sake of multiplying leaves. So putting a default makes sense. And we don't have to report it for every single energy object ID. And by the way, you mentioned we could have the one for the parent. So we also stressed that now we're dealing with the I triple e power state sets. If you recall the previous discussions, we had in IANA we have in IANA three higher power state sets, but we decided to go from the minimal one, the I triple e, but it was never clearly mentioned in the draft. So now it's clear or clearer. So all of these documents are evolving together. So first of all, we remove all references to the old EMAN in the Yang module. It was maybe there as, you know, a helping hand, but now there is no point to even mention it because EMAN was not implemented and it was a MIP. There is a little bit of text in the framework, which is fine. We mentioned the link with the terminology, and we are aligned. There is just one exception with energy object, and that's been solved already in our draft because somehow we were referring to the energy object definition of framework, and the reference is the technology object. So, Qin, you look like there is nothing wrong with your draft. It's perfect. It's just it's just telling that we have to point to your draft and not the framework. Don't worry. Relax. I saw your face. Obviously, the framework and the yang modules, they evolve together. We keep them always aligned. Jan is going to start discussion on the controller Yang module in a in a few minutes. And the use case, we discussed that and also, like, you know, having a new version without much changes, and that's fine. So we have open issues, and some of them are open like recently because even by preparing those slides, we sometimes find an issue. I could tell you that some of them have been resolved already this weekend. The first one is about terminology. We've got, like, the PR done. Linking the object ID in the control tree and operational three so let me go back to the yang, the YANG tree. If you see there in the operational, we've got object ID as the key, and we've got object ID in energy. And somehow, we have to say that whenever you've got an an object ID for energy well, actually, the if there is a link, it should be the same one as the the power. Right? So we put text over there. Another one is that it says object ID, which is actually very generic. What definition is energy object ID? It might be like details, but we're aligning everything together. So what else? We solved one issue with, IANA, with Ken even going to the IANA table there and getting making sure that we've got the right Ayana section. Okay. Good job. Now, what I want to do now is discuss three open issues which are worth the time of this working group, which are slightly bigger. The first one we received on the mailing list, we have in instantaneous power as mandatory. How are people supposed to comply with that? Put an active meter on each and every component. Manufacturers many manufacturers will refuse for cost and space reason. I can see nameplate power as mandatory, but not instantaneous power. So, yes, we could. Now if we do that, look. The question mark there is optional. So basically, everything becomes optional, which could be fine. Right? But then, is this what we want to do because everything is optional? Or what we could be doing is telling we're going to say that the energy object definition is whenever you can report, it's at least power. Or we could be telling, well, whenever you're going to report nameplates. But the question to the group is, okay, what do we want to do here as default? Because we could say everything is optional, but the point as well is that it's not because you've got an object ID here, which is linking to the hardware components there, that we must have an entry for every single component from the IATF hardware or the every component from the entity old entity MIP. If we've got nothing to report about power energy, we just don't report it. So discussion time.
[00:40:34] Rob Wilton: Mic's open. While while people are thinking, my so instant reaction here is that making it optional is better because it's better to give the flexibility rather than force somebody to have to lie and produce an incorrect value. And it's quite possible that some components might be able to return instantaneous power and others wouldn't, which means you can't even deviate the leaf because it's used in some cases. Otherwise, that means either you're just not returning a value, maybe the yang doesn't validate, or you're gonna return zero and the client has no idea of knowing that it's it's in scope or not. So I sort of feel that it's better to make these things optional, and then if you return them, if you you know them and you don't you don't return them.
[00:41:23] Benoit Claise: That's one view. I could agree with anything. So even that view would comply with the definition, right, which says let me read it. Energy object represent an equipment that is part of or attached to a communication network that is monitored or controlled or that aids in the management of another device for energy management. So even that, you would be compliant. Right? It seems to me that if you put everything optional, then, okay, we would need maybe more guidelines in the yang module or the framework telling, okay, ideally, you want to have some of this power, but if you can't, maybe the nameplate is sufficient sufficient. Because just reading a yang module is optional, it really complies. Right? So the guidelines will be more important there.
[00:42:09] Rob Wilton: Yes. And that sounds like the right that's what I think is the right answer at the moment.
[00:42:14] Luis Miguel Contreras Murillo: Nigel? Yes. Just going to
[00:42:16] Nigel Davis: align with that point. So in in TAPI, we've had the same experience. So we had a a mandatory temperature attribute on an equipment. And so every equipment had to report temperature, but not all equipments had monitors on them. And as a consequence, you have to go and make some number up. So we went through the process of this, and we concluded that the temperature shouldn't be mandatory. It should be optional. But then if it's just purely optional, you have exactly the problem you've highlighted that, you know, you're compliant by putting nothing in there. So on that basis, we then put guidelines on temperature saying that if the equipment had a temperature monitor, it was mandatory to report it. But if it didn't, you didn't report the property at all, which I think is exactly what you've just been saying for this. So I think that's that's exactly the right answer. That's what we concluded in in TAPI because it's the only way of actually resolving the issue. You don't have an ability to deal with the thing. You don't report some strange max int or something like this. It doesn't help. So not reporting at all. It has to be optional, but then we we identified the thing as essentially conditional. We said it's optional on the yang, and there are a set of conditions in the in t r five four seven, which is our document that says, under these circumstances, you and then we found lots of other properties have the same challenge. And as a consequence, almost all of our properties are now optional in the yang and conditional in the descriptive document that explains when you have to report it and when you don't. So I think that's the position you're essentially Rob, you were essentially saying, I think. So
[00:43:43] Benoit Claise: Very good. Okay. Don't go away. I've got one more question. Because whenever you mention whenever you know the temperature, it's mandatory to report it. Now there there are two things with yang. It could be in the yang or it could be in the document. And somehow, some people take the yang as stand alone, and we start to see more and more that you've got, like, the must, the should, the make in description. So what do we do in this case? We put the guidelines in the self contained yang module or we put them in the document, which mean that from the yang, you must go by the yang catalog to find back what is the document unless you just look at the description and then say, oh, I'm also compliant with the guidelines that are in the document. See what I mean?
[00:44:27] Nigel Davis: Yeah. No. I fully see. So so in in TAPI, we're fortunate that we've made t r five four seven essentially normative, and it has normative and informative parts in it. Therefore, the yang isn't standalone. We have to have both. That's just what we've been able to do in Linux Foundation. But it feels like you almost want a formal profile or something that explains this. So you've got yang as the standard form, which is optional, and then a set of different profiles or profile fragments that you have to be a better point to conformance with or something like this with reason rather than just a dissociated document that people can miss. And that's, I think, the problem you've highlighted. It's got to be a normative thing that goes beyond just a simple Yang statements.
[00:45:08] Benoit Claise: Right. So do I understand from what you're telling me that we would put the guideline in the description telling to just quote your example, if temperature is available, you must report it, and then the profiles would be in the framework? Because, actually, the description could start to be very complex. That's right. That's not
[00:45:27] Nigel Davis: not that wasn't quite noted. So in the in the description, we we stayed optional, essentially. We explained that it's optional. And but then, as I said, we have a normative additional document, which makes our life a bit easier. But so the the guidelines then become semi normative, essentially. So some of them are informative guidelines, others become normal. And that becomes challenging, I think, here, especially.
[00:45:52] Diego Lopez: So this is a bigger discussion. Right? Because, actually, you're changing
[00:45:55] Benoit Claise: yang to say, yang, fine, tiny description, but there is a must normative reference to read the document before, which was exactly what I was
[00:46:03] Luis Miguel Contreras Murillo: trying think
[00:46:03] Benoit Claise: to see it was not the case by putting more must and should.
[00:46:07] Nigel Davis: That's right. So and so I'm not I I wasn't putting a solution forward for here. I was saying we had exactly the same challenge in TAPI. We chose a particular solution because of the situation we were in. I think you might need to choose a more sophisticated solution here that isn't simply putting in the yang is a problem because, of course, your yang then keeps changing. So you get another condition, another condition, another condition, which is the challenge we have with TR five four seven where every time we open the document, we find another set of things we want to put more conditions on. So it's not a bounded problem either. So I'm pointing to I think the answer in the yang is it has to be optional. Otherwise, you end up with strange situations where you report bizarre numbers and so on to try and hope that the client then realizes it's not a real number or whatever. So it can't really be in the yang, but then there's a second then then the challenge has been moved somewhere else, and there's a need for some profiling or other mechanism that then becomes itself normative that explains under what circumstance you can do this, which is a more readily incrementable thing than the Yang is. So it's like a living document rather than a published document. Hope that helped.
[00:47:17] Diego Lopez: It might I thought it was helping at
[00:47:19] Benoit Claise: the beginning, but, yeah, I kind of forgot my even my question. Sorry.
[00:47:23] Jan Lindblad: No. Okay. We could take
[00:47:24] Benoit Claise: it offline because right now Yeah.
[00:47:26] Nigel Davis: No. It's it's it's
[00:47:27] Benoit Claise: description good job. In Yang, and we could not say it's a normative reference to the profiles or whatever guidelines you have. Yeah. So we have to be bit pragmatic here, and I don't have the answer, so I would like to hear from you.
[00:47:36] Nigel Davis: It's bigger it's a bigger challenge. I'm happy happy to participate in that discussion, obviously, because I've had some background in it. So okay.
[00:47:43] Rob Wilton: Thank you. Ben, I'll just make a quick comment. I would suggest in the yang, you have the the requirement, as in you must do this or you should do this, and then the the extra description of what that means and the and the constraints that goes in the documents. That's the split I would put in.
[00:47:59] Tony Lee: Hi. Tony Lee. You've got instantaneous power as an int 32 right now. Do you actually have a use case for negative power? Outside from science fiction.
[00:48:22] Benoit Claise: I don't see one. Actually, were thinking
[00:48:28] Tony Lee: Well, then that would seem to be under energy delivered.
[00:48:34] Benoit Claise: Yeah. I good point. Okay.
[00:48:37] Tony Lee: Thank you. You uint32, please.
[00:48:43] Rob Wilton: I
[00:48:45] Benoit Claise: see good point. Now we were discussing Yan on what to do with let me see. In the case of PoE, we're we're killing. No. Okay. Forget about that. Okay. Point taken.
[00:49:03] Presenter: Right. So from the from the tester perspective, I'm always a little bit worried about optional attributes because there are multiple reasons why optional attributes are not filled. Sometimes the data is not available. Sometimes somebody doesn't want to share it. And I think the whole story of the green working group is around getting telemetry first, getting it correct, then optimizing, then reducing energy consumption. And so I agree, putting something optional is great to accelerate adoption. But in the end, it might be detrimental. So is it possible at all in IATF to put an expiration date on something optional to say that it's only optional until this date? That would be awesome. Probably, it's not. And so that's one comment. I don't have a good solution, but I think optional is not really good. You know? You could we could make it maybe conditional to say, like, if if your device does have the opt option, the opportunity to measure instantaneous power, then it's mandatory. Right? You cannot just say, like, I deliberately don't want to share it, you know, although I could. And the second point is also about
[00:50:19] Benoit Claise: Can I just answer this one? Yep. So I agree with you. It was my first reaction when I saw a young module, which is, like, everything optional because it's so easy for vendors, implementers, NMS, whoever to say, comply. I don't do anything, but I'm compliant because everything is optional. So this is why we concluded that if you report it, it must be if you can measure it, it must be available, which is a kind of trade off. I will my first reaction was, are one of these one of them mandatory? Why? Because what I see from multiple operators, they they they go with the smallest common denominator to for their use case. So now what they have to do is that they have to ask all their vendor, right. It's optional. Actually, do you report the nameplates? Do you report in service? And they need to go back to the vendor to try to see what they support or they have even worth, they have to test it themselves. So but I'm not going to try to impose something for all the vendors. I just talk to operators. That's what I see.
[00:51:25] Presenter: Well, I think I would I would nudge them with this extra attribute saying, like, does this device have the the feature to measure the power consumption? And then the vendor, if they want to cheat, they'd have to actively claim no there, which would basically defeat their data sheet probably. So you probably get correct answers there. And then the the attribute instantaneous power automatically becomes mandatory. Elek, it's a conditional one. Right? So the second point is about nameplate power. At our interop events, we always ask the vendors to share the nameplate power so that we can calculate how much power do we need for the whole event. And it's so much off, it's basically useless. And so most vendors actually don't have a clue. And I don't know at which level these objects are going to be used, but if they're used on the level of, like, a a router, yeah, not of, like, a line card or a a fan, then it's very hard to calculate it sometimes because it really depends on all of the components that are pushed in. Of course, in the pizza box model, easy. Right? But in a modular system, if you have the two power supplies, if you have the 300 or 600 or 1,200 watt power supply, blah blah blah, there are so many options. Yeah. So I'm not sure if that's if it's a good idea to make that one mandatory either, if it will really help at all because it will be, from my point of view, a mostly useless number.
[00:52:45] Benoit Claise: It's a planetary sub channel. Okay. Look, this is nameplate question mark optional.
[00:52:52] Presenter: But you you that was one of the suggestions.
[00:52:55] Benoit Claise: Alright. Yeah. Okay.
[00:52:56] Rob Wilton: Can I just make a quick comment on that? Just know this model is very generic, so it can be reporting components all the way through from the full router down to the line cards to individual components. You might be able to report instantaneous power on some of those, but not others. And the model needs to have to cope with both of those aspects. And you can't actually, yang, express that level of constraint in a sensible way.
[00:53:22] Tony Lee: Hi. Tony Lee. I'm an evil, greedy hardware vendor. And we've got some serious problems trying to do instantaneous power for every component in the hierarchy if we wanna be complete in our reporting. There is no regulatory power in the IATF. You don't get to set laws. You don't get to throw us in jail. So if we don't like to report a number, we're not going to. And this is true for all vendors, not just my employer. And we've seen this because there are lots and lots of people reporting different numbers. Now it's absolutely true. The nameplate power is not particularly useful. Why? Well, because when and how you measure that power is extremely significant. K? My particular employer happens to measure worst possible case power. Now that means power at 40 degrees c ambient and zero airflow and worst case humidity and yada yada yada. Okay. And and so that power is not particularly useful when you drop it in the middle of a data center. It's a different thing. If we wanna talk about that, we can. But if we're gonna report something, the nameplate power is the best thing that everybody has.
[00:54:52] Benoit Claise: So so, Tony, the question to you. So if you had to implement this yang module and for a specific component, you cannot report in instantaneous power. Right? Fair enough. Would you even report an entry for this?
[00:55:07] Tony Lee: I would like to report a nameplate power because it's the data I have. I would like to be able to say, right now, it's actually probably doing about x watts, but I can't really know that because I'm I don't have temperature sensors everywhere. And, yes, the temperature varies within a chassis, so it matters a lot. So it's really, really hard without additional instrument instrumentation to say exactly what's going on. So it's kinda tough. Okay. Okay.
[00:55:50] Benoit Claise: So there is one oh, okay. So
[00:55:56] Nigel Davis: just on the the the suggestion of an additional attribute just to say what you do and don't support. We did that in gym forum and and we had lots of additional attributes all over the place, and it became a big mess because every single attribute ended up needing something like that. So that's what then led me to that notion of a specification that then says what you do and don't support that then gives you a it's like a profile again, essentially. And then that just on the the other comment about not wanting to support not wanting to report certain properties, there are situations where a value might be significantly proprietary and may give away something important about your solution. Know we have some of those things in the optical space where I know my company doesn't want to report some values and some capabilities because they are very sensitive. So yeah, it might be a bland value to somebody else, but it's very important one to us. There also very subtle cases where you're not although it's being measured, you're not reporting it under certain circumstances. So there's significant complexity in that. But but just back to the original point I was raised a handful, I think having additional attributes is not a not a good idea in itself. And I think having more of a specification would be more sensible. And that brings me back to that modeling boundaries draft I put in a couple of years ago and then let expire, which started talking about uncertainty of measures and all sorts. I I know the value is somewhere between this, but I don't know precisely or I have some idea based upon other measurements. It might be this or whatever. I think that's something we might wanna go and look at again, how to express uncertainty in a value. So I've got something, but not fully what you need.
[00:57:40] Rob Wilton: Nigel, would it be I'll take this one to the list? Because I think time wise, I don't know how much
[00:57:44] Nigel Davis: No. No. Sorry. Left, Ben. No.
[00:57:45] Benoit Claise: Sorry. So it's a question to you. So we're supposed to share presentation for five minutes for Jan. I could stop here and have this issue resolved, We're trying to resolve the other one on the list, or we resolve the issue first. Your call.
[00:57:58] Rob Wilton: I I think we take this to the list. I'm not sure when to resolve it here now, so I think we need more discussion on it. If there's anything more you've got to present, get that done, and then we'll give Jan five or ten minutes.
[00:58:07] Benoit Claise: So it's two issue, and maybe we're going to start a discussion on the mailing list. The first one is about the accuracy discussion. And, Jan, if you could lead this on the mailing list, that would be great because you are the one behind the identity ref on the right hand side. So that's something that we want you to to discuss. And the last one is one or two energy unit multiplier. So so far, we have one for energy, and the unit multiplier is available for the consumed and delivered. Right? It's the same one. And we want to understand if there are use cases where what you need to consume or deliver is significantly lower or higher than the other one, and we need to have two different unit multiplier. If we don't have this use case, if we don't hear from you, we keep a single one. These are maybe the two things on which we're going to start email threats on the mailing list. Sounds good?
[00:58:57] Rob Wilton: Okay. I mean, we I think we can get back an extra five minutes probably. So if you want to cover these in any more detail does anyone want to speak to these either these two slides now? Questions? There is a couple of minutes left, and then we can give Jan another five minutes. That's five minutes is enough. Yeah. So otherwise, it may be that people need to actually read these in detail to actually think about them. Anyway Fine. Okay.
[00:59:19] Jan Lindblad: Thank you.
[00:59:20] Rob Wilton: Thank you. And Jan's Jan's coming up. Are you on the safe side deck, are you? Yes. Okay. I think you have about five minutes.
[00:59:35] Jan Lindblad: As you may have heard it a couple of times, five times or so by now, we are starting up the work on this drafts, the green controller yang. There are a few x's there, x x x x, that's where we usually have an initial for who is participating in this work. And I don't know who's interested to participate here, so I just put x's there for now. But if you are interested in doing anything on the controller side, yang model work, now is a good time to let me know that. Okay. So you saw this slide already where we had this four work streams or work items one, two, three, four, and the two and three were about the device side work. That's what we have been talking about all the way until now. But now let's talk about work item one, which is on the controller and number four is also on the controller, but it's not in scope for today. So what are we going to start for the controller level yang model? This is what I think should go in that yang. And if you have things that you think should not go there or additional things that we do not have on the list, that's also a perfect input to have at this point. So I think that this controller needs to have an idea of where to collect it's gonna collect data from some things. It's gonna get data from a lot of different devices and components and so on. And I think this controller will need to have a list of where to get data from or things that it needs to reach out to to subscribe to or expect data from. It's not gonna just somebody sends it some data, it's not gonna include it without knowing what it is and where it came from. It needs to know that. It's we'll also need to know what sort of mechanism it should invoke. Is this yang push? Is this SNMP? Do I really need to run whatever? It needs to understand how how often should I collect this? Which and also, which metrics should I be including? Should I I don't wanna pull everything that's this device has for energy and power. I wanna measure certain things specifically. So that's all the things that I think should go in the control Yang model. And it appears that many proprietary solutions are already doing this. That's why I think this should be included here as well. And other use cases that we want this data that we are collecting to be auditable, that you can report it to, let's say, the EU Commission or something that has in ESRS report or something like this. And auditors, they would need to they always go, okay, this number that you reported here, where does it come from? Okay. It's the sum of those things. Good. Okay. Where where do you get that number from? How do you know that? So you need to be able to trace back, audit trail all the way back to the source and be able to prove basically. It's not the auditor is not gonna check every number everywhere, but any number anywhere must be defensible. And I think this audit kind of work, you get getting the trail backwards would be very difficult if we didn't have this list of where we collect from. It is, of course, possible for us in this room here to decide, no, we don't standardize this. It's up to controllers to figure that out themselves. We don't have a standard for it. But then in that, if we decide that, the audit use case is probably lost. We cannot do a standard way of auditing stuff anymore. Alright. So We need to configure sources and collection methods. We need to have some sort of idea about ID correlation. The devices are talking about themselves and describing their names in some way and their peers and I'm connected to and line cards and so and ports so and so. And the the controller might have a slightly different terminology and we need to be able to map those things. We will want to as Benoit has asked me to refocus the work here. I if you remember, if some of you have been in my presentations in this green space five years ago, you know that I have a very big concept of what needs to happen. But we supposed to do here is a more of an MVD, minimum viable draft that we can have something to build from. So but we then need that means that we will have only a few things, but we need to understand where the extension points are. If you want to, you can augment here more types of measurements and more protocols and more device types and so on. Okay. Besides collecting all the data, we need and and figuring out which metrics to collect, we also need to understand what we do with this data. We need to do some transform of it. For example, doing averages or sums or finding the peaks. Such transforms is something that this controller would be doing in my mind. And we would also need to configure, okay, I got this data, I may have transformed it a bit, but I also need to push it somewhere. Either storage in, let's say, in time series database or put it to another controller or something like this because you can't just hoard all all this data. And for the audit use case, you're not doing collecting any more data, but it needs to be possible to read the providence data and this metadata that we have follow collection graph, where did all every number come from, how did you arrive at it, and also compare with the inventories to see that do they actually collect all the data or are the holes here some device I forgot, or is some device there twice? That's also Does it make sense? Are we missing something important?
[01:05:29] Rob Wilton: So we're sort of out of time. Is is that your last slide? You're another one from the long
[01:05:33] Jan Lindblad: I think this is it.
[01:05:34] Rob Wilton: Oh, fine. So so I think we could take comments and things unless there's anything quick people want to say to the list. I would encourage people who want to work on the sort of controller aspect to to reach out to Yan and others and on the list and things to see and get more people who who wants to work on this. I think it'd be useful for people to understand, get a read of whether they think that the what's done in green for the base model should be focused just on the energy and power attributes and the other aspects in terms of provenance and things left out of scope or not. So I'm gonna start a poll question. So the question is, should the base network controller be scoped to to include more than just the power energy attributes? So if you think we should just do power and energy and keep this very narrowly scoped, please vote no. If you think we should incorporate, like, the why, the thing about what the, the other ones that Jan has mentioned in his last couple of slides, then vote yes, please. If you if the question is not clear, just say no opinion. Okay. So I would normally ask for what the no objections are. I don't think that makes sense on this poll here. I think that gives you a read that actually there seems to be support for covering the other things you want. But I think be careful with with your initial draft. I would focus on the power energy first.
[01:07:16] Jan Lindblad: MVD, I know.
[01:07:17] Rob Wilton: Yeah. Okay. Okay. Thank you. Thank you. Next up, we have Petra, which is Luis, I think.
[01:07:42] Luis Miguel Contreras Murillo: So I I will provide an update on on on this API that we call Petra, which stands for path energy traffic radio API. Originally, this was the the name that we provided, and I will do it on behalf of my colleagues, Alberto, Marcelo, Jan, and and Andrean. So very briefly, for the sake of time, the the motivation, just a refresh for the for the working group was to work in an API that could consume, could retrieve information from the network and then expose that information for others to take actions. Those others could be management entities external to the network or could be SD WAN customers or so, so just informing them in such a way that they could use for their own purposes or also internal consumers that could be management entities for optimization or whatever other purpose. So we are positioning on on top of the green framework in in the figure. So maybe after seeing Jan's presentation probably, it could be even on top of the of the controller. So, basically, consuming what the controller aggregates and and basically retrieving that information and exposing outside. So we have presented several times here. I I I will, as I provide an update and just recommend that there there is another document in sustained energy sustained energy where basically it incorporates further parameters that are out of the scope of green charter. So the positioning of of of Petra, again, as a refreshing here, we could consider Petra as an API for either the customer service customer service level or service level or even network level. So, essentially, the purpose here is to be able to retrieve between some endpoints, the information of energy consumption related to that the paths that are basically connecting these endpoints. On on your right, you see that the the position of of of Petra in in regards to the framework would be basically consuming the information that the controller could generate, but also maybe even complementing the information with what's called network domain level in the framework, but we are reviewing, revisiting the that definition. So, of course, we need to adapt the the the PETRA document as long as we are evolving the framework definition. So going now towards the changes in this new version, we basically remove all the parameters that are out of the scope of clean working group, things like carbon intensity and and so. So, basically, that will pertain more to the to the sustained RG. So we remove essentially all that information from the API, from the model. We also work in a generalization of the model. At the beginning, the model was basically applicable to IP endpoints, so we were working with IP addresses. And we have extended this so we can consider not only IP addresses, origin, and destination of the path, but also prefixes so that we basically could report the the energy information between different sets of of prefixes, typically, BNGs and and so. Also, MAC addresses, so working in layer two connectivity. And finally, well as slice service service delivery points as defined in in this for the network slicing work. Probably other extensions could be could make sense here thinking on on CCAM in optical paths and so, but so probably we will revisit this and and trying to be as as generic as we can in in the next versions. And finally, we also added some parameters for traffic characterization in terms of throughput and and volume. We had internal discussions if for throughput seems to be something evident to to have the the information per per throughput, but maybe it could be also interesting to have per volume so that, basically, we associate the consumption for an aggregation of traffic along the time in a time window, essentially. So as next steps, we have the pending to, of course, to to work in the consistency with the green framework as as mentioned. So Melissa presented the green framework is being refined, so we need to keep alignment with that. We one of of our initial ideas was to support incentive scenarios. So not not only considering s l SLAs, but also ways of incentivization incentivization for a a better usage of a network resources, in this case, the the energy. And so we will, yeah, keep thinking on that and and see if we can incorporate something in this respect. And, yeah, we see more or less the the the draft is somehow we have presented several times. It seems to be somehow solid to some extent. So we would like to request working group adoption as an exemplary API that could be connected to the framework, reviewing information from the controller maybe, and and basically helping us to expose this information to others to be consumed. That's all from
[01:12:46] Rob Wilton: Any questions or comments in the room? So none. So I'm sorry. I haven't sent any comments to this draft unless I did have a chance to review some things. It looks very simple, which is good. I think I had some questions about there's no dependency on, like, the topology module, but I think that makes sense because this is more an external API to either a web interface or web HTTP API. That's the thing that makes sense. So I think we're at a stage where it'd be good to check for interest. So I was going to do a show of hands to see who's read any version of this PetroDraft. So I'm not sure it matters who read the latest one. So I'll start that poll. Please vote yes if you've read any version of this document, or no if you haven't. So maybe fiftyfifty. Not about a dozen people ish.
[01:14:02] Diego Lopez: Somebody changed.
[01:14:05] Rob Wilton: Had read it, but they haven't. They've forgotten it, so that's fine. Okay. Once, and then we'll do one for adoption. And then the next question is whether you think the working group should adopt the PETRA draft, at this time. Think the clarification here is if we do adopt this, the focus is still to remain on the existing core deliverables and the existing progress in parallel. But I do not want us to see a sort of getting dual to a new shiny thing. So the numbers seem to line up fairly closely with the numbers that actually read the documents. And maybe the the folks who read it, they're like, yes, we should adopt this and the ones that haven't like, I don't know. That's certainly a possibility. But I think that that shows that there is some interest here. So who is voting no if they would like to if they got an opinion and want to oh, it's gone. Fine. So I think we'll take this to the list and see if there's interest in the list. I think that's good enough. So
[01:15:32] Nigel Davis: thank you.
[01:15:32] Diego Lopez: We we had no no. Since you asked Yeah. And I asked and
[01:15:35] Rob Wilton: They got scared. That's Yeah. Exactly. Thank you. I think Mehad's up next, hopefully. And the slides where's the slides? It's it's not green improvements. Is this it must be this one. Yes. Sorry. Alright. Here's a click for you to control. We're slightly behind, so I'll give you probably nine minutes. Hopefully, that'll be alright.
[01:16:21] Benoit Claise: Okay. Oh,
[01:16:25] Rob Wilton: I'll get rid of that. Oh, no. Let's try again.
[01:16:32] Luis Miguel Contreras Murillo: Okay.
[01:16:34] Mehad: Okay. Great. Sorry. Hi, everybody. I am presenting an update on YANG data model for reporting utilization score in ISAC. So this is basically a use case YANG data model, and it's related to integrated sensing and communication. Integrated sensing and communication involves sensing of the environment using radio waves and other sensors. And those sensors, the overall system, it consume a lot of energy, compute, and memory resources. And so the the utilization of how much is energy is consumed, for example, needs to be reported to the controller to make some energy efficient decisions, basically. So I think that's why we thought that, you know, to to have a young model specifically for ISAC utilization. We had presented this module in in in which we have considered a utilization score, basically, related to compute energy, memory, and storage, etcetera. We have an overall utilization score, and then you optionally, you can have multiple components that are such as energy, power, memory, etcetera, and some metadata with that, basically. And now in this update, I think we also had last time as well. So we augmented the the power energy Yang module and with the with the energy object with ISAC. So, basically, the energy and power module in the ISAC Yang model remains the same, but you augment it for the for the I ISAC utilization, basically. So this could help the controller to to basically say that where energy is consumed and how what is related to ISAC, basically, to yeah. And I think I would like to have this discussion and consideration with the working group that whether this augmentation is the right near term integration pattern for ISAC. And does this make sense, actually? And should the future work expose the software services scopes or other references, basically? And I think with the controller yang model, I think it would be nice to have, like, for the for the use cases as well. Right? For each use case, what kind of the decisions that controller or data the controller can collect and make decisions based on that. So, yeah, this is what I have, and I would take any questions someone has.
[01:19:44] Rob Wilton: So any questions in the room, first of all? No. So in I I need to review the latest version of your document. I think in terms of the direction going in terms of the augmentation, that that that, a certain level makes sense to me. It's like the that probably makes sense. I need to think about it
[01:20:02] Luis Miguel Contreras Murillo: a bit more. Be good to
[01:20:03] Rob Wilton: get the experts who are doing the actual device and the controller level models to come to that as well. And Yan actually is at the mic line. I'm sorry. Okay.
[01:20:13] Jan Lindblad: Yes. You have a question there whether this augmentation mechanism makes sense for your device level, and I think it does probably. If you found a natural place to augment, it's very likely that it is a good idea. I haven't seen the latest version, though. And when it comes to the controller level, of course, it sounds very good, very interesting that you would want to have a service level concept there. The the model that we were talking about a minute few minutes ago was mostly configuration for the controller itself that tells the controller, what am I supposed to do today? And what you're talking about now is probably a service level API that's going to some sort of other client, but it sits on the controller or something. So it's it's related, but it's not the same thing as the thing. So it would be interesting to hear more about what you want to have
[01:20:56] Presenter: on the service model here.
[01:20:57] Mehad: Yeah. Yeah. I would keep these two as separate as well. Right? So the controller and also the the the services on top of what you have, basically. But I think the natural extension would be like, if if if you're working on a controller model, then so how does control model that you come up with fits with the data collection that is related to specific test use case, basically? Makes good sense. Yeah. Thank you.
[01:21:27] Presenter: So do you want to document here the additional power consumed by the sensing function only or the total power of a radio access network component, for example?
[01:21:42] Mehad: So yeah. I mean, I can only know about the sensing function if you consider the service based, you know, the reporting of the consumption. But in this case, it would be linked to, for example, what they have, the the how the hardware or the component hardware component actually reports energy consumption. Right? So how to link that hardware energy consumption with the with what sensor is actually sensing. So it would be specifically linked to the sensors, not the whole radio access network. No.
[01:22:26] Presenter: And how confident are you that it will be possible to determine this add on component of power consumption?
[01:22:38] Mehad: I I don't know, actually. So if if we are able to know that which service is running on what hardware, then it would be possible in that case. But if we cannot, then, yep, maybe not. But that's the whole point of of bringing this to to the table to discuss that whether we can do it or not, basically. But this linking of service with the hardware, I don't know if it is our job. This is an implementation specific.
[01:23:10] Tony Lee: It's I'm
[01:23:13] Presenter: not sure. I mean, when when we look at RANs and ISEC components in RANs, of course, you can say, well, sensing takes power. It takes additional effort. But if you're running the network at full scale with all of its components, all of its nodes, including capacity nodes, etcetera, during the day, you could say, well, it doesn't take any add on power because it's running at full full speed, full function anyway. But during night, operators would normally disable some components, reduce the MIMO rank, turn off capacity sales, change anyway, so many many RAM features. And at that time, you can say, well, if I keep my components switched on just for the purpose of sensing, although I don't need them for the actual communication part, then suddenly, the power consumption of the sensing component increases quite substantially, although the total power consumption of the RAN doesn't change at all. I think But it's this is a derived figure, which is very hard to find out because the mobile operators, MNOs, are now struggling to see how much power can they save for the communications part. So it's an unknown figure that you're basing against.
[01:24:24] Mehad: Yeah.
[01:24:25] Presenter: I think it's it's a very difficult metric to report.
[01:24:29] Rob Wilton: So this is a great conversation. Can you take these onto the list as well? I think it'd be good to continue. Yeah. Yeah. Sure. I would like to give a couple of minutes because I want to again just get a read of the room in terms of how many people read this and whether because you're interested in trying to get this work adopted, I think. Yeah. So I'll ask a couple of polls first. The first one is whether you've read any version of the ISAC utilization draft. Check that out now.
[01:25:17] Mehad: Someone has no opinion.
[01:25:24] Luis Miguel Contreras Murillo: Two people.
[01:25:24] Rob Wilton: Maybe my my question wasn't very clear, but I'm not sure you have any opinion about whether you read something or It has. It's been a long day, though, and that's normal. So I think I don't want ask for an adoption whether you want to adopt this now. I think that that we want more people to read and review it. So if if anyone has some spare time this ITF week, your participants here, please can you have a a look at this document and then provide some comments on this and things? Because I think this is some interesting work, and I would like to see it progress. We'd like to like to get some more reviews and comments on that document before we take a bit further forward.
[01:25:58] Mehad: No. Thank you. No. I I just want to say that, you know, I I just wanted to I have been waiting for the progress on the yang model to see how this pans out and then augment it for the specific specific use case. So that's why I bought it here, and I would like people to comment on it or read it, and then, you know, definitely, that will be helpful.
[01:26:18] Rob Wilton: And you're completely welcome to continue that approach, continue presenting the updates and things like that, and then say, actually, now's the time that we think it's ready to adopt. But but we can, as a working group, choose to adopt the work knowing it's waiting on other things. That's okay as well. Yeah. Definitely. Possible.
[01:26:33] Mehad: Okay. Thank you very much.
[01:26:34] Rob Wilton: Thank you. Yeah. Bye. Providence? Yes. Brilliant. Thank you. Yeah. Probably eight minutes. Oh, yes. Sorry.
[01:27:04] Marisol Palmero: I'm going to introduce the new draft. It was just released, it was kind of in a hurry. But we wanted to have the draft released because we wanted to introduce a use case in the hackathon. And I will comment on the motivation as well and what we did in the hackathon. Even there is more to do. Right? Basically, in OPSAWG has been introduced many times already. It's already in a few ideas, the provenance draft. And what this draft covers is an extension of the use case for the provenance draft. The provenance draft basically is introducing one data JAN data is this provenance signature that is signing telemetry data. Right? It is signing but could be signing by the microservice, how they have been implemented, and could be signed in the device or at the controller. One of the things that you might catch as I receive already feedback we receive already feedback is is this green provenance draft controller based data model or device based data model? The green provenance draft is a controller based data model. This needs to be clarified as well in the draft. It brings five leaps. Right? The provenance key ID that will be the entity that has been signed sorry. It's the key sign the key ID that signs the data that is to be stored in the data store. The key owner who is responsible for that data, it could be the device or the controller. If it's device initiated or controller initiated, the the sick who has been signing this data. And there is a a new new identifier there, traceability verified. If is this if it has been verified or not. The key owner type is an identity ref that can be extended, but it introduce an interested point for green use cases. It could be an external certify certificate association that might have been signing externally that data. The data could be signed by the device. It could be signed by the controller or could be signed for this interoperability by other providers of that in energy. And this is an example that I will address as well. Issues that needs to be fixed in the current version, that's why I say it's needed version zero one in there. It's not an augmentation of the green YANG data model. It is probably a grouping that needs to be in the controller JAN data model, but the controller JAN data model doesn't exist yet and needs to be included in there. And it brings this traceability concept about, you know, who has been signing this data and who might be responsible for that. And because it's bring it brings as well this time when the data has been signed, this is helping for the use cases that Jan has been highlighting who has for for for the audit of the the the use case itself. About the motivation, I highlighted in the draft a few use cases. There is a typical one when the device sent an energy data power energy data, and this can be signed by the device itself, and the collector just verified that information. We have been testing this in the hackathon. Even it has been everything more or less based on the mock up and the implementation from the provenance draft based on the microservices. I would publish the this information and share as well in the alias what it has been how it has been done as a step by step guide for you to check as well. A second use case is when the device might not have this Jam provenance capability and the controller will sign that data. And the verification could be done by another third party third party and another controller, but it is just, you know, that a stamp that that data is trustful and, you know, who has been signing the the data. This use case, we introduced last week. Some of you has been in this workshop where Power Grid meets the Internet, And it got some attraction, right, some interest as well. And this is, you know, a typical use case, the data center with all the AI discussions today, who is giving this green energy and which percentage of green energy. I mentioned before about the regulation, and I think this case this use case is quite useful as well because there is these discussions about discussions and and legal legal implications to avoid greenwashing on the renewable energies, and this needs to be reported today hourly. Before it was everything manual, and it needs to it needed to be yearly. But today, this consumption and
[01:33:09] Emile Stephan: what
[01:33:09] Marisol Palmero: the power grid is giving you as renewable energy needs to be reported hourly. And here is where it meets, you know, what is consuming data center and how this consumption is is done from the networking part as well.
[01:33:21] Rob Wilton: And You have a question. Just take it now at the end. Sorry? You have a question. In the queue, yours to take it now at the end.
[01:33:29] Marisol Palmero: We can take it now.
[01:33:31] Rob Wilton: Two questions.
[01:33:32] Ben Curtis: Yeah. Hi. Ben Curtis. Related to the draft as it stands today, there's a recommendation in that draft for if the signing does not occur in the verification, that that data should not be used for any reporting controller accountability. Could that potentially cause problems with systems that aren't currently set up to leverage that accountability? For instance, if you need to report on utilization of energy overall, but suddenly assigning element breaks and it causes a ripple in the chain, should that be defined in a different way for reporting versus not included in reporting? And I can bring this to the list if that makes more sense. But
[01:34:15] Marisol Palmero: I think we can take it in the in the mailer, but I will need some support from the provenance as well. And I see I check on you.
[01:34:26] Jan Lindblad: The the
[01:34:33] Diego Lopez: the problem is that to the is is that to to define who's the source of what you are you're signing. So the the the provenance stream can hold whatever. The point is that then when you are going to use it, you have to decide in the in the application environment of the the goal that you want to do, whether it's about to identify a particular source, or would you want to verify a particular source of data or a source of energy that probably will be the the two difference. That is up to you because you have to verify the signatures and verify that that corresponds to the appropriate element. So Okay. Invisible, it will support both.
[01:35:15] Ben Curtis: If it helps for clarity, I I work in data provenance and auditing. That's why I'm asking the question. So if there's also interest in drafting anything that is related to the standards by how that auditing should work, especially in private zero knowledge environments, I'd be happy to assist with that as well. So
[01:35:30] Rob Wilton: thank you. Out of time. So Mahesh, do want to if you take your questions to queue to the list, that was useful as well. Mahesh, you've got time quickly as an AD.
[01:35:39] Mahesh Jethanandani: Alright. Mahesh, so you had that slide that is talking about green governance versus the ops area working group.
[01:35:51] Marisol Palmero: The first one?
[01:35:52] Mahesh Jethanandani: Yeah. That one. So I guess maybe I'm not quite getting it. Here, you're saying the green provenance is about controller based Yang model, whereas
[01:36:04] Diego Lopez: I think the ops area, the other document is about
[01:36:09] Mahesh Jethanandani: device and then our controller. I don't know. Both use Cozy signatures over Yang. So I I I don't know if just the fact that one is being implemented at a controller level, the other is being implemented at a device slash controller level is a distinction for really distinguishing the two work into different working groups.
[01:36:33] Marisol Palmero: Yep. I have a couple of comments on that, but probably. What did open my eyes, you know, when we I was looking to the provenance draft. This provenance draft from is only signing the data, and we are using that
[01:36:51] Luis Miguel Contreras Murillo: from the
[01:36:51] Marisol Palmero: controller. The controller could sign those data, and it will need this draft, the opsa yam provenance. But if you want to verify and to trace these these date the data, you will need to have the controller base. Probably, it's more generic than just green, but where to start this work? Should we go move this draft to OPSA? Should we keep it here, or should we move it to somewhere else? Because it's a generic issue. Right? It's probably not a use case from Green, but this is how we have been started many of the conversations in Green.
[01:37:26] Rob Wilton: I think we should cut this conversation now, but I think it's a good conversation to have. My understanding was this is an incestation of the other draft, like using that preference draft in a use case. It sounds like it's a bit different, so we should chat a bit more. Right. We'll move on, actually, because we're out of time.
[01:37:41] Marisol Palmero: Yeah. I am done. There are open issues that we need to address in the next version. And yeah. I think it's
[01:37:48] Rob Wilton: Luis, I think, is up next on PIM eco mode. Fine. We won't tell.
[01:38:07] Luis Miguel Contreras Murillo: Yep. So I I will go now through this draft. This draft is from Ping Working Group, but but when I request a a a for the chairs was basically for for having the feedback from green. I'm basically, yeah, looking for this cross pollination between between the work, but basically for for having feedback from the working group. So the idea that we are moving into prem is to provide some extension to IGMP/MLD signaling once the the subscriber wants to to signal the the subscription to a channel to a content. So, basically, to include in that subscription some way of signaling echo mode. So, basically, sensitivity to energy efficiency delivery of the content. So the rationale for for the the work is basically the video represents majority, at least till now. Let's say with the AI, but till now, the majority of the traffic in the operator's network is due to video, to content. So, basically, when the subscriber request a content, the the source of the content tries to deliver the maximum resolution, the maximum quality as possible. Right? But it could be the case that maybe the the user doesn't want basically that because because of the resolution of the screen, because willingness of the the customer to receive the the content with in a more energy efficiency way. So, basically, here, the idea will be to allow this extension to a GMP MLD so that we could include some signaling of echo mode in the delivery of the content. So for that, we are leveraging on RFC ninety two seventy nine. This RFC defines a mechanism for extending IGMP/MLD. As said, this is the signaling protocol for for the subscriber to a content to to signal the willingness to be subscribed to that content. And these triggers are the a number of actions in the multicast side for creating the multicast tree in case that the multicast tree does not reach the the MLD device and and so on so far. So, basically, here, point is that this signaling could be consumed in different parts of the network or even be consumed by different devices, the set of box or or the TV or I mean, there will be potentially several consumers of it. So the the IMP and MLE, for those that are not familiar with that, support, let's say, different kind of messages, the query message and the report message. It depends if it is triggered by the by the subscriber or if it's triggered from the network towards the subscriber. And, essentially, here, they'd be able to the same extension for both of them. So, basically, making consistency on that. And what we are proposing in this new version of of the document is the TLB that you can see in your screen. So, basically, capability for signaling some echo level at the time of the source to deliver the the content and also some preferences in that delivery. Then flags and reserve bits are are there for future extensions and so. So what are the the echo mode extensions that we are considering so far? Regarding the echo level, we are proposing and this is an initial idea, of course. So whatever suggestion or or comment is more than welcome. We are considering four different echo levels. No echo mode, so it will be the traditional delivery of of the content as as today. So, basically, also, this could help for I mean, in case that the sources or the IMP the the note that is processing IMP or MLD is not able to process this TLB with would apply this this mode. So now EcoMode essentially is delivering as as today. Then different levels of of EcoMode, like, level where basically the energy saving actions are acceptable in case that there is no impact to the service. Moderate eco mode where the receiver can accept maybe some energy oriented optimizations, like more efficient delivery alternatives and so, maybe leveraging on the information that we could activate through the green framework. And then there is a tech commode where even the receiver is even open to sacrifice a little bit of the quality or the resolution of the content if this improves the the energy efficiency and the delivery of that content. For the preference field, we are defining four different preferences, energy efficient I mean, that would be essentially targets at the time of delivering. And this target will be energy efficiency, carbon awareness. We know that this is is out of a a charter of of clean. As well, the the the third one, the renewable energy preference or any other criteria defined by your operator. So next steps for for draft that that we intend, as said, to keep moving forward in PIM. So the the idea will be to collect the feedback and and test for for green working group to understand how this could fit with the assets that have been defined in green working group. So how the for instance, the framework had consumed that or take notion of this willingness of the subscriber for taking actions in the network. And and, yeah, just to comment that the document will be presented in PIN as well this week. And just as a kind of summary, so, basically, there will be a mechanism for the users to signal the willingness of a more energy efficient delivery of the of the content, and and then it's kind of way of starting exploring solutions for signaling, for expressing the subscribers the the willingness of having a more energy efficient delivery of whatever communication service and that sort for this.
[01:43:40] Rob Wilton: Actually, I think we've a couple more minutes than I thought. So if anyone's got any comments or questions, I'll actually unlock the queue. Didn't I didn't mean for it to be locked. So any comments in the room on this? No. So so I think this is really interesting work, actually, because, I mean, it not sort of video, but unlike the audio where you get this, like, this loss lossless audio services that is a pet peeve of mine that they have no difference to what you can hear, and yet they're using more bandwidth. So I think this whole idea is very interesting. I think it'd be interesting to know from the working group actually here, not necessarily now, what their thoughts of this work is. I presume you you intend to progress this within PIM because it's sort of out of charter here. But I think cross presenting it a bit or updating what the status is, I think that is good. And somehow, I would I would like to know the thoughts of the working group on this sort of work. I think that's interesting. Okay. I had some minor comments on, like, slide four, actually. I think it's pretty time to make some comments. Yes. This one. So I didn't I couldn't differentiate why you'd have a difference if difference for eco level zero and one. As in, I think you'd always effectively using level one. So most sensible devices would surely try and minimize their energy usage if there's no change in service?
[01:44:56] Luis Miguel Contreras Murillo: I said this is an initial proposition. So the idea between zero and one will be essentially zero as as today. The source do anything special for delivering the the content. One could be, for instance, we could take the the content through the more energy efficient path.
[01:45:11] Rob Wilton: Right. Okay. So
[01:45:12] Luis Miguel Contreras Murillo: Not impacting resolution or impacting anything.
[01:45:14] Rob Wilton: But so so is there is a change to the service even if it's very slight? Actually, hadn't seen the legible, and they're fine. And then the other comment I had is on the, again, the right hand side, like, the preferences. I wasn't quite sure where you need all of those. I can't what I what I came up with, like, energy versus carbon. Thought it might be enough and that you would get pick up renewable by the factors to whether you're choosing energy versus carbon or something similar. So, again, I think some refinement at those levels might be good idea. But I think this is interesting. It'd be good to hear about this.
[01:45:44] Luis Miguel Contreras Murillo: Maybe just the difference between one and two, carbon awareness, maybe you could use a nuclear energy versus solar. It will be the number two.
[01:45:53] Diego Lopez: Yes. Yeah. Supposed to be that the
[01:45:56] Emile Stephan: nuclear is not renewable.
[01:45:58] Diego Lopez: No. But this connects as well, again, with the ideas of the provenance and how to verify it, etcetera.
[01:46:03] Luis Miguel Contreras Murillo: And, of course, all of this is initial work, let's say, so open to receive whatever comment I'm suggesting. Okay.
[01:46:13] Rob Wilton: Think it's Jinjie.
[01:46:24] Luis Miguel Contreras Murillo: I I think we have the the hackathon report. Oh, fine.
[01:46:28] Qin Wu: Yeah. Yeah. Yeah.
[01:46:29] Rob Wilton: Do that first. I'll explain the time.
[01:46:36] Luis Miguel Contreras Murillo: Alright. Yeah. So I will try to to brief here brief to be brief here as well. So the the idea was to report what we did in the in the hackathon. So I I do this in the on behalf of the team that you can see listed there in the title. So I'll I will start for what we could not do yet. The ambition that that we had, we we consider as well the the possibility of playing with the fact that so from understanding the behavior of the sleep modes in the routers, we were not able to to do so in this hackathon. And, also, the usage somehow to some to some extent of the jam models that we are not we were not all also able to do to do so. So it's somehow pending work for for future activities. So what what we did here? We basically leveraging our setup in in Telefonica lab. We were connecting to routers, the routers that you can see in the image, basically monitoring the consumption on the link between those these two routers. With a traffic generator, we injected different flows. I will comment on that. And we were taking measurements directly from the routers and also from the smart PDU and comparing it. As I said, it was as simple as that. I said that the ambition was major that we couldn't we couldn't do at this time. So this was the the actual setup. Let's say the logical setup. So we have two routers with different cards. We were interconnecting different different flows or different cards with different speeds. Let's say, basically, one flow of 100 giga connecting two cards of 100 giga, then a second flow, basically representing five times 10 giga in a diff in a different card, and there are third flow, four times 40 giga in another in another card. So regarding the tools that we use, we use the the GUI for the traffic generator, a standard, I mean, commercial traffic generator. We set these three pros, and we were playing switching off switching off the the flows. And then we developed this energy dashboard that you can see on your right. So that basically was collecting the information both from the routers and and from the PDU. I will explain a little bit more what what was represented here. So, essentially, we were collecting the information from the PDU. The one of the routers has two supplies to the power supplier power supplies. One router was only had only one power supply. We were collecting directly, consuming directly the information from the API of the smart PDU. You remember we we presented long time ago a model for it. And then for the for the routers, we were collecting the information directly from the CLI. Periodically running a a an a script collecting the information from that. You can see in those tables the kind of information that we were collecting from the different cards. And, basically, in the graph, we are comparing the information from the Smart PDU and the information retrieved from the routers. You can see a small difference between between both. Well, let me say that the solid lines are the lines for the smart PDU and the dash lines are the the the sumatory of the consumption of the cards. So you can see a small difference about the values. It's about 6%, 10% well, less than 10%. Six 6% depend more more or less. You know? And, yeah, and, basically, it was the idea was to to understand what will be the behavior as long as we are playing with the different flows and so so somehow we start from a needle power scenario, so no flows are active. We get a measurement, and then we are starting to activate the different flows. You see the transition from no flows to flow one active. The flow one is 100 giga, was the red flow that you saw at at the beginning. So you can see one yeah. That the the power consumption needs increase. And then we deactivate the flow, then flow two and flow two plus three. Give me just a chance to come back here. So the the point is, as as you see, the different flows are passing through different cards because we have a a that that green card two times 100 giga connecting to the to the traffic generator. And then from the from that car toward the other two cars, we could not inject more than 100 giga at at the time. So this is why we were playing with these strange figures of having 100 giga, then 50, then 40, so, basically, to to see the the evolution. And and then also we played with the fact of saturating the the nodes, injecting more more gigabytes that the the car can can process. So just to understand if there was also some impact here. So summarizing some conclusions, so there was this small deviation on the results between the information collected from the smart PDU and the device, around 6% more or less. There are different consumption profiles in the different cars, but the trend is is similar. So as long as we are inserting throughput, setting traffic, we are consuming more energy. Probably, it's it's obvious, but somehow we we we are some showcasing that. There is certain dependency on the delivered throughput. In this experiment, more or less than watts per 100 giga per hop. So this means that when we have several hops in a in a network, maybe we can play with that fact of of reducing the consumption per hop. That could be, in some cases, equivalent to the consumption in one node and and so. And and the final point is essentially that the characterization shown at the end will be very dependent on the particular network under analysis. It depends on the topology, depends on the manufacturer, depends on the capacity and the types of links and the pluggables and so on and so forth. Probably nothing new. Nothing that is not known. But what we were basically was trained to exercise that, and and the next step I said would be to work on the sleep modes and to work on the on the young model and, yeah, hopefully for San Francisco or or even before then, we can report to The Middle East. That that's all.
[01:52:50] Rob Wilton: Thank you. I've got a minute left. Any comments or questions on this? I think just one observation I had. I thought it's very interesting that it looks like it's quite high baseload. So even I don't know if the router's completely passed at had no other traffic other than those flows. But when it's just with nothing running, it seems to have quite high load. And it's which I I already knew, but it's still, I think, surprising. Thank you. It's useful. Do we have Jin Ji Yang in the room? Yes.
[01:53:49] Jinjie Yan: Since there is not too much time, I will go very briefly. Good afternoon, everyone. Today, this draft is export of energy consumption information in IPFIX. I'm JJ Yan from ZTE, co authored with Jimmy Lee from Qina Mobile. And I will go first, we want to clarify why we use IPFIX for energy. Since the operators need a traffic correlated power data for energy and per flow accounting. First is the gap in priority time telemetry. Polling cannot capture the dynamic traffic power relationship, and the manual cross data set scenic breaks the time alignment. Transient power spikes missed between the intervals. And as for the IPFIX, native advantage, first is built around flow metering, event driven at the source and energy observation, casually bond to the traffic events with native time alignment. And there's no post processing needed at the collector. The takeaway is is a complement to YongPush, not a replacement for some traffic coupled scenarios. And let's just what's new in the version two and the the green alignment driven by the feedback from the next working group meeting, there's five changes in the version two. First is we added a new section, section five, positioned as protocol specifics payment within the green framework. And at section 5.2, add some telemetry analysis with the young push. And all the six new information elements add is aligned semantically with the green power and yaw and energy yaw module. The use cases are mapped to the green use cases draft, and the terminology is adopted from the green terminology draft. There's key principle is semantic alignment with the green yang module, which will ensure cross protocol data consistency and deploy both mechanisms complementarily. Why true for the right job, not one over the other? And what we ask in the next steps is, first, we wanna ask more reviews and comments on this draft and welcome everyone to discussion and contribution. Finally, we also will keep alignment with the green working groups active Internet drafts. Thank you.
[01:57:15] Rob Wilton: So while I wait to see if anyone's got any comments on this, I when you said the right tool for the right job, I was trying to think this seems to me like the wrong tool for the job. So but the maybe the thing that I don't I don't know why it fixed very well. Is it that you are generating this information when a new flow starts? What's your what's the thing that causes you to generate these these the events out of IPFIX?
[01:57:41] Jinjie Yan: This can be configured in the IPFIX exporter, and this means there are some different trigger ways in the IPFIX, such as the number of the packets, or maybe you can get get your grain related information export maybe per thousand packets. Something like
[01:58:11] Luis Miguel Contreras Murillo: this. But
[01:58:13] Rob Wilton: is it okay. Because the thing I'm trying to understand is earlier on the slides, you say you don't have do it through a periodic cadence because you might miss the spikes and things. Yeah. So it's not clear to me with IPFIX why you wouldn't have the same risk of miss mix and spikes. So with Yang push or, can register for these things to be unchanged. But for something like instantaneous power, it's it's continuously changing the whole time, probably. Even, like, small amounts, maybe you could quantize that and say if it changes by, you know, 5%, then you renotify the value. So I think you could do that with YANG and push and things and still do it through the YANG model potentially. And it's not so it's still not clear to me how this fixes the problems. So I don't I still don't understand from a technical perspective why it's the right thing. So I think that's I think we need further discussion.
[01:59:06] Jinjie Yan: Oh, okay. Because there's time is over, so maybe I'll update in the draft, and I will post it in the mailing list for everyone to discover.
[01:59:17] Rob Wilton: Okay. Yes. I think we have need to have some discussion on this, but yes. Okay.
[01:59:21] Marisol Palmero: Thank you.
[01:59:21] Rob Wilton: So we're pretty much at time. Our five minutes to wrap up is down to one minute to wrap up. So I think, basically, we're just here to say thank you to everyone for coming today. Thank you for the people who've been working, progressing the base drafts and things and for those taking notes today. That's what's been appreciated. So that's also good. And we will I think we're going to continue these online meetings. We'll again, we'll probably put a comment to the list just to check that people are happy with the time with that, but they'll continue. But continue making progress. Please do review the work. That would be good. And then new documents are coming in, and we look forward to seeing everyone either, in person or online in San Francisco in November. Thank you. Oh, no. We have to
[02:00:07] Diego Lopez: we have to
[02:00:08] Rob Wilton: And thank you, Diego, for single Haley winning the World Cup.
[02:00:18] Diego Lopez: It's a long
[02:00:20] Nigel Davis: a day. It has been long time.
[02:00:23] Rob Wilton: And people are chasing me for slides.