Minutes IETF120: ivy: Wed 16:30
minutes-120-ivy-202407241630-00

Agenda for the IVY 120 WG Session

https://datatracker.ietf.org/meeting/120/materials/agenda-120-ivy

Session:

Wednesday, July 24, 2024
Session I: 09:30 - 11:30 (America – Pacific Time – Vancouver)
Room: Plaza C
(https://datatracker.ietf.org/meeting/120/floor-plan?room=plaza-c)

Available During Session:

Meetecho: https://meetings.conf.meetecho.com/ietf120/?session=33031
Onsite tool:
https://meetings.conf.meetecho.com/onsite120/?session=33031
Audio Only: https://mp3.conf.meetecho.com/ietf120/33031.m3u
Chat Only: https://zulip.ietf.org/#narrow/stream/ivy
slides: https://datatracker.ietf.org/meeting/120/session/ivy
Notes: https://notes.ietf.org/notes-ietf-120-ivy

WG Chairs:

Daniele Ceccarelli (daniele.ietf@gmail.com)
Qiufang Ma (maqiufang1@huawei.com)

Slot Information:

1). Introduction (10 min)
Presenter: chairs
Session introduction & WG status

2). A YANG Data Model for Network Inventory (30 min)
https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-03

Presenter: Italo Busi

Brad Peters(chat window): There are also the ability to accomadate card
that support daughter boards or plugin media adapters. So you have a
card, that supports plugin cards, that support ports.

Joe: Some of this feels way too complex. I want the FRU, so if it is
pluggable, I want to have it as a module in a container. Beyond that, I
want to know the connector type and port mode (fiber port/multi
mode/single mode), I don't care about the pins and lambas. Short answer
is keep it simple, I don't know the right answer, but the open config
way looked like it to me.

Italo: Agree to make it simple, but the different cases complicate the
modeling ways.

Joe: From the physical inventory perspective, maybe we don't need to
care about the logical breakout interfaces. All I need to know is that I
have a breakout connector here.

Mahesh: I do agree with Joe on some of the points he mentioned. You are
probably looking at defining things at a RMA level, e.g., is the port
empty? if not, what is plugged into it?

Qin Wu (chat window): Agree with Joe , aligh with openconfig and keep it
simple is the right way to go.

Camilo: Apologize that I open the discussion on the breakout. We really
need it, it is part of the inventory. I could give you some examples if
you need them.

Italo: All the cases are dirven by optical, but also applicable to IP
routers. The breakout is even more used on routers than optical devices.
The breakout cable is hard to know, I cannot know whether the cable
attached to the connector is breaking up.

Rob: I have some experience in breakout stuff. The difference between
modules and ports is that you have modular cards that can be plugged in,
and within modular cards, they will have modular ports. So I will keep
the ports to be plugable optics and module is something higher. I don't
understand your naming example where it went from like 3 to 2, the
number sequence was confusing to me. I don't really understand the
distinction between case 1) and 4), I would think they are probably the
same. In terms of modeling, the TAPI modeling looks complicate to me. If
we can align with openconfig, I think it is a benefit to industry.
Regarding whether you should see breakout in inventory, probably should
be there in some level. Agree with both Mahesh and Joe to keep it
simple.

Daniele: I try to split my chair comments with contributor comments but
I failed. OpenConfig seems simplest to me. OpenConfig is also very
widely deployed. you're saving some effort in translation. Regarding
simplicity: I spoke to multiple people, we all think it is extremely
useful work if it comes in a timely manner. Suggest that we don't cover
some cases to keep the model simple, and address a set of use cases, and
then look at extending to cover more in future. Regarding network model:
Controllers can be separate for IP and optics. Would it make sense to
split between packet model and optical model?

Italo: I understand the pressure to deliver this model as quick as
possible. We can always do a bis. I don't really see in these cases
which is specific to optical, and which is specific to IP. I don't see
how we can resolve this by splitting.

Oscar: Main use case is for IP/Optical - don't split it. I like open
config approach, too, but we need some guidelines. Can we find a
definition of port. Everyone used to know what a port is. E.g., is the
hole (option 2 on slide 7) a port.

Italo: Someone calls these pluggable ports.

Oscar: We are mixing up what is a port and what is a hole. Some
implementations create intermediate components, which can help, and then
the transceiver becomes a child component. I would like the WG to give a
clear definition of port and whether we need to model these holes.
Sometimes empty holes are advertises, and some others don't.

Italo: We can discuss whether the empty holes need to be modeled. We can
make some recommendation in the document.

Oscar: Do we want to call it a port or call it a hole?

Italo: We want to call it a hole, But I have heard some model it one
way, others model it a different way. There is no right or wrong, we
just need to agree.

Oscar: I Would like a common set of recommendations on how these are
modeled even aligning with open config.

Italo: I agree on the guidance, but need to reach agreement on what the
solution is.

Rob (chat window): I agree with Oscar's comment that having industry
guidance on how to model this would be helpful.

Kent: I didn't see you mention the SNMP entity MIB. I mention this,
because I used it at Juniper. They used the term enclosure, and it did
model the cables. You model the cables like it is a device, and in the
topology model you have the link to it.

Italo: Maybe we can talk offline.

Mahesh: Do you want to have a poll to try and resolve this or resolve
this on the list, but please try and figure this out. What is the
dependency on peer-mount. Are you blocked on this?

Italo: No, I don't think that we will be blocked. It might help simplify
our life, but we can progress without it.

Diego: Perhaps we should consider alignment of the styles in modeling. I
will keep this slide deck to reuse them to illustrate how complex it
become. Rather than trying to solve these problems one-by-one can we
uplift and find a similar pattern (e.g., entitlements in DLMO). Perhaps
the patterns can be reused.

Italo: Yes, perhaps we can discuss this offline. Also discussed another
option, or inventory only reports what is installed, and then we can
have a separate model that defines the capabilities.

Nigel: Separation between logical and physical is critical (can you
measure it with a ruler). The pluggable is an equipment as mentioned
earlier, it has a serial number and it really ought to to modeled in the
same way as any other equipment. The representation of the holder is
very much of a capability statement, we don't really need it if we can
do a capability model, because if you don't have that then you will need
it in the inventory model. So it really comes down to whether we can do
a capability model. TAPI model is quite simple, and it provides
flexibilty. Simplicity isn't necessary in the model, but in the usage of
a subset of a model. Need to be careful of the number. Can't number the
connectors on the card, vs the connectors on the plug.

Robert Wilton (chat window): I agree that a capabilities model would be
useful, but I wouldn't pin this draft on to that work, because that
could take years (Daniele and Med agreed).

Victor: Thank you to everyone working on this. I am not sure if you
answered Camilo. Do you need some examples provided by
operators/vendors?

Italo: We can work out some examples. It just takes time.

Victor: If you need some samples, let us know. What does it imply if we
follow openconfig way? Do we need a 8348bis to align with openconfig
approach?

Italo: I put '-like' because we don't need take everything, we don't
need exact copy, just take what we think is useful.

Victor: But the proposal won't be to mount the model?

Italo: No.

Victor: We had a recent discusison in the digital map. Understand that
we would like to have a solution, but we also want to try hard to not
change the model in future. Let's take some effort and do it properly.

Wim: I did a lot of work in this area recently. If you look at inventory
system, it is also about parent/child relationships. We have good
knowledge now, but it will change and evolve. When I did the modelling
itself, it wasn't only IP and optical, but also needed to deal with
servers. Then I took a step back. Then looked to see if I can come up
with a model that is generic and agnostic to the implementations. Model
the parent/child relationship. When you instiate differnet hardware, it
has different characteristics. Modeling it generically allows it to be
very flexible/generic. Generic approach, is broadly applicable. Don't
need to be very specific. Used a key/value solution (but this would be
tricky in YANG).

Qin Wu (chat window): Rewrite rfc8348 is a not good idea since it has
already be very generic and should be seem as best practices. Using
openconfig as reference implementation is sufficient.

Brad Peters (chat window): I agree. the models are concrete realization
of existing physical and hence are brittle.

Italo: You can do key/value with augmentations in YANG.

Wim: Ideally want the flexibility. I'm able to model almost anything,
even things that I didn't need to think about.

Oscar: Call for folks to join in the discussion and hackathon - perhaps
we can have some implementations. Asked Kent to come.

Italo: What do you think will be the benefit of doing a hackathon.

Oscar: At least see the model actually populated and used.

Italo: What if all 3 options are equally good, toss a coin?

Oscar: We will be able to see it.

Mohamed Boucadair (chat window): I think Wim's comment is consistent
with the spirit of the claim of the base IVY inventory "This document
defines a base YANG data model for network inventory that is
application- and technology-agnostic". It is useful to remind that goal,
otherwise there is a risk that we will overload the model.

Rob: I agree to look into future possibilities. Wim mentioned a very
generic and flexible solution, but this also makes it hardware for
consumers of the data. If the model is flexible then provide strong
guidance/recommendation on how you generally expect to be used. I would
really like to see quite strong guidance. Regarding Hackathon: To save
effort, Pick one solution first, then do a hackathon on that model and
see if it works.

Italo: In CCAMP, we do the model flexible then give some applicability
statements and guidance for implementation.

Rob: That is reasonable, but please get them published at the same time,
because if vendors have modelled then they won't change if an
applicability model follows after. Agree about balance between designing
for now vs the future. It is a fine balance. Suggest trying to not
overreach but keep flexbility/extensibility in the design.

Kent: Parent child/relationship is very effective. When modelling for
Juniper. Sometimes electrical connections were fixed and others were
very flexible. With various to one relationships. IANA could be used
helpfully to build a common registry on these items that could be added
in future. We want to model network before existence of the network.

Italo: Ok, thank you.

Daniele: Move the remaining discussion to the mailing list.

Brad Peters (chat window): agreed with Mohamed...if consider technology
agnostic then the view of what is done today is a discussion on do these
fit into the proposal and the manner in which they do.

Brad Peters (chat window): being tech agnostic and future proof is
potentially difficult to achieve but I think Wim proposal is probably
correct and that you need to move towards a dynamic generic agnostic
ability to define and add to that model in run time...like using a graph
(think as suggested by wim) but then being able to deifne that in run.
so you write it in rdf for instance and make it dynamic...at least what
I am thinking.

3). Network Inventory Software Extensions and Inventory Topology YANG
Models (15 min)
https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-software-01

https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-topology-01

Presenter: Bo Wu

Presenting & comments on draft
(draft-wzwb-ivy-network-inventory-topology-01)

Olga: I think that this is something that we really need and I hope that
it is adopted. 2 comments to resolve after adoption: 1) I think that
'name' is needed everywhere, maybe there is a way we can model it for
usability outside of this relationship. 2) If we end up changing RFC
8345 then we might need to change some of the text because the current
text suggests a different approach. Perhaps the old descriptions are
misleading. We need to state somewhere that this is out of date.

Aihua: At moment we only have 1 to 1 relationship between nodes and
elements. Do we support the case where an abstract node can be supported
by several physical NEs (or the reverse) or is it always 1 to 1?

Bo: Currently we just consider 1 to 1 mapping, because it applies to
most cases.

Italo: Perhaps look at some text in the CCAMP draft which states the
mapping between network nodes and elements can be many to 1. One node in
physical topology and another groups the physical nodes avoid making the
mapping more complex.

Bo: I agree.

Tim Carey: Why did you feel the need to refer from topology model to the
inventory and not the other way around?

Bo: Inventory exists before topology. Because RFC8345 provides
overlay/underlay relation, by having reference to inventory we can have
more details about a node going to the inventory.

Mahesh: Perhaps a motivation is that you have a network already in
place. Not saying that one should be better than the other.

Wim: I think that's irrelevant to the model. Whether you instantiate the
model to get the data, or populate the model. This is about how you use
the model, which may depend on deployment (brownfield vs greenfield).

Mahesh: Do you have the inventory first or topology first?

Wim: These are two ways of using them. If you do the design first, then
inventory is the result of it; if you do the discovery, you already have
something, and then the inventory is the result of what you have. The
model itself doesn't care.

Tim Carey: Are you saying that it should not matter which way round they
are referenced?

Wim: It is a bi-directional relationship. Typically you assign a node to
a topology. Sometimes people do a lookup from a node and they want to
know the topology or the other way around.

Tim: You are saying that typically you start with the topology and you
are assigning or referencing inventory to that topology. I just wanted
to check that you have thought this though.

Quifang: Please take this to the mailing list.

Bo presenting on draft-wzwb-ivy-network-inventory-software-01:

Aihua Guo: Thanks for this work, I think that this is important work.
BBF and potentially looking at reusing some of this work. Hope the WG
can consider accelerating this work and initiating the WG adoption.

Bo: There is also the manifest draft in OPSAWG that defines the software
attributes, I think this can be consistent.

Daniele: Definitely in IVY scope.

4). Asset Lifecycle Management and Operations: A Problem Statement and
YANG Data Model (10 min)
https://datatracker.ietf.org/doc/html/draft-palmero-ivy-ps-almo-02
https://datatracker.ietf.org/doc/html/draft-palmero-ivy-dmalmo-02
Presenter: Camilo Cardona

Daniele (chair): I want to make a proposal: What about splitting out a
bit of the work that is within the work of the working group (e.g.,
entitlement). And the rest of the work (e.g., capabilities) perhaps need
to recharter the WG. Do you think it makes sense?

Camilo: Very simple yes/no licenses are pointless. Maybe for some
devices they are not enough. We need to have a model tht has more
context.

Diego: Don't agree that capability model doesn't fit into the charter.
Possibly the lifecycle management doesn't fit in, e.g., how to activate,
deactivate, compose capabilities, etc. Defining the purpose of a device
is just as valid as defining the physical device that is there. We can
discuss how we model some of this. Purpose of this is functional
description and is of equal value to inventory. It isn't a usage of
inventory.

Italo: Are there any attribute that are missing in the base model that
would needed for this model. I.e., need to check that you can build on
top of the base inventory.

Camilo: So far we think that we are good.

Mahesh: Thanks Daniele for bringing up the question of whether this fits
into charter. Clearly we always want to focus on the work that is in the
charter. Diego, do you agree that what is in charter is what should be
done?

Camilo: Entitlement is part of describing how a device can be used. If
the charter includes the work entitlement then describing the
entitlement requires a characteristic, knowing what a license
encompasses or not is important. In that case, I see the capability or
the feature is in the charter.

Diego: We are not proposing that we are going beyond the charter. To me,
charter also includes functional description of the system.

Daniele: Does entitlement include capabilities? The charter is open to
intpretation.

Camilo: I need the limits. I don't know how we call this. I need to know
what it covers.

Diego: We need this to describe functionality.

Camilo: I have a question about support contracts which cover whether a
device is allowed to have firmware updates. A group that manages the
network inventory needs this information.

Daniele: Discuss today is very good input for a discussion with Mahesh.

Marisol: We were discussing entitlement even before IVY exists, it
represents the rights obtained by the user that allow them to access and
utilize certain capabilities of the asset.

Daniele: We will do some brainstorming to understand how to go forward
in the best way for the WG. The feedback you give are more than
valuable.