Minutes IETF125: ivy: Tue 06:00
minutes-125-ivy-202603170600-01

1) Title: Administrivia - WG Status - Reporting on WG drafts not being
presented
Presenter: Chairs

Bo Wu: An update on the status of
draft-ietf-ivy-network-inventory-software: it has not been udpated since
last IETF meeting. The draft is mature, it only requires example fixes
and base inventory reference updates.

2) Title: A YANG Data Model for Network Inventory Location
Draft:
https://datatracker.ietf.org/doc/draft-ietf-ivy-network-inventory-location-05

Presenter: Bo Wu

Discussion centered specially centered into the RO, RW parameteres. RW
required for planning and Intent Based Solutions.

Bo Wu: Proposal is to start with RO and then move to RW in a second
phase.

Daniele Ceccarelli: I have some doubts about the the planning of
inventory location. The provisioning of a service is intent-based, but I
don't understand what is the intent-based part in a location. Location
is location, so where is the intent?

Bo Wu: I think Italo mentioned that there could be the plan of network
elements which will be installed in a specific site, and then the work
order is sent and the device is boot up and connected to the controller.

Daniele Ceccarelli: But then there is the problem of possible
misalignment between the the OSS and the controller. It's something that
doesn't just apply to location, but potentially applies to everything
that that can go read-write, right?

Bo Wu: Yes, the plan is that it also applies to the base inventory and
software inventory, and maybe also entitlement.

Daniele Ceccarelli: How to address the potenial misalignment issues? One
is the source of truth and the other needs to align with what is there.

Bo Wu: Brad mentioned that we could specify our use cases, but this is
beyond the scope of our existing models.

Aihua Guo: We had this disussion in the side meeting yesterday. We'd
like to move forward quickly with the RO approach. Then in the second
phase, we consider doing a revision of base inventory to support write
mode. Regarding the misalignment issue, we considered a few options, but
don't really have a final solution. The minimum is that you can push it
out of the scope and leave the controller to deal with all the
inconsistencies.

Daniele Ceccarelli: Please take the discussion to the mailling list.

Italo Busi: This issue is not only for inventory location, but also for
base inventory as well as passive inventory. It is very simple to make
it "config true", but the complexity is about the misalignment and
conflict.

Mahesh Jethanandani: What are the two phases? You publish it and then do
a BIS version? Open question to Operators if it is desireable to follow
this way.

Brad Peters: The churn is desirable or at least acceptable if it leads
to something that is usable.

Italo Busi: I don't think it is a big churn. It is an evolution and
backward compatible. Phase 2 will be incremental (BC change) more than a
refacto, like adding a new attribute to enable new features with no
impact on existing applications working on a RO model.

Mahesh Jethanandani: I agree it is backward compatible change, but I was
concerned about the process of developing revision I-Ds.

Daniele Ceccarelli: The reason why we we had this approach of phase 1
and phase 2 is that in the meanwhile we deliver it, it's usable, and so
the new version phase 2 will just allow new use cases.

Italo Busi: I am looking forward to VELOCE here.

Nigel Davis: I want to support Italo that we want to deliver this work
faster. I also think some of this transitions will become more
straightforward when we move forward into LLM, becuase we will get
support in validation of models.

Discuss around adding rack attributes to support classification:

Brad Peters: It is basically just the characteristics of the rack,
right? Because there's different types of rack and you get security
racks that are lockable. So generally in Australia three different
version in terms of Class A, Class B, and Class C racks, but that's
really where the question originated from.

Daniele Ceccarelli: Please take this issue to the mailling list to get
more feedback.

polls: Is generic rack-classification sufficient for this issue?
Yes: 8/30; No: 0/30

3) Title: A YANG Network Data Model for Inventory Topology Mapping
Draft:
https://datatracker.ietf.org/doc/draft-ietf-ivy-network-inventory-topology-06

Presenter: Bo Wu

Olga Havel: We did a hackathon on the knowledge graph where we imported
SIMAP, base inventory, passive inventory, and inventory topology. Two
comments: 1) why you have two different topology inventories? We need to
extend the node for the passive device, why would you model them
differently? 2) We need relationship from link to cable.

Bo Wu: I am unsure if the comment is to this model or it is to passive
inventory model.

Olga Havel: It is for both. I do not understand why this model does not
include references to the passive inventory. And then the link would
need a ref to the cable ID.

Bo Wu: We think the cable is a general one. And there could be like a
Wi-Fi SEED. And also there could be lease line inventories. They can
augment this general topology to enrich this.

Olga Havel: But we need traceability for physical to service, we need
traceability for service to physical. So if I don't have that semantic
relationship to cable and passive device, I cannot figure out where the
problem may be.

Bo Wu: We suggest this to be addressed in passive inventory work.

Mohamed Boucadair: Passive inventory is not yet a WG adopted model. This
document is only for the base inventory. The navigation to the passive
inventory should be done in the passive inventory document.

Italo Busi: The reason is that the current approach is not to expose the
passive devices in the inventory and therefore you need to navigate from
the TP to the port and follow the cables' A-end Z-end. Another option we
discussed in the side meeting yesterday is to expose the passive devices
in the topology and then associate the link with the cable: in this case
there is no need for A-end and Z-end information in the cable. But,
given the comment of Med, this is an issue to be discussed within the
passive inventory I-D.

Dan Voyer(from chat):I think this is important work and a necessary
bridge between inventory and operational topology. Without this mapping,
it’s much harder to build clean automation and assurance workflows.
Perhaps we should keep the first step focused and make the ownership of
the mapping data very explicit. This work needs to keep going.

Brad Peters(from chat): I agree Dan.

Brad Peters(from chat): So perhaps I'll write my Use Cases that we use.

Brad Peters(from chat): and for those the passive enclosures are
required as they are critical.

4) Title: A YANG Data Model for Passive Network Inventory
Draft:
https://datatracker.ietf.org/doc/draft-ygb-ivy-passive-network-inventory-04

Presenter: Aihua Guo

Mahesh Jethanandani: I like the proposed definition a lot better than
the previous one. Maybe a nit about the "carrying signal". If the cables
are in a closet, should they be reported?

Aihua Guo: If the operator choose to track those in the inventory, it is
okay. But it is optional if the operator does not care about the unused
ones.

Mahesh Jethanandani: I am trying to figure out the intent. If these
objects are maintained for purposes such as identification, location,
connectivity, and lifecycle management, an actively used cable certainly
will count as that, but how is something that's sitting in a closet
being identified? You will be naming all of those cables, you will have
definition for a language for them of where they are located?

Aihua Guo: You don't necessarily need to track those, but in the case
that you need to track those that are still not deployed or not
connected, you could do this with the inventory.

Mahesh Jethanandani: I will let the WG to decide whether they want to
track all those unused cables or not.

5) Title: A YANG Module for Entitlement Inventory
Draft:
https://datatracker.ietf.org/doc/draft-ietf-ivy-entitlement-inventory-02

Presenter: Diego Lopez

Kent Watsen: A device that supports VPNs might have a variable called
max_num_vpns which could be changed and exist in (see
draft-ietf-netmod-system-config). The value could be set based on the
hardware, or the version of the code, or the physical card being
inserted. None of them is related to licenses, but you could also
purchase a license to modify this value. I am expecting there to be a
variable defined in that is modifiable based on hardware type,
software version, presence of system resources, and licenses that have
been installed, etc.

Diego Lopez: This is beyond the scope of this draft, but within the
scope of draft-davis-ivy-equipment-capability-application. We decided to
split this content because discussion on capabilities were complicating
the core goal of entitlement inventory.

Kent Watsen: In this draft, is it the case that the entitlement model
support entitlements that add specific quantities (e.g., plus 100, plus
500 VPNs)?

Diego Lopez: Yes, this is precisely the core purpose of the module. We
adopted a practical approach to capabilities that is sufficient and
compatible with Nigel's ongoing work. For Camilo (my colleague from NTT)
and me, the economic aspect of entitlements (knowing which licenses you
have paid for) is a key part of the inventory, which is why we focused
on this practical approach.

Yuanyuan Yang: I have a quick question about the five maturity levels
you mentioned in your presentation. Are these levels strictly
sequential, or can operators choose based on their needs?

Diego Lopez: The idea is that they are strictly sequential. You cannot
reach Level 4 without first addressing Levels 1, 2, and 3. The model is
designed such that being at Level 3 implies you can address the
requirements and questions of Levels 1 and 2. For example, to support
capability reporting in the restricted environment we are discussing
(not the general capabilities Kent mentioned), you need to be aware of
your entitlements, where they are installed, and how they are
restricted. Thus, the levels build on each other, and you cannot skip
lower levels to directly adopt higher ones.

5) Title: Hackathon on YANG data model for network inventory
Presenter: Italo Busi

Nigel Davis: Information about the IETF 126 Hackathon will be shared on
the Hackathon site soon. The goal is to involve more vendors and seek
operator support to ensure the Hackathon is meaningful. The structure
will be similar to the recent Hackathon, with plans to include multiple
controller roles and multiple inventory roles. Additionally, the team
aims to compare IVY and TAPI, exploring whether to introduce useful
features from TAPI into IVY or remove unnecessary ones. Beyond IETF 126,
there is a plan for further work. The recent Hackathon was described as
a "wet-ish dry run" with real, proper data; instead of direct
connection, the team used the JSON file and plugged it into the adapter
(bypassing the connection part).