Session Date/Time: 19 Mar 2026 06:00
Diego Lopez: Okay, so it's two. Let's start on time. As usual, we have an agenda that's probably going to be totally covered, but we will try to make it as efficient as possible. Welcome. This is the GREEN Working Group meeting. This time is the first time that we have only one session of two hours. And well, the idea is to start with a few reflections on this first. The other, my co-chair Rob is connected remotely. He's eight hours less, right? So we are talking about 6:00 in the morning for you.
Rob Wilton: Luckily, it's 6:00 AM, but I've been up for an hour to prep, so it's fine.
Diego Lopez: It could be worse, but thank you anyway. And I have Luis with me that is acting as a delegate, so in the case that we need additional help on-site. What you have on your screen is the Note Well for the rules that are governing the meetings and dictate some issues regarding IPR and proper behavior. You have seen them very often, but as the security instructions, safety instructions in the planes, it's something that is convenient that you read and are well aware of. These are the rules under which we are doing this meeting.
And with this, introduction to the agenda. We are at the first stage, the first item on the introductory introduction from the chairs. Basically, it's about—well, we will ask later on if you have any comment to the agenda. We need some note takers. Rob is going to take some notes, told me. You, if anyone willing, I know that there are ongoing AI transcripts and things like that, but any help from humans is always extremely appreciated because the AI is not that totally reliable. And for sure, for those of you who make presentations or questions or enter in any discussion, I think that is really important that you connect to the note page and check that your names, your ideas, the replies, exchanges have been properly recorded. This is important because part of the most important part of what we want to record is precisely those interactions. Please take your time. I'm not asking you to take notes of everything that happens, but at least that we are able to provide an accurate record of what has been discussed.
Apart from that, we have been—we will make a short review of the status of the working group and then we are going to work in the same—with a similar structure of what we have followed in the previous meetings. Sorry, one that is focused on the base drafts and the base model, which are, as you know, the main target of the group activities right now. We have three base documents that have been already adopted and the model in which we are working. Then we have allocated some time for an open discussion on this just to—among other things, there are open questions to continue with the documents and the model and to give you a view of how we have been working during this between Montreal and now with the interim meetings. Then we will move on to other documents, other drafts that have been presented. One of them has been around for a while, which is the one on PETRA, and other new proposals that we have on IPFIX, transport, and what's going on in our sister group in the IRTF on SUSTAIN.
Status. Well, I would say that we are progressing well. In Montreal, we agreed on a pattern of working and a set of immediate goals to be addressed. We have adopted, with I would say with a quite reasonable consensus, the documents on use cases, terminology, and the framework. The base model is maturing, and you will see that we are making good progress with it. And for sure, there are some questions that are open and that Benoit will take care of driving the discussions, highlighting these open questions and highlighting the discussions. And well, the idea is that this has been—I would say this has proved to be, this way of work has proved to be productive, effective. And the idea is to continue in this way for the next term until we meet again in Vienna.
The idea is to have a lightweight design team. It's not formally a design team as a describe, but it's a group of people that are mostly involved in these base documents and in the model mainly. And every two weeks, there is a meeting with the whole community. All of you that want to participate and have their say and try to decide on how the work on these documents and the model is evolving.
Now that we have reached this level of maturity—for sure the work is not done—but we are starting a—we are approaching a point in which these results would become available or at least stable enough to be considered mature. The idea is that, well, it's about that we have the opportunity to put some more effort in extended modeling, whatever that the group thinks that would make sense to be considered on top of this base model. And for sure, considering something that has been very important and we will go on this in a moment, is how we relate what we're doing here with what is happening elsewhere on energy-related—you name it—routing, service evaluation, application management, whatever. This is something that is important. It's important that we start considering this.
And just to give you an example, one of the documents that is about IPFIX—the group is very much focused on YANG, you know that—but precisely there is an ongoing work that is going to be reported today that is on IPFIX. And it seemed to us that it made sense to start considering this as well in GREEN. And well, apart from that, Luis is here sitting to my right and thanks to all of you that are far, far away and have connected early in the morning or very late in the evening or in a complicated situation. I suffered this in the past and it's interesting.
All this requires—and this is a reminder that is—and the bold font is precisely as a strong reminder that we need—it's not only about the authors of the document, it's about you all, or we all as a community about review the documents, make comments, and progress in the consensus formation and in increasing the quality of the document. All the documents that have been adopted—adopted means, just as a reminder as well, that adopted means that the group believes that addressing what is considered there makes sense for the group and it should be one of the results of the group—but they are far from being complete. And the idea is that you keep working or keep reviewing and making your comments and helping us in making something that makes sense. And in particular, the YANG base model is close to completion. We will go very soon, if everything goes as planned, for a call for adoption, and you are expected as well in particular to review that document and make your comments.
As I said, one of the issues apart from this good progress that we are making and that we plan to continue working in a similar way as we have done since Montreal, there are certain some issues with the outreach, with the relationship of what we're doing here with what other groups are doing in different areas, including energy measurement for application considerations, for routing, for quality of service, etc. It's something that is going to—has happened and it will continue to happen because it's natural. Whatever we call it—we are talking about sustainability and carbon footprint or energy measurement or energy control—it's going to happen and it's natural that it happens. And we have had, as I said, interactions inside the IETF and as well outside. Recently we had a conversation, for example, with the World Wide Web Consortium on their plans for sustainability. And well, that's perfectly fine and as I said, totally natural.
As a group, we don't intend, and for sure we can't decide how these energy measurements can be applied and which are the rules that—or how this information can be exchanged in different protocols by different means, or how they could influence algorithms or procedures or whatever. But what we would like—and this is something that we have discussed, Rob, Mahesh as our AD, and myself—is about that we try to keep, and we think that it's natural that we keep the core reference for energy measurement and control. It would not make sense from a point of view, at least within the IETF—then we would have to convince and liaise probably with other organizations—but within the IETF for sure that what we do here, what we do here in terms of conceptual and modeling of energy measurement and control, should be the core reference. Trying—and what we're trying to do is not to slow down or stop or in any way impact the development of these mechanisms, additional mechanisms considering energy, but to avoid misalignment and potential fragmentation. If we believe—and just to give a stupid example that comes to my mind right now—if we believe that you have to measure things and count the time of measurement in seconds, would not make any sense that we go and somewhere else we are talking about minutes. Simply that.
And well, that's what we would appreciate your help with this. Tony?
Tony Li: Tony Li. Just clarification: does this imply that device management would stay here?
Diego Lopez: Sorry, the what?
Tony Li: Device management.
Diego Lopez: Device management? Yes, if we're talking about the energy device management, we hope so, yes.
Tony Li: Thank you.
Diego Lopez: I mean, what we're talking about, measurement and control include the control of the device, yes. And well, if you have comments, objections, or on the other hand, if you are aware of any activity that we can try to synchronize with, it's something that would be really appreciated that you contact us.
Finally, what we anticipate is, as I said, that we are going to keep working the same way we have done since Montreal. The next meeting we will resume these fortnightly meetings with the lightweight design team on the 30th of March at, well, 2:00 PM UK, that by that time will be—now it's GMT, but will be GMT plus one. So as far as I can tell, Rob has already shared the invite for this. And it's not—they are not closed design team meetings, they are open to the whole community. So we hope you connect, you will contribute, you will help all of us in building a core set of documents and model that would be useful. If you believe that there is anything else that would require an interim press, let us know. Let us know, send us an email to Rob, to myself, to both of us, include Mahesh, whatever, so we can try to organize this. As I said, now at this stage, it would be interesting to consider opening other activities because this one of the core goes well. It's not finished, but it's going well. And I do believe that additional activity would help us in finishing the full polish of the core model.
And with this, unless Rob you want to add anything?
Rob Wilton: No, I think we're good. Thanks.
Diego Lopez: Okay. With this, I will finish and we can continue with the presentation. First one, if [I remember] well, is Qin? Yeah. This side.
Qin Wu: [Presenting Terminology for Energy Efficiency Network Management] Okay, good afternoon, everyone. So I will give a quick update of terminology for energy efficiency network management. So current version is 01 and document status, you know, version 00 was adopted as a working group draft in November, just previous IETF meeting before. And thanks, Camilo, Tony Li, and Muhammad, and Diego, Dongjie, and many others to provide valuable comments and input. Basis input and comments, actually we file the issue ticket and try to address in the latest version, version 01.
So you see the change we made actually not too much. Actually give a quick update. First, we add two terminology, including Energy Object and also Energy Saving. The second is, you know, we reference Power Benchmark in BMWG working group, so we try to update the status of this Power Benchmark reference. And also we try to generalize like, you know, DSLAM, GPON equipment into Access Equipment. So this is the main update we have.
Review the new term we add here, for example, Energy Object. This is based on the discussion with GREEN Framework draft authors, and one terminology they, you know, already propose use is Energy Object. So we think this is more generic and, you know, suggestion from the Framework draft author is also move to this Terminology draft. So you can see the detail, the definition of this terminology and if you have any suggestion or different opinion, please let us know.
Second definition is about Energy Saving definition. The title is not correct. This actually based on some discussion with Terminology author and we do have the open issue about this and we actually took this definition really from EMAN related already published RFC, but they don't have definition, they have some description text. So we come up this, you know, this definition put into the Terminology draft. So you can see we define the Energy Saving as a reduction in total energy consumption, typically measured against a baseline and per unit of output rather than just absolute amount decrease.
Happy to hear your review or comments on these two new definitions. And yeah, for next step, actually we just, you know, recently we have a good sync up with all the GREEN working group draft team authors and we think we already have use case, framework, and YANG data model. So for this terminology, could, you know, serve as, you know, umbrella for all these drafts. So we hope for, you know, terminology has been widely used in framework, use case, YANG model can be moved to this GREEN base terminology draft.
But in addition, we hear some, you know, opinion from Benoit Claise. Actually he suggest we need to better check the consistency of the terminology to be used in all the drafts. So this the next step we should do. We should do more homework, make, you know, all the terminology in different drafts to better align. And second, actually we currently we just maintain a, you know, this draft in the individual, you know, repo. We think, you know, already we have framework move to the, you know, working group repo. We think we can follow the same path, we can move other, you know, the draft to the working group repo so we can better track the progress of this work. And so this require, you know, approval or permission from the working group chair to help, you know, to do this transfer. Yeah. With that, I conclude my presentation. Any comments?
Mahesh Jethanandani: Mahesh speaking as AD. What is the plan for the document? Other than the admin stuff, what is the next step? Is it done? Are we ready to publish it?
Qin Wu: I think, from our side actually, we think we need to better, you know, make this draft better align with other drafts and then we can, you know, make sure we don't miss any important terminology. I think after that we can consider, you know, to move forward for the publication. That's my personal opinion. Yeah.
Benoit Claise: Benoit Claise. So we discussed this point in the past and what we were proposing is to keep it alive a little bit of time and whenever we publish the first documents, whether this is the framework or the YANG module or whatever, it means that it's stable enough for the next document to arrive. So we leave it untouched until the next one arrives, if that makes sense.
Diego Lopez: Yeah, that—it being a core document, we need to align all core documents at the same time. Probably some additional terminology would appear beyond the core document, but that's something that we could deal elsewhere. But keeping this synchronization will be interesting. Okay, so I don't see anyone else. Emil is there waiting. Yeah. Thank you, Qin. You're more than welcome.
Emile Stephan: [Presenting Use Cases for Energy Efficiency Management] So hello, one second. I'm on my way. So let's start. So I am Emil from Orange, and I edit the GREEN use case document with my co-authors as well.
And so I am going to keep the presentation of the update very, very short because I want to leave time for the discussion at the end about all the documents we have in the core. And so basically in the version 01, we added the use case 16 about network-level cross-layer energy saving. So it was provided by Xinyu. I hope I am not—I'm pronouncing good the first name. And it was in the previous version but on the GitHub, but it was not really reflected in the working group version. And it's about multi-layer coordination of energy saving action. So I don't know if there are feedback on this use case? Please. You can come even to say that you're extremely happy with the use case. Would be okay.
And now there were some refurbishment in the version before that I need to recall because we added a table with Marisol about the usage of the framework interfaces by the use cases. It was initially in the use case draft and we moved it in the framework document and I will let the framework presentation to detail that. And so currently I can say there are still overlapping between the use cases, but is not an issue yet. We will see in the future to see how we group them and so on.
But we decided to wait a bit for the framework and the modeling to make a loop to see how we are going to proceed. And I think there is a common view is to work on something in the hackathon in Vienna to make—to improve consistency amongst the core document and then I will—we will decide how I clean up the use case draft. And so if you have anything you want to say or to modify, you can go to the mic or make a pull request. That's all.
Diego Lopez: Okay, so I don't see anyone in the queue but any comment? Very good, okay. So you have spared us four—six minutes, that's good. So Marisol, you're the next one. I guess that I should give control to you, so it would be better that you...
Marisol Palmero: [Presenting Framework for Energy Efficiency Management] Yes. I don't know if you can see me, you can hear me.
Diego Lopez: Oh, I have—no, wait one second because I need to... We can see you, we can hear you. I'm going to change the—to the framework slides right now and I will give you control.
Marisol Palmero: Okay. It's the first time for me to have remote control, I think. But let me see if it works. Yeah, I see how. Perfect. Well, thank you.
I'm presenting the framework for energy efficiency management on behalf of the co-authors. We have been reaching adoption of the document right before the cutoff date. We moved as well from version 10 to version 00 as a working group adopted document. And we have been releasing just a couple of days ago a new version 01. It doesn't have much on it. Some feedback that we have been receiving on the mailer for the call for adoption is already in there, but there are also open issues that will need to be discussed further with the group. Having said that, we will be based on version 00 here to comment the adopted document.
Just to give a recap of what we have done since IETF 124. As you have been highlighting, Diego, the design team has been organizing biweekly calls where we have been accelerating mainly the GREEN YANG data model but also trying to align at the same time the GREEN framework. And this has been the main progress, aligning with the GREEN YANG data model, even I will give a couple of more updates. And with that, we got to the consensus to adopt the document.
As, you know, general overview or high-level view on what we have done based on the framework that we propose here with the different interfaces, highlighting the connectivity between the device component level to controller to the network domain level. The work that it has been done is aligning basically at the bottom, at the device component level with the GREEN YANG data model that Qin will talk further. This work is not completed—I highlight there 70%, could be 70%, could be 80%, right, but still work to be done. We are starting now to discuss the GREEN YANG data model at the controller level and Benoit will address more about these discussions and why the shift.
And we have introduced as well in the GREEN framework another table for use case mapping that I will be highlighting later and this is in progress, right, it's just started from the point of view of—if it's a device-centric or controller-centric. And we have been also seeing a good reference for the GREEN framework in a couple of drafts on the API access, basically on this G service interface on Luis, who will highlight on the PETRA draft, but there are other draft that are under Sustain RG as well making a reference to the GREEN framework.
Okay, what has been the main changes in the draft from version 6 to version 10 since previous IETF meeting? Basically two chapters in the draft. One highlighting the data collection architecture where there is alignment to the GREEN YANG data model based on the device and component level but also highlighting this part that has not been covered yet on the YANG data models on the controller-based. And also we introduced a new chapter for this use case implementation, much more practical where we introduce a classification based on the device or controller focus-centric, right, what needs to be more controlled by the device itself or where the controller might be needed that I will also introduce here.
With that, let me go to the data collection architecture requirements highlights. We are leveraging the framework based on the RFC 8348 on the IETF hardware YANG modules where the energy metrics are mainly based on the hardware unique identifiers if this is at the given by the device component level or if we agree that there is also a role for the controller to maintain that duality and Benoit will talk later more about this. We agree that the framework supports both initiation models, when the controller initiate this communication to understand the energy monitoring or control when this comes to a discussion, but it could be initiated by the controller or by the device, and this dual mapping needs to be—is required for the controller to take actions in there. This is not finished, still under discussion, but this relationship needs to be addressed as well a bit further.
More on what we have been highlighting on this chapter on the architecture requirements. We introduced this data source classification when we get metrics on energy consumption or energy efficiency. We have to understand if this is a measured, estimated, or we don't know from where those data—we might not know from where those data are coming. But source classification and accuracy are addressed and with an implementation on the GREEN YANG data model itself. There are also call out to the certifications for components, like it could be mainly for the PSUs, for the power supply units, where the operators can trust on the information that is given. And we have been introducing in the GREEN YANG data model this call out for the IANA maintained YANG data model we have been proposing and Gen-Chen will highlight on this as well later. And a couple of more things that are introduced here on the reference architecture is the unit multiplier to have consistency across the YANG implementation and we have been introducing as well the concept of power factor.
With this, I would like to derive questions and discussions on these topics for the power state set mapping and intent as well as the controller against device initiated communication to get more information about energy and also the unique identifier-based component identification for this duality mapping. I would like to derive those discussions for later where we have been reserving more time and Benoit will lead that discussion, if this is fine.
And with that, the other chapter or section on the framework document that I was as well referring at the beginning, here is a table summarizing this focus for implementation and we introduce this classification about, you know, where the focus should be if it's device-centric use case or hybrid mode kind of, with device and controller, or just controller-centric. And we expect from here to have some key findings implementation and complement as well the YANG data models based on these discussions and even prioritize, right? If we focus on some of these use cases, we probably will not be able to align with the use cases on all, but just giving preference to some of the use cases. For instance, Emile was highlighting this double accounting, right, focus. I know there are some interest on the video streaming as well and we can further analyze on use case if we agree on any prioritization.
With that, we have been defining as well next steps. And on this alignment with the GREEN YANG data model with main focus in the past on the device, the next step for us is to focus on the controller, even this is under discussion and as I mentioned Benoit will introduce this later. And we want to prioritize the use cases and we, as it was discussed as well by Qin, align and review the GREEN terminology to align the terms that are common to the framework. And based on things that are not open, the issues to discuss further are already highlighted as well on the GitHub repo that is now part of the working group GitHub repo that Rob enabled for us but we continue on the work based on that inputs as well.
And with this, I finish the presentation. I don't know if there are any questions. Diego, I see you.
Diego Lopez: Yeah, I—I put myself on the queue just because to not to forget one comment I want to make. It's about during the adoption call, we got a message from Ali Rezaki on these European best practices on energy management—I don't remember exactly the name. I think that it would be interesting that we address this somehow in the framework. I mean, it's more acknowledging that there are these best practices and that we are in the position of maintaining it. I don't think that is a matter of certification, I mean, of formal certification, but I think that you—we should pay attention to Ali and try to address this as a part—I will open an issue if you like on the GitHub and add this. Or if you have that in mind?
Marisol Palmero: There is an open issue already because what we did is to open issues for each feedback meaningful that we need to follow up, and there is one issue open for it. And there were other references, right? The TR 181 was also called out. There is a lot of work, right, it's super fragmented between other standards, but I agree. I think the Ali was highlighting this code of conduct, right? But I agree we need to address somehow these references, right, just at least as a call out.
Diego Lopez: Yeah, if you open the issue, just—noting that I stand corrected and thank you. I believe it's important that we send the message that we are taking, I mean, that what we are building here is essentially an enabler for all the social concerns about energy consumption and the like.
Marisol Palmero: Yeah, I agree. But the issue is open. Feel free to comment on it. I can put in the notes when the conversation is finished where is the reference just in case anybody else wants to add.
Deepak: Hello. Deepak, Nokia. A general question on the use cases as such. Are we considering, let's say, abstraction or normalizing certain metrics? Because the reason behind this question is I was going through some of the documents in CATS and I see, of course, the document talks about much more metrics, but one particular metric is on power consumption. And so we have L0, L1, L2 level of abstractions in that document. So do we have similar use cases here as well where we say we consolidate metrics from individual elements and then present it in a abstracted way? Are we covering that case?
Marisol Palmero: Okay, Deepak. Let me see if I understand. Are you referring to Layer 0, 1, and 2 from the device or component level to sum up that power consumption of the different elements?
Deepak: I'm referring to, let's say, individual devices and then we go up to a network level and then, you know, that kind of a level, yeah.
Marisol Palmero: Right. Yes, if you see the reference model, right, this will be the role of the controller as far as I see, right? But basically the controller will be able to monitor per device or per component, whatever that abstraction is given, and then at the network domain level, and for that we will have the APIs in place. This is the view.
Deepak: Thank you.
Qin Wu: Hi, Marisol. So at the end of slides you mention, you know, for YANG data model, actually I remember is focus on, you know, device level but now actually for next step, we will work on the controller level. So this will be documented in the same YANG data model draft or—I'm not sure I should defer this question to the YANG data model presentation.
Marisol Palmero: Yeah, I can give you the input that was discussed, right? I think we will include in a different YANG data model, in another module, but I—we didn't get to create a base model yet for the component level—sorry, for the controller level, but it might be a different YANG file, right, YANG module.
Qin Wu: Okay. So in the past, we do have, you know, three network-level YANG model related to this controller model, could be the input to this part. Yeah.
Marisol Palmero: Okay. Thank you.
Diego Lopez: Good. Any further comment? Okay, so next one is Qin again that should be—oh, on his way.
Qin Wu: [Presenting GREEN Power and Energy YANG data model] Okay, so good afternoon. I'm Qin-Chen from Huawei. I'm here to represent the progress of the draft Power and Energy YANG module on behalf of the authors.
So first, there's some document history and recap. On the last IETF 124 meeting, there's some decisions made to establish a GREEN design team and organize bi-weekly GREEN design team meetings to accelerate the work on device monitoring in the first place, and then followed by the bi-weekly GREEN working group meetings for decision validations. And also referring to EMAN Energy and Power MIB as a starting point, which is RFC 7460. And do the parallel work together with a GREEN Framework and make the synchronization between these two drafts from time to time. And also the main objectives of the draft have been decided to define the YANG module for power and energy monitoring aligned with the GREEN Framework terminology, use cases, and all these drafts already adopted as working group drafts. And support device component level energy management as well.
So here's the all the questions proposed and addressed on the GREEN design team meetings. Such as—I will mention some of the important questions addressed such as how should source IDs be handled? You know, the unique ID for energy objects. Are they the same one on the device side and controller side? Can we just reuse existing UUID in RFC 8348? Do we need to introduce Power Factor in the YANG model in replacement of Power Current type that was specified in the EMAN MIB? So namely alternating current and direct current. What hierarchy should the accuracy classification follow to facilitate accurate statistics and make it extensible? So should the YANG model adopt unit multiplier to represent 10-based exponents to scale power and energy units? How to address the double counting risk when measuring power and energy? How to formalize the various relationships? Should we integrate industry energy efficiency certifications into the YANG model?
And up to now, you can check in the latest drafts that has been proposed in the GitHub repo as well as in the IETF Data Tracker. So there's the YANG tree diagram overview here as well. I will note a few important notes here, such as the, you know, this source component ID, which could be mapped to the—to the component name and the UUID in RFC 8348. And also there's monitoring of power and energy attributes such as for power: instantaneous power, nameplate power, unit multiplier, and data source accuracy, power factor, measurement local. For energy: total energy consumed, total energy delivered, and the unit multiplier as well, and data source accuracy measurement local certification. So we'll come to some of them a bit later. And also in the last but not the least, the relationships. So as Jan proposed, we use type as key index ID for relationships that could use multiple sets of remote peers for each type. And the types will also be introduced a bit later.
So first, it's about accuracy identity. Actually there's several subtypes need to be clarified. So firstly, it's accuracy like parent. Because in this way, it could facilitate the aggregation of metrics to make it more easier to be used. So it's the default settings for the nodes. And then it's accuracy unknown, and it's used when the accuracy, you know, is not quantified or cannot be get. And then it's accuracy estimated. So for this, it means the accuracy cannot be measured directly, so it will use the—the metadata from datasheet, etc. And then for accuracy measured. So there's some subtypes like bronze, silver, gold, the red ones. And all of them, most of them are percentage—percentage based and also absolute value based. For example, if we say look at—take a look at the accuracy measurement bronze 100, it means we could use 30% based or 100 to be multiplied by the absolute unit. So in this way, it works very well for small value that doesn't fit the percentage-wise case. So whichever is larger, then it will be counted.
And then it's the relationship. We borrowed some subtype from EMAN, namely aggregating, aggregated, metering, metered by. And also this powered and powered by and powering. So this is to establish a clear relationship between the local nodes and the remote peers across the box. And it's critical to have it for reliable calculations and also to avoid the report duplications.
And then as mentioned as well just now by Marisol, so there's IANA certification types. So we introduced several well-known industry certifications for energy efficiency indicators so that in this case, there's a basis for this metric to comply with. So it's rather to—not limitation but impose some support for these indicators. And also this certification types has got some very positive feedback from IANA, from Amanda. So Marisol also already fixed all the issues mentioned. So it's now—the updates is in the GitHub repo.
And for next steps. So we'll collect feedback from the community and the design team believe the draft is ready for operational information aspect. So just now, Qin mentioned that if it's a whole—overall YANG model or separate YANG model for different aspects, I think I agree with what Marisol said. So it's better to work it in different way. And also we would like to request for working group adoption. But still, there's some open issues which might influence this draft. So for next presentation, there's some—some discussions will be led by Benoit such as operational versus configuration and device level versus network wide. So I think many questions could be clarified and completely discussed in the next session. Okay, that's all from my side. Questions or comments?
Tony Li: Hi, Tony Li, device geek. How do I turn things off?
Qin Wu: Yeah, so you means the YANG models may need the switches for some features, right?
Tony Li: Yeah, we want to be able to turn components off. How do we turn them off?
Benoit Claise: So thank you, Tony. So this is actually one of the key questions. If you don't mind, I'm going to ask the question to the audience because we need to provide more feedback. Whenever we thought about that, we have different views. I mean, your feedback exactly on that point in the next session. Is it possible to postpone it? Thank you.
Tony Li: Two more things along the same lines, and you can tell me I can postpone those too. How do I tell what can be turned off? And then also, how do I express other relationships? Right? I need to be able to say this line card is dependent on that switch card. Please don't turn off that switch card. And I didn't see a relationship that expresses a functional dependency.
Qin Wu: Okay, thank you, Tony. So I guess most of the questions could be covered in the next session and yeah, let's discuss next session. I'm also very interested in these questions.
Benoit Claise: Benoit speaking. On the last one, I think that we could address it here. So right now we have three types of relationships, which is powered by, which is aggregated by, and—I'm missing one.
Qin Wu: Power and Metering.
Benoit Claise: Metering, yes. But if this is functionally, I mean, this is an identity, we could simply add it because what we've done is that we have the notion of energy object, all right? So you take one energy object, a second energy object, and you could just say if this is a functional dependency, it's not powered by, just functional, we could describe it. We make it flexible for that. It's just an extra relationship. You seem confused.
Tony Li: Are you proposing adding a relationship?
Benoit Claise: If this is what you want, yes, it's open. It's an identity. Sure. It somehow—we could even have more identities. What we—because we discussed at lengths in EMAN and we were thinking that there is no point to redo the—the old Entity MIB or the IETF hardware where we say, you know, this component is on that line card because it's not that useful for an energy object. Now if you say this router depends on this switch which is remote and you need it for energy, obviously.
There is a question on the—on the—on the chat about renaming. There are some literals that have been renamed from RFC 7461 but well, I think that's something that if you don't mind to—to reply to it because it's a question on the chat. Later on when you—when you see it.
Qin Wu: So please clarify the question a bit?
Diego Lopez: It's—I mean, I'm curious because it's something that probably would could be sorted—sorted out easy. Is that—literally David Schlick said: the literals for relationship types (powered/by, etc) are different from the literals in 7461 (e.g., poweredBy or altogether). Was this changed to provide consistency with another registry of relationship identifiers?
Qin Wu: So it's borrowed from the—from the EMAN MIB with powering and powered by. If it's a contradict with—you know, for some literal reasons, we can double check after the meeting, I guess.
Diego Lopez: Okay, so it's something that it would be sorted out. Yeah, yeah. Thank you.
Xinyu Chen: Yeah, another question. This is Xinyu Chen from China Mobile and I want to confirm one thing that is the—the report—the power-related or energy-related data reporting interval has been confirmed in the YANG model discussion?
Qin Wu: So you mean the powered by or powering relationships or—
Xinyu Chen: Just the data, the power or the energy data reporting to—from the device to the—
Qin Wu: Yeah, it's already covered. So as the instantaneous power we mention just now and the energy consumed, energy delivered. So they're for this purpose on the device and component level.
Xinyu Chen: Okay, so the time interval is just minute level or just second or what?
Qin Wu: For power, it's instantaneous. For energy, it's, yeah, it should be some interval based. But here we—we haven't this interval set for in the YANG module yet.
Xinyu Chen: Okay. Okay, thank you.
Benoit Claise: Benoit. So question to you: do you need to have the interval? Do you need to have the interval as part of the YANG module, right? Because if you take the interface stats, we push them, we pull them, but we don't say in the YANG module it has to be five—every five minutes, every 40 seconds. So do you need to have this in that YANG module or you actually asking for what are the capabilities of that specific component that the energy could be sent every five seconds? And somehow it becomes the telemetry capability.
Qin Wu: Yeah, I think for this question we—we can discuss offline in more details.
Diego Lopez: Okay. Okay, thank you. Anything else? Well, Benoit, time for—for the open discussion. So let me... [Presenting Open Discussion on Base Documents and Model] All right, so we've been having this design team light or whatever you want to call that for some time now. Every two weeks we meet on a Thursday, why? Because the next Monday there is like a working group meeting, interim, where we try to tackle issues. So we proposed solution and you've seen this in the two previous presentation about multiple points: power, energy attributes, accuracy, relationship, certification, you name it. It was somehow validated what we proposed by the working group, but let's face it: we didn't have a lot of attendance in those meetings. So we need more review. So thank you for that.
What we have is now a YANG module which is there for operational data only. This is a fact. Operational data only means like the interface stats: we don't say how frequently we're going to export. Now it's going to come back the capabilities of the box on that box with that telemetry protocol, I can export the parameters every one minute or every five seconds. This is a telemetry capabilities. We don't say in here you have to push it or you have to pull it every five, ten minutes, seconds, you name it.
So it's an open discussion, so maybe we get this discussion at the end or whenever you want or what you prefer. As you think—as you believe that it could help better. So probably being open discussion, let's go for it. Tony?
Tony Li: Hi. I think as far as timing concerned, what I'd be more interested in is how often the box is measuring that particular value.
Benoit Claise: So yes, there is one RFC that we developed on top of YANG push to give the capabilities. So for example, I could push the interface counters—to make something that we know, interface, we all know interface—every one minute on that box. And there is also part of that RFC like "it's changing," the state is changing. We could say the capabilities. So to come back to your point, it's more interesting to know how frequently it's measured internally. I'm hoping that this RFC will just say actually I can stream it and this is measured every 10 seconds, so I have the capabilities of that telemetry every 10 seconds on that energy agent—energy ID. Makes sense?
Tony Li: Again, I'm more interested in the measurement, I'm less interested in worrying about the streaming or the polling intervals.
Benoit Claise: I get that. Now there are two ways out of that. Whenever we want the capabilities, you want the capabilities only of the measurements, right? I'm telling that right now we don't have it, but if you want to use that RFC 9196, you could. But if this is a requirement from this community, we could have the extension for this measurements here.
Tony Li: Measurement, thank you.
Thomas Graf: Hi Benoit, Thomas here. A very interesting discussion. Maybe, I'm coming more from a YANG push side and I fully agree, we have RFC 9196 where we basically detailing on how data can be exported, in which frequency, whatever is on change or not. Now the questions you're discussing here about measurement, how it's being measurement and what detail on that measurement have, I believe this is a generic discussion and not only related to GREEN itself. Would you agree on that?
Benoit Claise: Myself, yes. Because why I think in terms of telemetry is that if I have to collect this, whether this is energy counters, power counters, interface counters, routing counters, it should be treated the same way in my data collection system.
Thomas Graf: Exactly. So like we have in YANG push with 9196 where we basically describing in general for all basic YANG data we are subscribing what are the data export capabilities, I believe we need something similar for the measurement aspect.
Benoit Claise: I think so too. Now I'm trying to see if it would be different for energy measurement, for data plane measurement, for something else. And this is where I don't know enough of the different domains on which we need to have the measurement capabilities. But I agree this is a generic problem. Yeah. Makes sense. Thanks.
Tony Li: So I'm going to reopen the earlier questions: how to turn things off?
Benoit Claise: This one I would like to get to it in a few slides. I notice your question, but don't worry, we'll address this as I mentioned.
Ah, meaning, can I present the slides about config first and we come back to this? And I've got only nine slides, I guess. Sorry.
So for many of those questions, I would like us to come back to the work items that were proposed by Jan some time ago. By the way, Thomas, you're still in the queue. You want—okay, fine. So let's try to keep in mind the numbers and the content. So and they're groups with reporting and config. And also on the controller and on the device. So the work item 1 is collection from the controller point of view. It means how do I get the information, it means how do I aggregate, how do I make sure I don't double count and all these. Work item 2: reporting from the router or switch or whatever you want. Number 3: now we go in the config. Power saving mechanisms on a device—your point. And number 4: this is power saving or control from the controller point of view. Because maybe I want to control my entire network.
So that's what we did so far. Number 2: operational data on a device. It's complete? No. Need more reviews? Yes, absolutely. But this is where we need guidance from the working group on what to do next. Because we were thinking, can we do this number 3, the power saving which is your question, on the components or a device? Can we do it quickly? And somehow this is where we need your feedback here on where to go. Because when we discuss this, we even have two views.
We could say let's make it very simple, right? I've got like the YANG tree on the board and we could simply add in there an extra variable: power admin state and power oper state. Like we do for the interface: admin down, oper down, and all these. I put two in there for the sake of it, if we know about YANG we have NMDA, we could have only single leaf with two operational states. Fine.
And then we think, well that's easy, this we do it like in the MIB—the old MIB—7460, and that's fine. But here is the thing: for this, I first I need to explain what we have as power state in IANA coming from EMAN. We've got three power state set. One coming from IEEE because that's what we found in the past: off, sleep, on with an IEEE reference. Then we had some from DMTF. Then we had some a third one coming from EMAN telling "actually we need something more generic," so we define a ranking of those: soft off, hibernate, sleep, standby, and all these.
And now the fun starts. We have many questions. And then even between ourselves, there are different views. What do we need? What this group wants to do? Some people are telling, "you know what, I care about having a specific intent which is energy-related for my network." Because it's midnight and I want my network to go to a kind of low power state. But then we face a problem: how do we define the intent? How do we say I want low power state for my network? And somehow it's not the GREEN specific problem, defining the intent is a big problem in the industry, right? So this is one view.
Now, a question is do we even want to have power states of individual configuration components? Now, yes and no, that's why I'm bringing all the arguments to the table. The fan: do I need to have like the power state for the fan? Well for some of those components, they're going to be self-optimized anyway. The fan will have its own optimizations. However, we know that there are some cases where we need to turn them on/off. A single PoE, a smart PDU. We had a case about energy-optimized routing.
Now we ask ourselves, okay, which power state to use? We had some there, if I come back to the slide. Which one to use? Then we—we looked up, is there any power state that are used in our industry right now? And asking the question is answering the question. Well, not really. So what do we do?
Then we thought, okay, there are people coming from the controller, people coming from the router. And we're thinking, let's pretend that now we have a specific vendor telling "I've got this energy feature." We call that energy slicing E+++ whatever. What does it mean in terms of this YANG module? Or in terms of the controller YANG module? Typically you would have a single command and it's going to enable that energy feature on the router or a network. But does it mean that we're going to have all the individual component settings to make it happen? Because maybe it's a mix of "I will go to the low energy routing" with—on a different device—a low fan speed, and on a third device I will have a less CPU state.
Now the question is, would the vendor even give this secret sauce? The answer is no. So on one side we've got like a network view, I would like to go to a low energy state for my network, with proprietary marketing feature, energy slicing E+++ you name it, and individual components.
Now two more things about the component ID—so maybe I'll skip that one for now. Now the question is also do we want to delay this YANG module before we have the answer to all these questions? And some of them are not generic to energy like the intent. And we believe it's not a good idea to—to delay the publication.
Now—okay, there are two options there but I see some in the queue. So please.
Klaus: Yes, Klaus [last name] from EANTC. We have been doing this kind of testing in the mobile network optimization area. And as you know, base stations, gNodeBs have hundreds of parameters and it's proprietary often, it's sometimes just black magic, you know. Um, so that's probably an area where vendors could see this as a way to make—to create a profitable service and often optimization. On the other hand, however, there could also be solutions like SONiC switches, for example, or server environments which benefit from being as open as possible and they might want to share as much information as—as possible so that a controller could reasonably choose the best optimized solution. So I'm wondering if it's possible to create an optional part in the reporting area which could say, for example, from all of the different settings, this is the recommended one for best power savings if that's possible from all of the options space, or at least to say if you choose this—let's say—fan setting, it's going to take that amount of power, if you choose that fan setting it's going to take this amount of power, and then let the controller decide themselves if they want to speed up the fan and then save power because—save something else because the CPU can run faster because it's better cooled, whatever, you know. So I'm—I think it's not wise to delay things too much, but maybe it's wise to think about adding a little bit of reporting capabilities to at least give a choice where the vendors are open to giving that choice, the device vendors.
Benoit Claise: On the—on the second part which is benchmarking, I fully agree because this is what we need. This line card is going to consume that much in that state and anyway we need this. So either we do our own measurement or it's benchmarked by the vendor, we need this.
So Tony, I believe that you've got a question, right?
Tony Li: No, actually I have a proposal. Okay. My microwave oven is pretty smart. It allows me to set a power level. It takes a number between 1 and 100. Why don't we do something like that?
Benoit Claise: Very good proposal. So this is actually what we were trying to do with EMAN there. That's why I mentioned a ranking. Now is this—how useful is this from an interoperable point of view? Now I'm a—I have a controller with multiple vendors, with multiple OSes, with multiple version of the hardware. Now which problem do we try to solve? Setting an independent component or trying to say I want to go in that state for my network? Which mean that I need to keep somehow the mapping between, "oh if I want to go to that state for the network, this is 80%, this one 70%, and this one is 50%." But I—I kind of agree and you'll see two proposal that maybe that's the best that we could be doing from an interoperable point of view.
Emile Stephan: Okay so my—my point of view is that we already have three set of states. Perhaps it's enough. And—and we don't need to spend time to discuss about that and just allow the vendors to select the set they want and then—but I am not—I am not opposing to—to what you are discussing. You—there can be another things that we can add but—
Benoit Claise: And I'm not proposing yet a solution yet. Now we have three, this is correct. So it depends what we want to solve. Because Emil for us and Tony for us, this is easy. You see the green stuff there? It's an identityref. So from a YANG point of view, it could be anything we want. So that's why we wanted to have this discussion here: which problem do we try to solve, all right? So—
Qin Wu: I think we could even have a fourth one, right, which is, "you know what? You prefer to have from 0 to 100? Let's add it."
Emile Stephan: Yeah, but do we need to delay the work?
Benoit Claise: Ah, agreement. I mean this one: what is your answer?
Emile Stephan: I think we—we can go with these three sets and then add another mechanism later if we want. In parallel. I am not saying it's not good.
Diego Lopez: Okay, just watch the time, please. That we have—I mean, this is the kind of—of discussion that you are expected to get engaged in the interim calls. So you have this feeling of this and—and helping the—the team in developing the models.
Holger Koch: Yes, Holger Koch from DT. I think just looking at three states is not enough because think of the hardware how it works today. There is no on, off, sleep. There is maybe on, there is maybe off, there is maybe partly sleeping, partly on, partly off. That's not complex enough to build the—the world. That's my opinion.
Benoit Claise: So if you don't mind: okay, you need more states. How many? Do we arrive to the solution of telling it's from 0 to 100? And then what does it mean from a semantic point of view per device, per vendor, per—or maybe, and this is what I have here, which is—I'm going to present this and we say we just add the state—the read/write now and we have the power state series and how it's applied, we cannot solve this here. Or not now. This is what your point is? Okay.
Tony Li: Um, you know, you could get arbitrarily complicated here. You can imagine an NPU that's got a thousand cores in it and a different power set state for turning off each individual core. I mean this is getting to the point of ridiculous. Um, we're never going to be able to describe everything in the model. And so we have to have some—some kind of abstraction that everybody can interoperate with.
Benoit Claise: Very good. Can I just conclude with two options and—
Diego Lopez: Yeah, no, well, we had to speed up but go.
Benoit Claise: Okay. So I've got two slides and two options. The first one—and I write it maybe badly like the controller view—which means that in terms of the work package or the item, we just say we publish this item 2, solving the telemetry case. Then what we should be doing ideally is try to get work package 1 done where we disaggregate, etc. Then we go to the network-wide controller view, and then if we solve that one, we come back to the YANG module to—to do properly the settings. This might be the most theoretical and the right way to do it, but I'm not sure we're going to be able to solve the configuration from network-wide, as I mentioned before. Or option 2 which is: actually, we just add this read/write variable, it's an identityref, it points to the power state set we have, if someone wants an extra one from 0 to 100, all of them make sense somehow, then we're good and it's not our business to say to even try to solve this interoperability issue of the states per device type and vendors. So this is my last slide, but we need direction for—for the people. Did I hear correctly that somehow we want to go to this option 2 for now?
Diego Lopez: My—my impression from the what has been said in the—the room is that—that we are leaning or here, the people here that we are leaning towards for option 2, yes.
Benoit Claise: Very good. But it doesn't mean we're not—not doing to do work item 1 that we have to do, and maybe try the 4 there. Thank you.
Diego Lopez: There are—there are a couple of other comments on the—on the list, on the—sorry, on the queue. First is Rob.
Rob Wilton: I'll speak a couple of comments. So—so the first one in terms of these power settings, I think I'm scared that if we have too many different sorts of—of choices and things, we end up with no interoperability at all because every vendor does something different. We've just—we've got the interoperability in terms of we've got a single leaf but different meanings. So I think we want to try and—try and get some commonality there and some flexibility. And I think YANG identities allow that. And to sort of echo one of the comments that Tony made about this going arbitrarily complex again, I think we need to try and focus on solving the simple cases and make sure we could do those and then if we need to expand it out more states then we can do that. So—so that's that specific question. In terms of the work next, um, I'm not sure I've got a clear conclusion what's been suggested here. It does feel to me that it's important to—to maybe focus on a couple of these things at the same time. So I know that there's folks that want to work on the controller stuff, to do that. I know Tony's also got dependency for the work he's doing in other places where he wants to know what the settings are going to be on the device. So I would like to sort of try and—try and cover both of those and maybe divide and conquer a bit to see if we can sort of—progress both of those a bit in parallel, at least to a stage where we've got a—a rough idea of what we're doing even if we don't get to the stage where we publish them quite yet and finish them. If that makes sense?
Benoit Claise: Point 1: let's see because your simple case is not someone else's simple case and it means that the only logical conclusion is that we have to do something in a generic way. On the point 2, it makes sense to work on item 1 the same time that we do power—power saving, but the option—the other option was to wait until we tried everything and maybe I wouldn't delay the YANG module.
Thomas, please, very, very fast.
Thomas Graf: Very short. On the power states, I'd like to understand: do we need a ranking or not? Or is it just a string where we—an identity where we describe basically "that we are now in this power state?"
Benoit Claise: Good question. I don't know. Uh, it depends what you want to solve. If you've got enough from the description to know that you go to something lower, better, whatever metric, then maybe it's sufficient. I don't know.
Thomas Graf: My suggestion is to clarify that now, whether this is needed or not, and based on that we can move on.
Diego Lopez: Carsten, please.
Carsten Rossenhövel: Yeah, two words. Thank you. I think we won't fully understand the realm now, so it's fine to progress and just let everybody know in the document "this is not the last version ever" because some vendors sometimes implement things and then they keep their implementations fixed for a long time. Um, I would also think we shall not imply by like 0 to 100 that it's a linear scale. In many cases it's non-linear, also for the power states, the savings are non-linear. So that should be reflected at least. Maybe if there is a ranking, the ranking is not linear, it doesn't get 20% better. And my preference would also be with option 2, like focus on work item 3 because then the working group can actually show improvements, it can show a—a benefit of the work, it's not only monitoring.
Diego Lopez: Okay, so Luis, jump in and please be brief. I will be short. One second because I have to now start the whole process of framework slides. This is Petra. [Presenting Path Energy Traffic Ratio API (PETRA)] Yeah, so next presentation is an update of this Path Energy Traffic Ratio API that we have been presenting some times already and I will do on behalf of my co-authors.
So the motivation, just as a refresh of what was the purpose of the document, was to provide visibility in regards energy consumption for a path. So metrics such as power consumption between source and destination, basically reflected in the graph. So the idea is to define this API that can provide that information using well-known architectures and schemas, so essentially using YANG models for it. And with the purpose of this information to be consumed either internally or externally. So that we can use for reporting consumption for customers, maybe in the case of SD-WAN or—or any other. But also internally, so that we can based on this information, on the information retrieved by the API, so act on the network, maybe through optimization, through taking actions as configuration that has been discussed long before.
So we have presented a number of times as I said. Early version was presented in PE-ENERGY some time ago. And just for your reference, there is an spin-off of another document that is being contributed to SUSTAIN with the purpose of covering parameters that does not fit on the GREEN charter. So more sustainability-related parameters.
So changes in this version. We have been working on refining the model. We have modified some basically model stuff, so throughput defined as decimal64. We have also added the data source accuracy that Qin presented before as part of the data model and some other minor fixes. And relevant here is that we are starting to align with the GREEN data model that was presented as well by Marisol. So somehow trying to converge and—and yeah, positioning this API as a potential API that could retrieve the information based on the model.
Really going through the positioning of—of this API. On—on your right, you can see that essentially the role would map to the framework document would be to serve as a—as one of the potential APIs for—for retrieving the information, so the—the service interface. Could be others as well, but basically that—this API could play that role. And in relation with the Service and Model draft, the RFC—sorry, the RFC 8309, PETRA could play different roles. Could be on top of the network controller, could be on top of the network orchestrator, so in case that we have different domains or even multi-layer approaches. Or we could offer this API even for the customers as I said before, so that can be consumed from—from external customers. So yeah.
So going to the last slide and for the benefit of time. We have yet pending to generalize the model for not being only applicable for IP networks. There are a number of situations where probably we could use this API like could be the non-packet switched technologies in case of optical, even scenarios where we can combine this multi-layer thing, so IP plus optical, or other artifacts like network slicing and so on. In many of these cases, well in the majority of these cases, we don't have API endpoints, so we want to generalize also to them. Of course, we will keep working on aligning this with the GREEN modeling effort so that basically is fully aligned and—and we converge. And explore other scenarios, probably this is more futuristic, so using this API for incentivization, so that the customer—external customer or—or internal ones could use this information for performing optimization actions in the network.
Once we—once the work in the other drafts in the working group are adopted, probably we will try to request working group adoption. I know that now the focus is in the other work in—in GREEN. So but yeah, this is—this is our aim. And with this I'm done and I will not take more minute.
Diego Lopez: Well, it's—this is a—I mean I would say this is a good example of what I've mentioned about going beyond the—the core model and... Well, let's keep talking about this. Thank you. I—I don't see anyone in the queue. Next one is Jing-Jie? Yes. Please. [Presenting Export of Energy Consumption Information in IPFIX] So hello everyone, good afternoon. I'm Jing-Jie Yan from ZTE Corporation, and today I want to present our new draft "Export of Energy Consumption Information in IPFIX," co-authored by Jiaming Li from China Mobile.
Before I begin, I want to make a special note that while this draft is formally submitted to the OPSAWG working group, we still think it's fundamentally energy monitoring technology and related to our GREEN working groups and we believe that the experts from the GREEN working group would give some very valuable feedback and suggestions. Thank you.
First, I want to introduce the background. Now energy consumption has become a very critical operational metric in the modern data centers and networks driven by such as sustainability requirements, cost efficiency demands, and regulatory compliance. And the network operators need accurate and traffic-correlated power information to support some scenarios such as energy-aware routing decisions, per-service energy cost accounting, and fine-grained power optimization.
While there are some gaps in the existing protocols, current protocols such as SNMP and Netconf, they often rely on the periodic polling and this will lead to a lose of causality between the traffic events and energy consumption, lead to delay insights, and enable to correlate power spikes with the traffic burst.
And why we need IPFIX for the energy information exporting? And we talk back to the limitations of the existing approaches. First, let's see the SNMP and Netconf. They often used the request-response model and with a fixed polling intervals. This cannot establish a causal binding between the traffic events and the power consumption. And to the YANG push, I think we—it still fails to track the traffic-induced power changes and the data sampling is decoupled from the data plane load dynamics.
And the IPFIX has three key advantages and we list it here. First is traffic-driven and this kind binds monitoring directly to the traffic events and ensure timely and causal reporting. The second is the exporting can be traffic-correlated. The export can be triggered by packet counts or active/inactive timeouts. And the IPFIX is also extensible. It is easy to add new information elements without the protocol stack changes. So to make a summary, the core insight is IPFIX's event-driven architecture is naturally suited for the traffic-correlated energy telemetry.
And to overview our draft. Our core proposal is that we define six new IPFIX information elements to export energy consumption for both the physical entities in the network devices. And we have three granularity levels: the device level, the line card level, and the port level. And we involve two kind of—two types of metrics. The first is the real-time, which is instantaneous metrics, and the average, interval-based metrics. And the key characteristic is that the traffic-driven export preserves causality between the traffic events and energy consumption. And we also list some target applications such as energy-aware routing, per-flow energy auditing, and fine-grained power management.
Here is the new information elements that we proposed. At the device level is device real-time power and device average power. At the line card level is line card real-time power and line card average power. Finally, the port level is port real-time power and port average power. And this elements exporting should be triggered with different mechanisms in the IPFIX. First such as packet count, the export when N packets are processed. And it can also be triggered by the time—active timeout mechanisms. This might be suited for the sustained but low-rate traffic. And finally is inactive timeout. This can be triggered when there are no packets arrived.
And we put two use cases here. The first one is energy-aware routing. The goal is the compute network paths that minimize total energy cost, not just the latency or bandwidth. The traditional metrics are poor proxies for power. The polling is too slow to capture the power spikes caused by the microburst. So we expect the export real-time power triggered by the traffic thresholds. This provides instantaneous power draw data directly correlated with specific traffic loads.
And second is the per-flow energy auditing. We want to attribute the energy cost to specific services or customers such as the elephant flow which consume significant resources across multiple components, but traditional monitoring is only device-wide. And we want to make the solution that we can correlate such as a 5-tuple flow with a line card and power energy IEs, synchronized export to ensure the data alignment.
We have two key innovations here. First is the traffic-aware collection. We use traffic events as the core triggering mechanism so we can solve the unsynchronized collection problem of polling and enables precise causal attribution. The second is composite templates. We want to combine multiple level energy IEs such as device, line card, port with their identifiers and we want this can synchronized collection of relevant energy data in a single export event.
Okay, that's my presentation and any questions or feedback are welcome. Thank you.
Diego Lopez: My—my only recommendation—I find this interesting and this is some interesting work. My recommendation is that you—you should align units and measurement intervals and everything with the—with the core model. So—so the collection of data is consistent. That's my only comment. But I see Rob and Benoit are on the queue, so well, please, Rob, you go first. Please be—be brief in both cases. I'm going to close the queue anyway.
Rob Wilton: Okay, I will. I mean I think probably Benoit might have the best chance here. I'm still not sure that IPFIX is the right solution for this. So I think Benoit's the expert here who will know. If it's definitely related to traffic flows, then I think IPFIX is great. But otherwise, if it's just getting information off the device, even if it's related to instantaneous power that's being used due to traffic spikes, I still think that YANG push is a better mechanism here. So I don't really understand the use case that well.
Jing-Jie Yan: Okay, and in my opinion, I don't think IPFIX would be the right choice, but we want to make some options for the energy-saving management solution. Thank you.
Benoit Claise: All right. Quickly go back to the slide with all the IPFIX information elements. If you use IPFIX, there is something to be optimized because you put like a line card, port, device. Then what else are you going to have? You're going to have software, you're going to have process, and somehow you're overloading the IPFIX information element with something which is the context. So that's why in the YANG we have energy object which is generic with a value and we report power, energy, etc. To get to the list.
Jing-Jie Yan: Okay, thank you. Maybe we can discuss it later offline. Thank you for your advice.
Diego Lopez: Okay. Can I have a—sorry, can I—oh, sorry. I don't know why—sorry. Otherwise, I'm—you can use the list if you don't mind, the GREEN list if you don't mind. Thank you. So Xinyu? Come here while I prepare the Hybrid Energy Saving Mechanism for Transport Network.
Xinyu Chen: [Presenting Hybrid Energy Saving Mechanism for Transport Network] Okay, thank you. Hi, everyone. This is Xinyu Chen from China Mobile, and here I am presenting our latest draft on hybrid energy saving mechanism for transport network on behalf of all the authors.
To begin with, it's important to recall the conception that here we mention the transport network, it's a combination of the IP layer and the underlay layer. So it combines the flexible ability to do the routing and the rigid resource allocation. So previously, our network level cross layer energy saving this use case has been incorporated in the use case draft. So thanks to the collaborative work with Emil, Stephen, and Qin-Wu. So thank you very much.
And here we just propose a hybrid approach for GREEN that combines—combines the fast local response with coordinated holistic network-wide optimization all while maintaining SLA guarantees. And all these are supported by power-related monitoring and policy configurations and YANG models.
So here what does this hybrid actually means? First, we have device-centric operations and it is local and fast with real-time localized energy adjustments by individual network elements. Local data connection and pre-configured policies are performed. So it enables fast response to transient traffic fluctuations and it maintains autonomous operations even if the controller connection is down. And then the hybrid mechanism also concludes the controller-centric operations. It is global and strategic with centralized holistic view across the entire network domains. So here it can perform cross-layer analytics and long-term traffic prediction based on these—based on these policies. It can access network level risks and formulates the strategic policies for energy saving. So here the hybrid approach is immediate reaction and global optimization.
So here the most important thing is that to achieve the hybrid mechanism for energy saving, a lot of reliable power-related data is required. So here we—we have three layer data monitoring layers, including the power monitoring, traffic monitoring, and topology monitoring. And for the power monitoring, it comes from the component level like boards, fans, or PSUs to the device level. And we think that the period means that the reporting or the acquisition—the interval has been defined. And for the traffic monitoring, not just the port traffic, but down to the tunnel traffic, we think is also really important for service assessment and migration for energy saving. And third is the topology monitoring and it is from a network level to—to perform the cross-layer visibility across the transport and IP layers. So it can capture protection relationships and service mappings.
And here we just show the device-centric and controller-centric operations. And we won't go through in detail, but shows—here we just shows the operations flows among these, and we can see it formulates a loop control from the device to the controller and from the controller to the device. And we think that maybe in—maybe for data connection, different layers must focus on different—focus on different data granularity. And for analysis, the model—the model for GREEN, for energy saving policies, will be different such as for the controller, maybe AI or ML engines can be—can be inserted, but for the devices, maybe only lightweight algorithm is can be considered.
And so—and here we just showed some information flows we can think in this system. So we listed here: the first one is the controller to the users, it may include the northbound interfaces for configuring objectives and viewing results. And for controller to devices, it may infer to the southbound interfaces for policy distributing, telemetry, or some commands. And to device to device—device to device, and it is a scenario that we imagine here that maybe some devices can have peer interactions for local energy saving coordinations and capability advertisements.
And so also the security for network energy saving is also a really important—important factor. So here we just consider service-aware power states based on the—based on the general power states. So we think that power state should be alignment with the service tolerance and network idle or busy cycles. And risk-controlled energy saving is also should be considered because, for example, if protection path may carry extra traffic normally but must be instantly available for failover scenarios. So we think that risk assessment is mandatory before we turn the device into some low—low power or sleep mode.
We also have some deployment considerations, but for the time limitation, we just to show some real-time—to some demo results and we have deployed this at both at the controller side and the device side. Yeah, and energy-aware routing policy is also verified and to achieve a network-wide energy saving profit. And protection switching or and traffic burst reliability reliability is also verified.
Yeah, so next step, we—we believe that this draft established the foundation. So looking forward, we see some potential extensions maybe can discuss with you guys. First, the interface and the data models. We think that cross-layer energy status, how to—how to exchange and device power state, how to negotiate, and what is the required granularity? And then, how to facilitate understanding of power or energy-saving states among the related devices to enable collaborative energy optimization? And the second is what monitoring dimensions are essential to guarantee SLAs during energy-saving mode? So here, here is all for today's presentation and comments and feedbacks are really welcome. Thank you.
Diego Lopez: Thank you. I don't see anyone in the queue. I'm curious: so what you think is something that happens above the controller, right, in general? Whatever the controller is?
Xinyu Chen: Now here we mention the controller is the controller add—devices to the controller. Yes.
Diego Lopez: Yeah, which is on top of the—of the GREEN controller, if you like.
Xinyu Chen: Yes. Yes.
Diego Lopez: Rob, please.
Rob Wilton: Yeah, thanks for this presentation. I think that this is very interesting. I think lots of what you cover here is very much in the scope of what GREEN is doing and is covered by other drafts and things. So I was trying to understand what the scope of this document actually is. Is this really about you documenting a use case that you're doing now, in terms of like explaining how you're deploying the benefits you're getting? So it's like an informational draft? Are you saying that there needs to be more guidance and general instructions about how everything fits together? Although that seems to be close to the framework. So I was trying to understand what the goal or focus of this document is or what you—what you're aiming for, if that makes sense.
Xinyu Chen: Oh yeah, thank you. And as you can see that we think that in this kind of scenario, the cross-layer energy saving, we can extract some contents is related to the working group's use case draft, framework draft, or some YANG model drafts. And besides, we think that the cross-layer is also a systematic piece of work. So we want to—to separate some models, data models, or some just the framework—or just more importantly, maybe just the data models to do a separate—to do a separate from a system—system draft or in—and to cooperate with the others from the network level, the—the network level holistic view. Yeah, thank you.
Rob Wilton: Okay. So can you feedback some of that into the—into the—on the list to framework—the people working the framework document in terms of your ideas? And also be very clear as to how what you're adding adds on or is separate from that? That'd be, I think, helpful to see how to position this work.
Xinyu Chen: Oh, okay, of course, we will—to do the alignment with the use case, the framework, and the models' drafts and coordinate with others more often. Yeah.
Rob Wilton: Thanks.
Jing-Jie Yan: Thank you.
Diego Lopez: Okay, so well, we have our last presentation. Thank you, Xinyu. Luis? Jumping and please be brief. I will be short. One second because I had to now start the whole process of functional entities selection, confirm, and now you have the control.
Luis Contreras: [Presenting Functional entities for enabling per service eco-data reporting] So hello everyone again. This is Luis from Telefónica. I will introduce this—this new draft. Was originally directed to SUSTAIN, but we received advice from the SUSTAIN chairs to move here. So I will present the—this idea of defining functional entities for enabling per-service eco-data reporting.
So the objective essentially is to—to identify potential functional blocks that could help—could help us to collect the information about energy consumption and then basically aggregate that so that we can report towards external—towards APIs that could be part of the framework. The additional blocks that we have initially identified are the ones that you can see in the sub-bullets: so Service Discovery (when we comment here about service, we refer to the service connectivity, I mean), Service Discovery, Resource Allocation, Energy Measurement, Attribution, and if necessary, Orchestration, so if we want to optimize capabilities in the network. So apart from that, a—a function that would be necessary as well would be the one of reporting. So once we have aggregated the data, how to report that to external or internal entities.
Key concepts of the document. We are describing the functional components, so we are identifying those components that would enable this per-service energy attribution within a network domain. Also we are reusing the—all the—the different artifacts that have been defined in the GREEN framework, so energy objects, interfaces, and the framework itself. And finally, mapping those functional components defined in the document to—to on top of this reference framework. So well, I will not spend more time on the framework because was already presented.
Proposed functional blocks. We are, for instance, proposing the Service Energy Information Function. The idea of this function would be to be responsible of attributing the resource level energy measurements to the service level energy consumption, so basically associate the different consumption about the different elements in the—that are traversed by the connectivity services so that we can basically attribute the consumption to the service. Then the Resource Energy Measurement function. The idea of this functionality would be to provide the raw energy telemetry that could be used for the other functions for compose the end-to-end.
Then the Resource Allocation function that would track which resources are allocated to a service. So we are considering the—as a connectivity service, so would be how is the information that—the energy information that is collected from the different network elements that the connectivity service is passing through. Then the Service Directory Function. Here, the idea would be to get a list of active connectivity services and map each service identifier to the different service instances, so essentially to understand the—the chain of nodes that are being traversed by a connectivity service.
Then the Orchestration and Optimization function, so with the idea of having orchestration that could optimize and manage the connectivity service placement, so where we basically instantiate the service, the connectivity path. And then the reporting function that would be the one consolidating all this information and reporting back to the—the one that is consuming this API.
The functional mapping of these functions—and this is a very initial exercise—is as you can see there. So the reporting function essentially playing the role of these API service interface, and then having basically on—at the device component level, the telemetry part. And then in the controller level the other functions that will essentially process the telemetry, allocate—associate the telemetry with the network elements that are being used for a certain connectivity path, aggregating all of that, and then passing through the reporting function. Apart from that, the orchestration function that we will leverage on that in case that an external customer requires some kind of optimization for—for the purpose of improving the energy efficiency. On the text, you can see the process flow. I will not take more time because we basically lack of that time, but basically the idea would be to associate to the different interfaces that we have in the framework.
So the—as conclusion, the document proposed this identification of functional blocks: what would be needed for having this allocation of—this attribution of energy for a given connectivity service. All of this is a preliminary exercise, so for sure we know that we will need more—much more iterations on having something much more solid. And the idea for presenting here would be to collect interest from the working group to understand if this is of interest for GREEN essentially. Our next step is also to move the draft to GREEN working group. As I said initially, was targeted to SUSTAIN but I think there is no essentially no research topic here, and we will with this, we will work on a preparing a new version for next IETF and collecting and incorporating feedback that we already have started to collect and—for instance, the one from Adrian from Deutsche Telekom. And that's all from my side. Thank you.
Diego Lopez: Okay, so well, we are just—just on time for closing, unless there is a final comment on this? No. Well, we will keep doing things beyond and above the core model in parallel. Uh, well, just let me close, formally close the meeting and thanks to you to you all. Keep reviewing documents, keep, keep joining the discussions, the interesting discussions we have had—we had here. This is the kind of—of things that are discussed in the interims. Come and—and join us. It's—it's as fun as it was here. Thank you so much. Rob, consider yourself dismissed and consider the possibility of an invention that everybody says is Spanish, but it was invented by Romans, which is siesta. Take it.
Rob Wilton: That's good. Thank you. Thanks, all. And thanks Luis for stepping in.
Luis Contreras: Welcome.
Diego Lopez: Yep. See you.