Hi Alex,

 

I don’t think we’re in disagreement here. 

I was not proposing to add dynamic information, but just what can be read in a 
datasheet.

 

What you refer to as the “holitstic view of the network providing a view of 
current status”, to me is topology, not inventory. It would be more accurate to 
speak about an augmentation of the topology. 

 

Cheers,

Daniele  

 

From: Alexander L Clemm <[email protected]> 
Sent: Thursday, August 24, 2023 12:21 AM
To: Tianran Zhou <[email protected]>; Daniele Ceccarelli 
<[email protected]>
Cc: opsawg <[email protected]>
Subject: Re: [OPSAWG] Some thoughts on Green Networking Metrics

 

I think the purpose of what the network inventory is supposed to be used for 
needs to be clarified more generally, which will also answer the question here. 
 

I believe that fundamentally “inventory” is just that: an inventory of what is 
there, or supposed to be there.  Generally something that you could attach an 
“asset tag” to, either physical or virtual.  That is, basically it constitutes 
“static” information.  (Of course it can still change over time, but changes 
will occur on slower time scales (e.g. minutes to days, not subseconds) and it 
does not include dynamic state of the assets themselves.)  So, with inventory 
being understood that way, dynamic information (such as current consumption) is 
simply not a part of it.  That being said, static aspects that describe 
properties of the assets in the inventory might be – information such as 
equipment type, which could be tied also to data sheet stuff such as power 
ratings.   

That being said, there may also be a need for a holistic view of the network, 
providing a view of current status etc.  To organize this information, 
utilizing a network inventory model is a natural candidate.  However, the needs 
for this type of use are different from those of a traditional inventory.  
Crucially, this data would not be “owned” e.g. by a controller having a network 
view, but by the individual devices in question, where it would also be 
retrieved from or subscribed to.  This means that you would need to organize 
this not as part of a network inventory, but as part of the data provided by 
the device.  (In the past, this would be broadly referred to as the device’s 
Management Information Base, or MIB – not to be confused with MIBs in the 
narrower SNMP sense).   

>From that perspective, dynamic metrics such as the current power consumption 
>do not belong in the network inventory as currently defined.  If we wanted to 
>put it there, the next question would be why stop there?  Why not put other 
>operational data there as well, why not configuration data?  Arguably you 
>could organize any type of management data into a network inventory, which 
>would however not take into the account the fact that in general, you will 
>access most management data from the device directly.  

--- Alex 

On 8/21/2023 7:22 AM, Tianran Zhou wrote:

Hi Daniele,

Thanks for the clarification.
Now I understand what you want to include is static value.

Best,
Tianran 


  _____  



Sent from WeLink

发件人: Daniele Ceccarelli<[email protected]>

收件人: Tianran Zhou<[email protected] <mailto:[email protected]> >

抄送: Alexander L Clemm<[email protected] <mailto:[email protected]> 
>;opsawg<[email protected] <mailto:[email protected]> >

主题: Re: [OPSAWG] Some thoughts on Green Networking Metrics

时间: 2023-08-21 20:33:57

 

HI Tianran, Alex, 

 

the power consumed at a given time is highly changing over time, but parameters 
like e.g. power consumption of a card at 50%, 75% and 100% of the load don't.

I don't disagree with Alex when saying that this is not directly inventory, but 
it's strictly related to it and should probably be an augmentation of the 
device inventory.

 

BR
Daniele  

 

On Fri, Aug 18, 2023 at 3:20 AM Tianran Zhou 
<[email protected] <mailto:[email protected]> > 
wrote:

I am not quite clear about the applicability of the inventory.

What’s the difference with hardware model or entity model.

I see energy work was related to entity mib in eman before:

https://datatracker.ietf.org/wg/eman/documents/

 

It seems inventory should be something static from the name. But IMO, the 
energy metrics are dynamic, can will change all the time.

 

Best,

Tianran

 

From: OPSAWG [mailto:[email protected] <mailto:[email protected]> ] 
On Behalf Of Alexander L Clemm
Sent: Friday, August 18, 2023 7:05 AM
To: [email protected] <mailto:[email protected]> 
Subject: Re: [OPSAWG] Some thoughts on Green Networking Metrics

 

Hi Daniele,

apologies for the late reply. 

I think inventory is somewhat orthogonal to this, but of course devices and 
equipment (including chassis, line cards, equipment holders etc) will be 
considered part of inventory.   Therefore via transitive closure it is 
certainly conceivable to make power consumption data accessible via inventory.  
This could make sense as part of a consolidated controller view of a network.  
However, on a network element itself, the network inventory aspect would not 
apply but the metrics should still be available so the device/equipment level 
category still applies.  As to whether device level data should be replicated 
as part of network inventory data  would presumably depend on the use case.  

--- Alex

On 7/26/2023 6:35 PM, Daniele Ceccarelli (dceccare) wrote:

Hi Alex, all,

 

Just following up on the comment I did ad the mic earlier today. 

 

The drafts speaks about metrics at: device/equipment level, flow level, path 
level, network level. 

The  device/equipment level covers power consumption per chassis, line card and 
port at different loads of traffic, hence IMO should fall into the inventory 
category. 

Would you agree?

 

Cheers,
Daniele  

  

 

_______________________________________________
OPSAWG mailing list
[email protected] <mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email protected] <mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to