search

ietf-ccamp-wg / ietf-network-inventory

3 stars 5 forks source link

Inventory models coordination #26

Closed italobusi closed 9 months ago

italobusi commented 2 years ago

2021-11-17 Network Inventory call

During IETF 112 OPSAWG meeting, the issue of disambiguating the concept of inventory has been raised:

https://notes.ietf.org/notes-ietf-112-opsawg

A dedicated OPSAWG interim meeting may be scheduled.

italobusi commented 2 years ago

2021-11-24 Network Inventory call

Related work on "inventory" within OPSAWG:

YuChaode commented 2 years ago

draft-palmero-opsawg-dmlmo-02： this draft introduces a lifecycle management and operation(LMO) solution. It focus on the LMO data which includes but not limited to asset inventory, licenses information, feature usage and incident management. Our draft may have some overlap with its asset inventory concept. According to the asset inventory model defined in this draft, it seems their inventory management is in large granularity. The asset types include hw, sw, sw-cloud, phone and other. And it also defines a sub-asset id list underlay the asset root, the subasset id points to asset id. This idea more or less looks like our generic modeling idea. And for sub-asset types, they include router, switch, wireless, controller, board, power-supply, transceiver and others.

draft-claise-opsawg-collected-data-manifest-00: This draft sounds like serving for telemetry and if you read it a little bit deeply, you will find it cannot be used for inventory management. It can be a part of inventory information but not all. According to the abstract of this draft, the author point out the existing issue of model-driven telemetry for missing contextual information. The contextual information includes identifying what kinks of data produced by device and how should the client collect this data from device. The author call them platform manifest and collection manifest. I think we could consider the platform manifest for device as yang-lib for controller.

draft-ietf-opsawg-sbom-access-03: This draft introduce a module to discover the software running on the device and retrieve known vulnerabilities for this software. I thin this draft cannot fully replace our inventory draft. But the software and vulnerabilities can be a part of information, just like the collected-data-manifest model.

draft-yg3bp-ccamp-optical-inventory-yang: This is the draft we are proposing.

draft-dbwb-opsawg-sap-00: This draft introduce a new concept of SAP (service attach point) in network model. And the author considers it can be the inventory model mentioned in RFC8345. I don't agree with this idea. IMHO, the SAP is still related with service or connection configuration which can also be covered by termination point of abstract network model. If the author consider that there is a requirement of identifying what kinds of service can be supported by the port, it is better to augment some more attributes in TP, just like we augments client-facing and supporting-client-signals in OTN topology. And the model they propose in this draft, they provide a new network type, SAP network, and a SAP list underlay the node root. It cannot cover the management of rack, shelf, slot as we recognized. That is the reason why i don't agree that this SAP network is the inventory model.

italobusi commented 2 years ago

2021-12-17 Network Inventory call

Review from Chaode of other OPSAWG drafts related with Inventory

see https://github.com/italobusi/ietf-network-inventory/issues/26#issuecomment-996390349

draft-palmero-opsawg-dmlmo-02：here there is some overlapping with our draft. "Asset" in this draft should have the same meaning of our "component". It considers Hw asset so it is close to our draft.

draft-claise-opsawg-collected-data-manifest-00: inventory of yang models capabilities of device

draft-ietf-opsawg-sbom-access-03: different type of inventory, just SW inventory.

draft-dbwb-opsawg-sap-00: Anton: the draft is trying to find UNI ports in the network and the service capable ports. Not inventory. IP service capable ports. To expose an abstracted view of a very simple of connectivity matrix. Just edge ports. Italo: it is an inventory of topological element. Anton: which ports are service capable, e.g. I can setup L2 or L3 VPN service on these ports. No contention at alla with respect our draft. Is is very IP oriented draft.

Regarding again the first draft:

Italo/Aihua: need to qualify the term inventory, HW inventory, or topology inventory or other.

Jeff: we need to clarify that we are focusing on hardware network inventory. Our objective is simpler than what is in this draft. Even if there is some overlap, our scope is a bit clear.

Anton: we have a subset of what it is happening

Italo: if it is a subset, a profile can still be used so this model can be modularized to allow using only the asset or augmenting the definition of the asset inventory

Anton: another solution is to put our inventory model within the draft. May need to check what is the difference between our data model and their asset data model

Italo: it seems that the structure is already modular, section 6.1.1 defines an asset inventory model which can be used as a stand-alone model and it might support our needs. We need to review the YANG model in 6.1.1 in more details.

Aihua: we should compare this module with our model and see if we can extract the common parts

Italo: not sure if the model applies to device and/or controllers but it looks like quite generic and applicable on multiple scenarios (including controller's NBI)

Anton: it seems applicable to any scenario where you have different applications, servers, ... and you want to manage them in the same controller. Our model was meant to be more specific for a transport/provider network environment. This model may probably lack some specificities we need in our environment

italobusi commented 2 years ago

The scope has been clarified to be the network hardware inventory

italobusi commented 1 year ago

2022-11-16 Network Inventory call

Issue ietf-ccamp-wg/ietf-network-inventory#26 has been re-opened to track the inventory models coordination started during IETF 115

The feedback from IETF115 and the side meeting

The material presented at the meeting is available at: https://github.com/billwuqin/Inventory-management-using-YANG

The Inventory YANG mailing list has been already setup:

https://www.ietf.org/mailman/listinfo/Inventory-yang

It is not yet clear whether we are going to be subscribed automatically or we should subscribe by our own. A question has been sent to the list administrator.

All the contributors to this draft are invited to join this list and actively contribute to the discussion

Our current view is that there is no overlapping between the scope of our draft, which is a network model for hardware inventory, and the scope of other drafts submitted to OPSAWG

As soon as the list is operational, we can share with the other participants the result of the analysis we have already done: https://github.com/italobusi/ietf-network-inventory/issues/26#issuecomment-996907583

This analysis is not covering draft-wzwb-opsawg-network-inventory-management-00, which has been recently submitted

italobusi commented 1 year ago

2022-11-23 Network Inventory weekly call

Sergio: I don’t see any overlap with the other draft, but i concern that these argument will delay our work.

Jeff: I will send an email to the mailing list to tell that, from our operators perspective, the inventory data model we are working on is the inventory data we want and there is no overlap with the other drafts.

italobusi commented 1 year ago

Some analysis from Chaode: Analysis of Enterprise Network Inventory Draft.pptx

italobusi commented 1 year ago

2023-04-26 Network Inventory weekly call

We can leverage on the operators' feedbacks to push the WG to address the hardware and software inventory models in a step-by-step approach

italobusi commented 1 year ago

2023-05-24 Network Inventory weekly call

Reviewed the latest version of proposed charter: https://mailarchive.ietf.org/arch/msg/inventory-yang/GcBEYEnG07JZHL1mPTT994N8B6I/

Comments:

There is a lot of potential complexity when dealing with planning of components and may be worthwhile understanding what should be covered by the inventory model

Jeff/Fabio: at least it could be important to mark an holder as reserved (e.g., because a new board is planned to be deployed there)

Issue ietf-ccamp-wg/network-inventory-yang#22 created to track the discussion on this topic

italobusi commented 1 year ago

2023-06-14 Network Inventory weekly call

Draft charter updated:

https://datatracker.ietf.org/doc/charter-ietf-ivy/

An e-mail soliciting comments (to be sent to IESG) has been sent to the list (deadline for comments is next monday, June 19)

https://mailarchive.ietf.org/arch/msg/inventory-yang/SZh3AUYGUr7tiBSyAUFeC6e73uU/

Comments should be sent to IESG (iesg@ietf.org) but it is better to keep also the inventory mailing list informed (inventory-yang@ietf.org)

The comments discussed earlier are still applicable to the latest version of the draft charter:

  • [ ] Jeff/Fabio: send a mail to the inventory mailing list expressing the urgent need from operators perspective

Oscar thinks that the urgency was quite understood from IETF offline discussions

Jeff is concerned that covering also enterprise and software inventory would require longer discussion

A possible approach could be to focus the initial RFC to cover only hardware network inventory in a carrier network, making sure that the model is open to future extensions to support enterprise network and software inventory

Comments:

D: multi-layer is not a proper name for inventory objects. Better to use the term layer-independent or layer-agnostic for inventory

E: correlation might be understood as implying some complex processing, better to use relationship instead

  • [ ] Nigel: raise the comment on the Inventory mailing list

Discussion about the next steps after the IVY WG is formed

Our proposal is to propose the IVY WG to use the model in our draft as the base common model for network inventory

Question about whether to move the optical aspects outside the draft. The current model is not covering the functional aspects (including the optical functional aspects). Functional aspects are usually covered in the interface and topology models

Aihua reported some discussion in BBF meeting about the possibility to use the model in our draft as a common basis also for the access networks

It is not clear whether there are gaps in our model to model access NEs: to be checked on a case-by-case basis if the gap is specific to access networks, to be covered by a BBF augmentation, or is generic to be covered by our model

Having more examples of devices that are modelled using our inventory model is anyway good to check the completeness of the model

italobusi commented 1 year ago

The IVY WG has been formed and a session is planning at IETF 117

Suggested actions from the chairs:

If you’ve already proposed a network inventory related document:

  • Send a mail to this mailing list saying " Hey, I/we wrote a draft related to inventory, here it is". This will allow people getting a better awareness of all the material already present and spread in different WGs.
  • Identify which parts of your existing drafts would fit into the core model.
  • Book a slot at IETF 117 to discuss about it, there will be room for everyone.

See: https://mailarchive.ietf.org/arch/msg/inventory-yang/wn9iGN2koZOByodguzQ9vxedv2Y/

My suggestion is:

italobusi commented 9 months ago

Closed by the new IVY WG