@Bechet Let's have a BoF to find out!
", "time": "2024-07-24T20:00:29Z"}, {"author": "Robert Wilton", "text": "For note taking: https://notes.ietf.org/notes-ietf-120-green?edit
", "time": "2024-07-24T20:04:06Z"}, {"author": "Behcet Sarikaya", "text": "@Adrian: looking forward to.
", "time": "2024-07-24T20:04:37Z"}, {"author": "John Scudder", "text": "Mahesh isn't speaking to slides, right? Just speaking?
", "time": "2024-07-24T20:08:39Z"}, {"author": "Adrian Farrel", "text": "ack
", "time": "2024-07-24T20:08:50Z"}, {"author": "Behcet Sarikaya", "text": "eman was a WG sometime back, don't remember when and eman stands for energy management, I think
", "time": "2024-07-24T20:11:23Z"}, {"author": "Adrian Farrel", "text": "wait for the presentation about eman
", "time": "2024-07-24T20:13:02Z"}, {"author": "Behcet Sarikaya", "text": "Benoit
", "time": "2024-07-24T20:13:44Z"}, {"author": "Stephan Emile", "text": ":grinning:
", "time": "2024-07-24T20:22:27Z"}, {"author": "Dan York", "text": "GIven the topic, I'm assuming \"NPU\" = network processing unit ?
", "time": "2024-07-24T20:25:33Z"}, {"author": "Jeffrey Haas", "text": "yes
", "time": "2024-07-24T20:25:55Z"}, {"author": "Cheng Li", "text": "providing greener solution is important, but the pre-require is remaining the same forwarding performance.
", "time": "2024-07-24T20:26:19Z"}, {"author": "Romain Jacob", "text": "I'd argue that point
", "time": "2024-07-24T20:26:41Z"}, {"author": "Cheng Li", "text": "But what if, we can low down the energy price, we do not need to care about the energy consumption. Invest more on green energy is another good way to go.
", "time": "2024-07-24T20:27:55Z"}, {"author": "Adrian Farrel", "text": "That's Jeff Tantsura
", "time": "2024-07-24T20:28:24Z"}, {"author": "John Scudder", "text": "Is the question about embodied energy?
", "time": "2024-07-24T20:29:32Z"}, {"author": "Suresh Krishnan", "text": "I think it depends on the kind of equipment
", "time": "2024-07-24T20:29:33Z"}, {"author": "Cheng Li", "text": "But the analysis is very useful, thank you Tony LI
", "time": "2024-07-24T20:29:39Z"}, {"author": "John Scudder", "text": "When he talks of \"manufacturing cost\"?
", "time": "2024-07-24T20:29:40Z"}, {"author": "Jeffrey Haas", "text": "I believe this bof is for a wg that will manage power usage of network devices, not lobby for cheaper power.
", "time": "2024-07-24T20:29:50Z"}, {"author": "Suresh Krishnan", "text": "I was thinking embedded carbon @John Scudder
", "time": "2024-07-24T20:30:02Z"}, {"author": "John Scudder", "text": "Yeah, that's closely related to embodied energy.
", "time": "2024-07-24T20:30:23Z"}, {"author": "Jan Lindblad", "text": "@kurtis, the numbers you quoted are not typical for the types of equipment relevant for IETF, I believe
", "time": "2024-07-24T20:30:37Z"}, {"author": "John Scudder", "text": "Yeah I would be quite surprised if the embodied energy were that enormous. (But I don't have data to share.)
", "time": "2024-07-24T20:31:11Z"}, {"author": "Snezana", "text": "the 90-10 are not nbrs for networking but mobile devices if I am not mistaken, For networking the power in use is about 70%
", "time": "2024-07-24T20:31:53Z"}, {"author": "Yesu Lu", "text": "That actually is different from the data we have. 70% of our emissions come from use of product sold, which means energy consumption through use > that of manufacture.
", "time": "2024-07-24T20:31:57Z"}, {"author": "Romain Jacob", "text": "\"we do not need to care about the energy consumption\"
\n\n\nIMO, that's the mindset that got us here in the first step.
\n
I'm not saying green energy isn't important. It is. But optimizing the amount of resources we need will always be importnat
", "time": "2024-07-24T20:32:02Z"}, {"author": "Jan Lindblad", "text": "The embedded carbon fraction can be quite high for end user equipment (with relatively low power consumption and short life). For core equipment, it's a very different story, where the energy use is dominated by the use phase
", "time": "2024-07-24T20:32:24Z"}, {"author": "Daniel Bernier", "text": "agreed @jeffrey although I believe rethinking our industry practice should be looked at ... ie yearly evolutions improve performance vs power on all components.
\nMIght end up with the \"era of the 20 years old router\" needs to be relooked at
", "time": "2024-07-24T20:32:55Z"}, {"author": "Boris Khasanov", "text": "@Tony, could you pls clarify the point about not using Go vs. Yang?
", "time": "2024-07-24T20:33:43Z"}, {"author": "Romain Jacob", "text": "(I think this was a Monopoly joke)
", "time": "2024-07-24T20:34:37Z"}, {"author": "Adrian Farrel", "text": "It was a cultural reference to a popular board game called Monopoly
", "time": "2024-07-24T20:34:40Z"}, {"author": "Suresh Krishnan", "text": "I think slide 3 from Ali's presentation at IEPG has some numbers
", "time": "2024-07-24T20:34:54Z"}, {"author": "Suresh Krishnan", "text": "", "time": "2024-07-24T20:34:59Z"}, {"author": "Tony Li", "text": "@Boris Khasanov Yes, that's a Monopoly reference.
", "time": "2024-07-24T20:35:23Z"}, {"author": "Boris Khasanov", "text": "Thanks all, I just thought about programming language and got confused...
", "time": "2024-07-24T20:36:12Z"}, {"author": "Jeffrey Haas", "text": "Daniel Bernier said:
\n\n\nagreed @jeffrey although I believe rethinking our industry practice should be looked at ... ie yearly evolutions improve performance vs power on all components.
\nMIght end up with the \"era of the 20 years old router\" needs to be relooked at
\n
Steady improvements will be desirable. Focus on addressing these problems means that power usage and ability to use it elastically means that it becomes an even deeper input into component design.
", "time": "2024-07-24T20:36:59Z"}, {"author": "Behcet Sarikaya", "text": "+1
", "time": "2024-07-24T20:37:01Z"}, {"author": "Robert Wilton", "text": "@Tony, yes a Monopoly reference, but I also interpreted your slide as \"we already know how to solve this problem, we just need to get on and do it\". Fair?
", "time": "2024-07-24T20:37:02Z"}, {"author": "Tony Li", "text": "@Robert Wilton We know the desired delivery vehicle: YANG. Contents are still TBD.
", "time": "2024-07-24T20:37:57Z"}, {"author": "Stuart Card", "text": "There have been murmurings in the distributed ledger technology (blockchain, cryptocurrency, smart contract) community about _explicitly_ charging for the energy consumption of their \"miners\", routers, etc. vs their implicit pricing into the mining rewards & transaction fees.
", "time": "2024-07-24T20:38:00Z"}, {"author": "Jari Arkko", "text": "Pointer to Benoit's diff: https://author-tools.ietf.org/iddiff?url1=rfc6988&url2=draft-eman-green-rfc6988bis&difftype=--html
", "time": "2024-07-24T20:38:53Z"}, {"author": "Stuart Card", "text": "I worry also about the increasing energy costs of the enormous neural networks now being called AI and inserted into the networks as magic pixie dust to optimize everything (esp. shareholder perception of value).
", "time": "2024-07-24T20:39:58Z"}, {"author": "Padma Pillay-Esnault", "text": "@Jeffrey I agree with your comment. However ... are we aiming for this group to give recommendations?
", "time": "2024-07-24T20:40:14Z"}, {"author": "Jari Arkko", "text": "AI is a concern of course. As is crypto-mining. But ... maybe not something which are directly in our field, i.e., looking at power reductions in networking.
", "time": "2024-07-24T20:41:07Z"}, {"author": "Jari Arkko", "text": "Benoit's point about different power state models is a key one. There's multiple. And different implementations have different ones they can leverage.
", "time": "2024-07-24T20:42:57Z"}, {"author": "Srihari Sangli", "text": "@Padma, I would think this group should provide recommendations for efficient usage of given power. Whether that power is cheaper or not is not relevant (cheaper is most desired)
", "time": "2024-07-24T20:43:26Z"}, {"author": "Mohamed Boucadair", "text": "@Padma, I don't think we can provide recos (not only that specific point) at least at the first phase of the WG (read, I would not see that in the first charter).
", "time": "2024-07-24T20:44:01Z"}, {"author": "Daniel Bernier", "text": "infrastructure is infrastructure ... if I power an HVAC at 80% load because I cannot adjust/optimize an \"entity's\" or set of \"entity's\" power usage, is relevant.
", "time": "2024-07-24T20:44:04Z"}, {"author": "Robert Wilton", "text": "@Jari, I think that those power states probably matter more for reporting, but for configuration to control power states, I would hope that we can come up with something simpler.
", "time": "2024-07-24T20:44:10Z"}, {"author": "Tony Li", "text": "Is it really our place to make recommendations all over the place? Isn't our job to develop standards? Give people the right tools and let them run their networks.
", "time": "2024-07-24T20:44:20Z"}, {"author": "Daniel Bernier", "text": "Padma Pillay-Esnault said:
\n\n\n@Jeffrey I agree with your comment. However ... are we aiming for this group to give recommendations?
\n
I personally find it likely that technologies that provide for component and systemic accountability will help provide tools to provide the ability to address the targeted problems. When you see the energy meter spinning, if you know what component burns the most power, you look to see if you can reduce it. Using Tony's presentation as an example, if NPU burns the most power, being able to shift traffic off the whole line card - not just the interface - becomes a target. This has impacts for topology, what links are plugged into cards by purpose and expected traffic, etc.
", "time": "2024-07-24T20:44:53Z"}, {"author": "Stuart Card", "text": "We need to look not just at energy but also related quantities: entropy, Gibbs free energy, exergy, emergy... energy alone oversimplifies and misses important environmental and economic considerations.
", "time": "2024-07-24T20:45:04Z"}, {"author": "Daniel Bernier", "text": "I do not build a 500s+ CLOS fabric just to see port lights blinking ;-)
", "time": "2024-07-24T20:45:23Z"}, {"author": "Robert Wilton", "text": ":-)
", "time": "2024-07-24T20:45:32Z"}, {"author": "Mohamed Boucadair", "text": "ha ha ha
", "time": "2024-07-24T20:45:34Z"}, {"author": "Jeffrey Haas", "text": "Half serious observation, @Daniel Bernier : You build CLOS to have non blocking traffic through a fabric. There is a level of overprovisioning that is required to accomplish the job. Providing for resiliency vs. some blocked or dropped traffic can have a measured energy impact.
", "time": "2024-07-24T20:47:03Z"}, {"author": "Padma Pillay-Esnault", "text": "@Med I too think it is difficult for this forum to give recommendations. I even question for a later stage as each vendor may have different manufacturing procedures, costs, imperatives ... and it is all apples and oranges. However perhaps it can come up with a way of evaluating the system.
", "time": "2024-07-24T20:48:35Z"}, {"author": "Dan Romascanu", "text": "thanks for the EMAN presentation, Benoit
", "time": "2024-07-24T20:49:10Z"}, {"author": "Adrian Farrel", "text": "A question got asked in the prep for the BoF: To what extent is an operator (or customer) willing to flex an SLA in order to reduce energy consumption?
", "time": "2024-07-24T20:49:18Z"}, {"author": "Jinming Li", "text": "good question\uff0cThe usual ways to save energy and reduce emissions are often by dynamically turning off a part of the equipment, like some line cards or optical modules on it. But for all operators, directly shutting down something that's running is really a scary thing. We must first make sure that no customer traffic is being carried on the corresponding part.
", "time": "2024-07-24T20:49:56Z"}, {"author": "Tony Li", "text": "With my end user hat on: none. I paid for the service level. Please deliver it.
", "time": "2024-07-24T20:50:13Z"}, {"author": "Romain Jacob", "text": "The problem is the service level.
", "time": "2024-07-24T20:50:45Z"}, {"author": "Jeffrey Haas", "text": "https://en.wikipedia.org/wiki/Differential_tariff
", "time": "2024-07-24T20:51:14Z"}, {"author": "Daniel Bernier", "text": "@adrian question might also turn to ... at what point in time are operators going to be asked to provide KPIs on power-per-bit as an SLA ?
", "time": "2024-07-24T20:51:20Z"}, {"author": "Tony Li", "text": "@Jinming Li : This is not hard. We use traffic engineering techniques to move traffic around all of the time already.
", "time": "2024-07-24T20:51:25Z"}, {"author": "Romain Jacob", "text": "Expecting constant service no matter what is a fallacy
", "time": "2024-07-24T20:51:26Z"}, {"author": "Padma Pillay-Esnault", "text": "@Srihari my point is that recommendations scope need to be clearly defined as it is a very diverse ecosystem out there.
", "time": "2024-07-24T20:51:37Z"}, {"author": "Jan Lindblad", "text": "@tony, If there is a price difference so that lower SLA at night is a bit less expensive, then people may prefer that. In Europe I think that will happen in a not too distant future. CO2 has a price here
", "time": "2024-07-24T20:51:44Z"}, {"author": "Tony Li", "text": "@Romain Jacob My ISP already disappoints me on a regular basis. A further reduction in service levels for 'green' reasons would simply give them another excuse.
", "time": "2024-07-24T20:52:34Z"}, {"author": "Vicky Risk", "text": "naive question: is powering up and down, eg for NPUs, does that cause them to wear out and fail faster?
", "time": "2024-07-24T20:52:45Z"}, {"author": "Marisol", "text": "Service providers today in Europe are looking into defining network path constraints based on power utilization.
", "time": "2024-07-24T20:53:11Z"}, {"author": "Daniel King", "text": "Some consumers actively look for services that are low(er) carbon, or have an option to pay a premium for carbon offsets.
", "time": "2024-07-24T20:53:34Z"}, {"author": "Daniel King", "text": "If Green Telcos is not a thing currently, it will be one day.
", "time": "2024-07-24T20:53:44Z"}, {"author": "Daniel Bernier", "text": "and/or source of power
", "time": "2024-07-24T20:53:47Z"}, {"author": "Tony Li", "text": "@Vicky Risk We have an ongoing study looking at exactly this. The jury is still out, but so far the results look like it is not problematic.
", "time": "2024-07-24T20:53:52Z"}, {"author": "Kurtis Heimerl", "text": "Just got onto the chat. @Jan Lindblad I am confident that the numbers are still bad for core networking equipment, which still has lifecycles of around 5 years. The report (which I am trying to find) was focused on datacenter equipment and conflated routers and servers but it was all round that 80/20 90/10 ratio. The manufacturing costs dominate.
", "time": "2024-07-24T20:54:10Z"}, {"author": "Jari Arkko", "text": "There's many problems in this space. In the e-impact meeting \"power proportionality\" (mostly but not entirely implementation issue) was given highest priority. Equipment is improving in this regard... A second issue is whether we can do some more wholesale shutdowns of entire nodes, e.g., during night. I believe this is also being done in some operator networks. But there's also user and app issues, e.g., apps that keep polling every second for some news, making it harder to keep stuff sleeping
", "time": "2024-07-24T20:54:11Z"}, {"author": "Jeffrey Haas", "text": "Vicky Risk said:
\n\n\nnaive question: is powering up and down, eg for NPUs, does that cause them to wear out and fail faster?
\n
One of the properties you're looking for is \"thermal shock\". It's a consideration and how susceptible components are to it depends on the product and the environment.
", "time": "2024-07-24T20:54:43Z"}, {"author": "Kurtis Heimerl", "text": "The only space where the build costs didn't dominate were buildings, which makes sense given their much longer life cycles.
", "time": "2024-07-24T20:54:54Z"}, {"author": "Romain Jacob", "text": "@vicky: It's not naive. In theory, it hurts. In practice, it's not clear whether the effect is visible in the MTTF
", "time": "2024-07-24T20:55:14Z"}, {"author": "Vicky Risk", "text": "I am thinking any scheme to power down and re-energize would have to be tied in with monitoring for faults, such as failover, etc, and if this system increased failures, that would be counter productive.
", "time": "2024-07-24T20:55:45Z"}, {"author": "Romain Jacob", "text": "true
", "time": "2024-07-24T20:56:04Z"}, {"author": "Jari Arkko", "text": "Such monitoring would be prudent, yes
", "time": "2024-07-24T20:56:07Z"}, {"author": "John Scudder", "text": "@Kurtis, to repeat my earlier Q, can you confirm that by \"costs\" you mean embodied energy or embodied carbon, and not monetary costs?
", "time": "2024-07-24T20:56:25Z"}, {"author": "Boris Khasanov", "text": "@Marisol, That might be one of the ways to accomplish being more 'green'; an additional constrain for TE
", "time": "2024-07-24T20:56:26Z"}, {"author": "Padma Pillay-Esnault", "text": "@tony Tony Li
\n\"Is it really our place to make recommendations all over the place? Isn't our job to develop standards? Give people the right tools and let them run their networks.\"
\n+1 I think we should not provide recommendations but standardized means to evaluate the consumptions. How vendors build their systems will be based on their needs and a plethora of other parameters. Therefore defining how to measure will be interesting...
Tony, Padma, I agree. IETF is about making tools. Others use those tools to optimize their situation according to their preferences.
", "time": "2024-07-24T20:57:16Z"}, {"author": "Kurtis Heimerl", "text": "@John Scudder yes, actual monetary costs aren't directly correlated with energy use and carbon creation
", "time": "2024-07-24T20:57:29Z"}, {"author": "Boris Khasanov", "text": "+1
", "time": "2024-07-24T20:57:30Z"}, {"author": "Adrian Farrel", "text": "... compare privacy, security ...
", "time": "2024-07-24T20:57:30Z"}, {"author": "Michael Welzl", "text": "+1
", "time": "2024-07-24T20:57:40Z"}, {"author": "Srihari Sangli", "text": "@Romain, to have NPU toggle between power-off and power-on more frequently is going to be messy from traffic & operations perspective too.
", "time": "2024-07-24T20:58:23Z"}, {"author": "Tony Li", "text": "False. Again, we move traffic around all the time already.
", "time": "2024-07-24T20:59:26Z"}, {"author": "Romain Jacob", "text": "\n\n@Marisol, That might be one of the ways to accomplish being more 'green'; an additional constrain for TE
\n
FYI: academics have proposed many solutions for this. Not sure how practical they really are, but there is a starting point. GreenTE is one of the earliest paper I know
", "time": "2024-07-24T20:59:32Z"}, {"author": "Boris Khasanov", "text": "@Roman, thanks for pointing it
", "time": "2024-07-24T21:00:13Z"}, {"author": "Tony Li", "text": "GreenTE is very practical. However, it's not the first-order optimization that we should be making. Turning off components is far more impactful.
", "time": "2024-07-24T21:00:20Z"}, {"author": "Romain Jacob", "text": "Sure, but you need to steer traffic away to make turning off possible (which is what you mentioned before). No?
", "time": "2024-07-24T21:01:20Z"}, {"author": "Alexander Clemm", "text": "There is a draft for green metrics which would presumably move into GREEN: https://datatracker.ietf.org/doc/draft-cx-opsawg-green-metrics/
", "time": "2024-07-24T21:01:28Z"}, {"author": "Tony Li", "text": "Yes. However, moving traffic away from components will necessitate doing things like sending some traffic on less-optimal paths and less power-efficient paths.
", "time": "2024-07-24T21:02:12Z"}, {"author": "Ike Kunze", "text": "@Romain: Thanks for the pointer to GreenTE
", "time": "2024-07-24T21:02:24Z"}, {"author": "Cheng Li", "text": "Topology/routes can not be changed frequently, otherwise we will meet more problem. Therefore, ports can not be turned down just because of saving power. Need more considerations
", "time": "2024-07-24T21:02:32Z"}, {"author": "Daniel King", "text": "Steering traffic that requires computation/function to specific locations to leverage an economy of scale in the data center is valid. Various references point to 40-50% of DC power costs are cooling related, too. Again economy of scale is important.
", "time": "2024-07-24T21:02:39Z"}, {"author": "Padma Pillay-Esnault", "text": "Regarding on/off and reducing longevity @jeffrey +1 thermal shock is a significant factor
", "time": "2024-07-24T21:02:55Z"}, {"author": "Cheng Li", "text": "problems
", "time": "2024-07-24T21:02:57Z"}, {"author": "Joe Clarke", "text": "I keep hearing efficiency, but it seems more like consumption monitoring and control to effect energy use. Use of a lot of energy is not necessarily inefficient. And it may not be carbon heavy, either.
", "time": "2024-07-24T21:03:10Z"}, {"author": "Alexander Clemm", "text": "@Cheng LI: yes, this is why this needs to be accompanied with techniques that facilitate reconvergence, perhaps maintaining state
", "time": "2024-07-24T21:05:12Z"}, {"author": "Padma Pillay-Esnault", "text": "@Cheng Li on topology changes - what is the frequency are you framing this statement?
", "time": "2024-07-24T21:05:30Z"}, {"author": "Jari Arkko", "text": "Joe: the idea is that energy consumption can be measured and pain points be identified, then some reduction actions can be taken. (Config again, adjust, buy new equipment). But ultimately one needs to contrast energy use to what you get with it. MWh/bit is not great, but uMwh/bit is better.
", "time": "2024-07-24T21:05:34Z"}, {"author": "Daniel King", "text": "Sounds like a BMWG problem, too. Do you trust what the vendor tells you about the energy demand of its platforms/components. Another attribute to test in the operator labs.
", "time": "2024-07-24T21:06:06Z"}, {"author": "Stephan Emile", "text": "you trust the max
", "time": "2024-07-24T21:06:44Z"}, {"author": "Joe Clarke", "text": "Jari: agreed. I was just thinking through the terminology. What I hear more is getting the real consumption is important and having controls to reduce that use where possible is also useful.
", "time": "2024-07-24T21:07:09Z"}, {"author": "Tony Li", "text": "Today traffic engineering moves LSPs around every few minutes. This uses a make-before-break approach so there is no significant disruption. Yes, there is a potential for a one-time reordering with each move.
", "time": "2024-07-24T21:07:59Z"}, {"author": "Marisol", "text": "Charter proposal as discussed in green-bof mailer: https://github.com/marisolpalmero/GREEN-bof/blob/main/GreenCharterProposal.md
", "time": "2024-07-24T21:08:20Z"}, {"author": "Alexander Clemm", "text": "@Jari I guess uMwh/bit would be wh/bit:-)
", "time": "2024-07-24T21:09:12Z"}, {"author": "Kurtis Heimerl", "text": "I'm poking round a little bit, and there was a LCA for a Dell server in 2019 that had it at 50/50 manufacturing vs running (https://www.delltechnologies.com/asset/en-us/products/servers/technical-support/Full_LCA_Dell_R740.pdf)
", "time": "2024-07-24T21:11:05Z"}, {"author": "Kurtis Heimerl", "text": "That's over an anticipated 4 year utlization
", "time": "2024-07-24T21:11:31Z"}, {"author": "Adrian Farrel", "text": "...add deployment, removal, recycling
", "time": "2024-07-24T21:12:20Z"}, {"author": "Romain Jacob", "text": "If you want more of this type of data: https://dataviz.boavizta.org/
", "time": "2024-07-24T21:12:57Z"}, {"author": "Kurtis Heimerl", "text": "Those (at least remove and recycling ) are accounted for and are relatively small (~2%)
", "time": "2024-07-24T21:13:01Z"}, {"author": "Romain Jacob", "text": "(no networking gear, yet)
", "time": "2024-07-24T21:13:13Z"}, {"author": "Behcet Sarikaya", "text": "I don't know how the milestone dates make sense for this long going historic problem
", "time": "2024-07-24T21:15:16Z"}, {"author": "Kurtis Heimerl", "text": "They reference the report I list but have wildly different outcomes. Thanks for the pointer @Romain Jacob I'll try to figure out what's going on
", "time": "2024-07-24T21:15:42Z"}, {"author": "Romain Jacob", "text": "(I never worked with the Boavitza data, I don't know the details nor endorse it)
", "time": "2024-07-24T21:16:39Z"}, {"author": "Romain Jacob", "text": "But it's a tool to be aware off in the area for sure
", "time": "2024-07-24T21:17:03Z"}, {"author": "Beno\u00eet Claise", "text": "Mariol: benchmarking was out of scope but I see under \"dependencies and liaisons\" => \"collaborate with other SDOs like ETSI and ITU for benchmarking methodology.
", "time": "2024-07-24T21:17:39Z"}, {"author": "Boris Khasanov", "text": "we have BMWG too
", "time": "2024-07-24T21:18:08Z"}, {"author": "Behcet Sarikaya", "text": "Let's not forget that the crux of the issue is the use of fossil fuels
", "time": "2024-07-24T21:21:23Z"}, {"author": "Qin Wu", "text": "ETSI and ITU provide useful metrics already in addition to what IPPM, BMWG is doing, we need to collaborate with them, avoid to reinvent new wheel, just as Dean said, @Benoit
", "time": "2024-07-24T21:23:03Z"}, {"author": "Tony Li", "text": "That's not the only issue. Efficiency means that we can make better use of green energy sources.
", "time": "2024-07-24T21:23:10Z"}, {"author": "Stephan Emile", "text": "fossil ressources at large
", "time": "2024-07-24T21:23:34Z"}, {"author": "Dan York", "text": "I think this charter, as proposed, is a good first step.
", "time": "2024-07-24T21:24:38Z"}, {"author": "Behcet Sarikaya", "text": "I think problem statement should state clearly how we expect to impact fossil fuels usage
", "time": "2024-07-24T21:25:30Z"}, {"author": "Eliot Lear", "text": "Just a little FYI. Toerless and a few others have written a draft about previous work at the IETF. You can see it here. https://datatracker.ietf.org/doc/draft-eckert-ietf-and-energy-overview/
", "time": "2024-07-24T21:25:31Z"}, {"author": "Qin Wu", "text": "Agree with Tony, this work proposed is indepdent of whether you use green energy or regular engegy, definitely can encouage operators to use green energy by introducing new metrics
", "time": "2024-07-24T21:25:57Z"}, {"author": "Yesu Lu", "text": "fossil fuel is the biggest but not the only issue. more power = more copper in cabling, more lithium for storage, etc...
", "time": "2024-07-24T21:26:43Z"}, {"author": "Robert Wilton", "text": "@Behcet, until we get clean energy (fusion) then I all energy technologies has a cost to build/maintain, etc. Hence, regardless of where the energy is coming from, if we can make devices be more frugal on the energy it uses, we should do that.
", "time": "2024-07-24T21:27:35Z"}, {"author": "Daniel King", "text": "Canada is a great example of a geography that has renewable/sustainable energy, and steering traffic to specific locations that have access to sustainable energy is compelling. That said, I guess routing extensions and PCE-type scenarios of traffic steering is out of scope. But... Moving forward GREEN would provide the building blocks that would be the first step towards these goals.
", "time": "2024-07-24T21:27:37Z"}, {"author": "Tony Li", "text": "Energy source information is absolutely vital, but is not something that we need to standardize for PCE-type scenarios.
", "time": "2024-07-24T21:29:41Z"}, {"author": "John Scudder", "text": "The tired old \"boiling the ocean\" metaphor seems incredibly applicable right now.
", "time": "2024-07-24T21:30:39Z"}, {"author": "John Scudder", "text": "Also the old saw about how to eat an elephant.
", "time": "2024-07-24T21:31:12Z"}, {"author": "Tony Li", "text": "We can save TWH right there. :-)
", "time": "2024-07-24T21:31:27Z"}, {"author": "Eliot Lear", "text": "John, have you been eating elephants again?
", "time": "2024-07-24T21:31:33Z"}, {"author": "Jan Lindblad", "text": "@stuart, I completely agree we should involve some of the economists/sociologists that are already doing the SBTi and GHGP evaluations of pretty much all the companies in our business
", "time": "2024-07-24T21:32:01Z"}, {"author": "John Scudder", "text": "@eliot easier with ketchup
", "time": "2024-07-24T21:32:21Z"}, {"author": "Padma Pillay-Esnault", "text": "Having a clearly defined scope would help on seeing how the work produced by the wg will be used. my 2 cts
", "time": "2024-07-24T21:33:10Z"}, {"author": "Suresh Krishnan", "text": "@John: Is the answer \"Write a yang model for an elephant?\" :grinning:
", "time": "2024-07-24T21:33:12Z"}, {"author": "Robert Wilton", "text": ":-)
", "time": "2024-07-24T21:33:50Z"}, {"author": "Adrian Farrel", "text": "I asked, but the elephant doesn't want a YANG model
", "time": "2024-07-24T21:34:14Z"}, {"author": "Robert Wilton", "text": "Tight scope/charter for the initial WG. Once that work is done then (despite what someone else said), I think that rechartering is relatively easy, or should be.
", "time": "2024-07-24T21:37:49Z"}, {"author": "John Scudder", "text": "Seems right.
", "time": "2024-07-24T21:38:00Z"}, {"author": "Daniel Bernier", "text": "might actually end up having to rethink the whole model.
\nRather than try and figure out what/how to mesure massive pool of power to then try and figure out if it economically makes sense to move things around for power savings.
MIght end up looking more towards how to build massively distributed resources.
\n100000s of distributed rasperry PI's instead of 2 centralized massive DCs.
\nFood for thought
", "time": "2024-07-24T21:38:31Z"}, {"author": "John Scudder", "text": "Not stipulated that massive distribution is more power-efficient than centralization. Distribution has many merits but efficient use of resources isn't usually one of them.
", "time": "2024-07-24T21:39:26Z"}, {"author": "Robert Wilton", "text": "IMO, the problem with OPSAWG is that it pulls in small groups who want to focus on their own thing/ideas and care less about the other ideas being presented. A dedicated WG would focus the participant energy into this topic.
", "time": "2024-07-24T21:39:30Z"}, {"author": "Tim Chown", "text": "so have green-man and green-ops WGs
", "time": "2024-07-24T21:40:06Z"}, {"author": "Tim Chown", "text": "the charter for green-man is pretty clear, for the other less so
", "time": "2024-07-24T21:40:23Z"}, {"author": "Adrian Farrel", "text": "green-man or wicker-man?
", "time": "2024-07-24T21:40:31Z"}, {"author": "Qin Wu", "text": "EMAN is designed for industry vertial, the use cases we are looking for for operator is much simpler comparing with industry iot use cases.
", "time": "2024-07-24T21:40:53Z"}, {"author": "Chris Seal", "text": "Long term - RFCs to contain a 'Energy Efficiency Considerations' section as well as the 'Privacy' and 'Security' sections?
", "time": "2024-07-24T21:40:54Z"}, {"author": "Behcet Sarikaya", "text": "boil the ocean / eat the elephant
", "time": "2024-07-24T21:41:19Z"}, {"author": "Qin Wu", "text": "Energy efficiency consideration only take effect when energy aware routing is taking on. Agre with it is long term.
", "time": "2024-07-24T21:41:47Z"}, {"author": "Tim Chown", "text": "the path to measure / manage / control seems a lot clearer and well defined, hence green-man.
", "time": "2024-07-24T21:42:00Z"}, {"author": "Marisol", "text": "+1 to Chris Seal point on Long term
", "time": "2024-07-24T21:42:23Z"}, {"author": "Robert Wilton", "text": "@Chris, I'm not so keen on adding those sections to every RFC. They would probably only end up containing some fairly standard text as a tick box exercise. I.e., only have the section if there is something important to say.
", "time": "2024-07-24T21:42:38Z"}, {"author": "Mohamed Boucadair", "text": "@Chris, some SDOs have such section but IMO the content is too generic or too speculative.
", "time": "2024-07-24T21:42:40Z"}, {"author": "Daniel King", "text": "@Chris - It might fall into \"Operational Considerations\" as a sub-section, but given regulatory requirements will play an increasing role in network operations, it will be an important consideration.
", "time": "2024-07-24T21:42:58Z"}, {"author": "Suresh Krishnan", "text": "@Chris, Marisol, Rob: I suggested that once we have a base for a checklist we should start off with a question in the shepherd writeup
", "time": "2024-07-24T21:43:45Z"}, {"author": "Alexander Clemm", "text": "@Chris While well-intentioned, I don't think it is a good idea to introduce more \"red tape\" and boilerplate sections that will not always apply
", "time": "2024-07-24T21:43:47Z"}, {"author": "Padma Pillay-Esnault", "text": "@Chris - may not apply to a large number of docs as we typically build incrementally most of the time
", "time": "2024-07-24T21:44:22Z"}, {"author": "Robert Wilton", "text": "Yes, shepherd write up question could be a good idea
", "time": "2024-07-24T21:44:36Z"}, {"author": "Behcet Sarikaya", "text": "I also support formation of green WG!
", "time": "2024-07-24T21:44:42Z"}, {"author": "Dan York", "text": "I support formation of the the separate GREEN WG. I think this kind of work needs a home.
", "time": "2024-07-24T21:45:09Z"}, {"author": "Srihari Sangli", "text": "+1
", "time": "2024-07-24T21:45:20Z"}, {"author": "Michael Welzl", "text": "I support formation of a GREEN WG.
", "time": "2024-07-24T21:45:23Z"}, {"author": "Dan York", "text": "I share the concern just voiced by @Ali Rezaki about getting this deployed.
", "time": "2024-07-24T21:45:50Z"}, {"author": "John Scudder", "text": "What would the shepherd writeup question look like? I'm very skeptical that it would produce anything helpful. (Same for mandatory considerations for reasons already said.)
", "time": "2024-07-24T21:45:57Z"}, {"author": "Mohamed Boucadair", "text": "+1 John
", "time": "2024-07-24T21:46:16Z"}, {"author": "Robert Wilton", "text": "@John, strawman, something like: \"Does this draft have particular considerations for energy efficiency either in it's design or how it should be deployed? If so, is this documented in the Operational Considerations section?\"
", "time": "2024-07-24T21:48:02Z"}, {"author": "Qin Wu", "text": "regarding deployment implemtation, we can have all network vendors to work together to develop vendor neutral solution, improve multi-vendor interoperability. @Ali
", "time": "2024-07-24T21:48:28Z"}, {"author": "Dan York", "text": "To me this is a bit of \"crawl -> walk -> run\"... many of us want to \"run\" and have all sorts of measurements that help with a larger sustainability picture. But the reality is that we need to \"crawl\" with the basic measurements first.
", "time": "2024-07-24T21:48:33Z"}, {"author": "Robert Wilton", "text": "But I do absolutely get the point that for the vast majority of drafts there is probably not that much useful to say.
", "time": "2024-07-24T21:48:46Z"}, {"author": "Adrian Farrel", "text": "Wouldn't you add to the manageability considerations section recommended contents to discuss energy?
", "time": "2024-07-24T21:49:01Z"}, {"author": "John Scudder", "text": "@rob would we be asking the shepherd to opine as to whether the document should have covered this? Sounds like that's what you intend. I think the last couple hours has demonstrated that question is incredibly knotty and not amenable to a quick one-sentence reply. It's potentially the subject of a whole second draft.
", "time": "2024-07-24T21:49:47Z"}, {"author": "Clayton Hassen", "text": "fundamentally (from an operator perspective), when we do receive this telemetry, we are going to want to pro-actively act on the data...as an example shutting down un-used links, or turning off NPU's etc....I think there will need to be some potential work on protocol extensions to make this happen, no?
", "time": "2024-07-24T21:49:50Z"}, {"author": "Robert Wilton", "text": "@Adrian, yes, so the shepherd writeup question is just a reminder to make sure that has been considered, if it should be. But this is all going off topic anyway
", "time": "2024-07-24T21:50:04Z"}, {"author": "Tony Li", "text": "@Clayton Hassen Please see draft-li-ivy-power
", "time": "2024-07-24T21:51:15Z"}, {"author": "Adrian Farrel", "text": "@Rob, I'm all for off-topic if it result on you writing a draft on \"Energy Considerations Sections\"
", "time": "2024-07-24T21:51:28Z"}, {"author": "Robert Wilton", "text": "Apparently as an ex-AD, I'm meant to have lots of free time now. :-)
", "time": "2024-07-24T21:52:04Z"}, {"author": "Andrew Sullivan", "text": "I\u2019d suggest getting the basics and particularly terms nailed down would tell you naturally what high level things you could actually achieve.
", "time": "2024-07-24T21:53:25Z"}, {"author": "Suresh Krishnan", "text": "+1 for doing the basics first @Andrew
", "time": "2024-07-24T21:54:22Z"}, {"author": "Andrew Sullivan", "text": "(Since I agreed with the observations about the competence of the IETF to tackle some of these matters in the larger issues)
", "time": "2024-07-24T21:54:33Z"}]