https://datatracker.ietf.org/meeting/121/materials/agenda-121-ivy
Thursday, November 7, 2024
Session II: 13:00 - 15:00 (Europe - Dubin)
Room: Liffey MR 2
(https://datatracker.ietf.org/meeting/121/floor-plan?room=liffey-mr-2)
Meetecho: https://meetings.conf.meetecho.com/ietf121/?session=33391
Onsite tool:
https://meetings.conf.meetecho.com/onsite121/?session=33391
Audio Only: https://mp3.conf.meetecho.com/ietf121/33391.m3u
Chat Only: https://zulip.ietf.org/#narrow/stream/ivy
slides: https://datatracker.ietf.org/meeting/121/session/ivy
Notes: https://notes.ietf.org/notes-ietf-121-ivy
Daniele Ceccarelli (daniele.ietf@gmail.com)
Qiufang Ma (maqiufang1@huawei.com)
Mahesh Jethanandani: For the liaison statement, a silence is consent. So
if we get a liaison which we don't respond to, it would be considered
that there is no objection from IETF. If there is any liaison and we
feel the need to response or give some information, let's make sure we
respond.
Port and Breakout modelling:
Mahesh Jethanandani: Suggestion on how to move forward, if there are not
many replies, take a stand, put it in the draft and move forward. If
anyone has any objections, they will come back.
Mahesh Jethanandani: What is the question about updating IANA YANG
module? Is it a process issue?
Chaode Yu: Yes.
Mahesh Jethanandani: There is a documented way of how to update IANA
YANG module, I am happy to show you how to do that.
Daniele Ceccarelli：Why you need to update RFC 8348? Why our network
model would depend on the device model in RFC 8348?
Chaode Yu: Because we have different modeling of port, and we have
concern maybe the current RFC 8348 cannot cover all the focused
scenarios.
Daniele Ceccarelli: So it is a work independent of what we are doing
here. Do you remember which working group RFC 8348 belongs to? We have
to coordinate with them and see if they are happy.
Camilo Cardona: Let's continue with OpenConfig solution and then we
figure out how useful it can be.
Italo Busi: The IANA YANG module has been defined in RFC 8348 and there
is some definition which are ambiguous，we need to understand what
happens to RFC 8348 if we update IANA hardware YANG. Or maybe we can
decide not to reuse IANA, that is another option. Or we keep the current
YANG and we put some description how we interpret these identities.
Daniele Ceccarelli: If we consider making an update of RFC 8348, maybe
we can clarify the text there.
Italo Busi: I would like not to have dependency on RFC8348bis.
Qiufang Ma: RFC 8348 is a device model produced by NETMOD WG, if folks
have interests, an I-D could be submitted and discussed in NETMOD, but I
don't wish this work depends on it and to be delayed.
Energy Object
Daniele Ceccarelli: We would like some guidance from AD Mahesh: There
are some green parameters which don't change over time, we think those
fall into the scope of IVY. Whether they should be addressed as part of
inventory here, or in GREEN WG?
Mahesh Jethanandani: My initial thought would be to stay in this WG.
Diego Lopez (Green Chair): What we are doing is trying to categorize a
particular component that has something to do with energy. We consider
inventory as connection. I don't see how this can cause any conflicts.
Robert Wilton (Green Chair): Focus on terminology and metrics is number
one in Green, and the modeling would follow on a little bit after that.
There are already some modeling work, some amend the inventory model. It
is possible that some attributes might move into inventory models. I
would suggest not losing it now and keep it here, but keep in mind that
you may need to pull this out at some point in the process and move it
elsewhere.
Italo Busi: this identity is already defined in the IANA module and
imported by the base inventory model and could be used by
implementations of the base inventory model. The definition seems not
clear and it is hard to re-use it to define the component as a
generalization of this entity. We can not reference this entity for the
definition and indicate that more work on this component is needed in
the context of Energy Inventory which is outside the scope of the base
inventory.
Marisol Palmero (from chat): I believe the description for this
energy-object is vague.
Daniele Ceccarelli: Maybe when GREEN settles down a little bit, we can
have a joint interim meeting and discuss on this.
Mahesh Jethanandani: Have we approached the authors of RFC 8348? That
might be a first step; if there is something unclear, maybe the module
needs update to better clarify.
Robert Wilton: I would propose to be just silent about this component in
the draft.
Marisol Palmero (from chat): +1 for Rob to do not mention about the
energy-object, there are other ways to identify and link IVY work,
basically components and network elements... through augmentation.
Italo Busi (from chat): Ok for me to be silent on the energy object.
Mahesh Jethanandani (from chat): How is an implementation supposed to
react if the client configures the identity? In other words, I do not
know if one can be silent.
Italo Busi (from chat): I would say that this behavior is unspecified
likewise RFC 8348 implementations.
Italo Busi (from chat): Future work in coordination between IVY and
Green WGs would help clarifying the behavior but IMHO this should be
outside the scope of the first version of the base inventory draft.
Italo Busi (from chat): We can either be explicit on this ambiguity or
keep silent (as proposed by Rob).
Stack Component
Camilo Cardona: I want to see all the chassis in the network element so
please put a MUST or a SHOULD to report all the elements. If you have a
multi-shelf switch in which you have a switch under a router extending
the router, the interfaces from the switch become part of the router and
it really behaves as a single element, then when you query the router
for all its elements, I want to see all of them.
Next Steps
Daniele Ceccarelli: please send a list of the priorities to the mailing
list to check that the WG agrees with the prioritization.
Poll: Is the draft ready for WG adoption?
Yes: 18
No: 0
No opinion: 0
Swamynathan Balasundaram: I saw a lot of focus in the draft is about the
software instances that are running, but not on software images, is this
something going to be covered in the draft?
Aihua Guo: Could you please clarify why the previous-revision parameter
is removed as well?
Bo Wu: Software updates should not be inventory, it should be another
functionality.
Aihua Guo: I suggest to add the history revisions at least the previous
one.
Bo Wu: We just considered the minimum in the current draft, may we can
discuss further if more functionality needs to be supported.
Camilo Cardona: Regarding the software which is there but not installed,
we had the same question for the hardware inventory. That is part of the
lifecycle management of the asset. It might be more important sometimes
of what is installed because this is what you have to solve problems. It
is a general problem that needs to be solved.
Daniele Ceccarelli: How would a SDN controller know you have some
hardware that has not yet there?
Camilo Cardona: In our implementation, we have APIs for the people that
have inventory in stock.
Mahesh Jethanandani: If something is not being used, is it part of
inventory or not? I had the similar question. Regarding software,
software has a separate lifecycle from the hardware, I think it should
be separated from the inventory model itself.
Poll: Should we define features?
Yes: 6
No: 8
No opinion: 7
Mahesh Jethanandani: My first reaction was KIS (keep it simple/stupid).
I would start with something more well-defined. Stick to licensing and
don't worry about other features/capabilities, at least initially.
Camilo Cardona: That is not going to be useful for us. We already have
other models that does it, but we don't really find use for it. It is
not fine by me, but if it is fine by others, that's okay.
Mahesh Jethanandani: What do you mean by features? Are you modeling
hardware features of the box? Capability of the box?
Camilo Cardona: People don't say capability, people say feature. I am
fine with capability.
Mahesh Jethanandani: My concern is that I don't think we've clearly
defined what is the feature.
Daniele Ceccarelli: we can take a No as it's defined now.
Qiufang Ma (from chat): It might be confusing as we already have a YANG
statement called feature in 7950.
Robert Wilton: People don't understand what feature is, it's too vague.
So you are not getting an answer. The term also conflicts with YANG
feature. I am wondering whether you can find an alternative name that is
a bit more specific.
Camilo Cardona: It could be capability/function, I guess.
Marisol Palmero (from chat): Feature is defined in the ALMO from early
versions. Features: are options or functional capabilities offered by an
asset.
Camilo Cardona: At the end of the question it would be are you intereted
in modeling whether your box can do whatever capability?
Robert Wilton: Generally yes, a lot of devices and platforms will have
these capabilities that can be turned on/off or licensed separately. You
need use another different term other than feature and narrow it down
and it's not a YANG feature.
Camilo Cardona: Definitely not the YANG feature, it is the capability of
a device. What we are trying to answer is you have a model in which you
can know my device is not allowed to do MPLS because it doesn't have the
license to do it.
Robert Wilton: If YANG package work gets finalized and finished soon, I
would maybe tie it to YANG package definition which exposes like the
MPLS and optional capabilities. But it is about software only.
Camilo Cardona: We could link it and define it elsewhere. But I was
thinking initially this is just a string.
Robert Wilton: Package only ties to what is defined by either IETF or
others. You may some capabilities and features that have no
manageability interface.
Sherif Mostafa (from chat): but I'd say it's then part of the
intent...intent1 needs MPLS while intent2 doesn't for the same device.
Qiufang Ma: I think it is fine if you include a string type parameter
inside the entitlement list to describe what specific functionality will
be granted if the entitlement is activated. But we may not need to
standardize capability/feature itself, this is something hard to do and
the granularity is hard to balance.
Daniele Ceccarelli: Since we don't have a clear list of features, I tend
to agree with Qiufang. The question is are we in a position to define a
list of features to standardize, or that is something generic and we
leave the tool to carry the information but we don't standardize what
the information is.
Camilo Cardona: Agree with that.
Robert Wilton (from chat): Rather than feature would it make sense to
tie it back to components?
Bo Wu: You mentioned MPLS as a feature, but we also have the MPLS LDP,
MPLS TE, etc. so we cannot see whether there is a clear granularity to
different vendor implementations.
Camilo Cardona: It is just a string. It is a list that others can
reference. We can model it further.
Swamynathan Balasundaram: Would it just simply be a list, or would it
also include some other metric? E.g., you are entitled to have X number
of tunnels. If you have so much details, do you image that this is
something that would be available in the network?
Camilo Cardona: X number of tunnels is about restrictions rather than
feature. The second question is more about the license server that
provide this information.
Daniele Ceccarelli: Potentially it is something that you may want to
configure on the SDN controller and expose it to various consumers.
Camilo Cardona: Suppose you have 7750 in your stock, but it has an
entitlement that doesn't allow this line card to work on its entitled
bandwidth, in this case you can know that before and your license can
have that information.
James Cumming: If we create a generic string for some feature, where
from the programmatic perspective would this information be used?
Camilo Cardona: Some person reading the inventory, at the end you can
query whether your 7750 supports MPLS-Nokia version.
James Cumming: Were you not anticipating that in some programmatic way
you'd understand what MPLS-Nokia meant.
Camilo Cardona: It is very hard and complex. We are trying to keep it
simple.
Robert Wilton: When things are modeled in OpenConfig, you can create
components of like arbitrary complexity down the graph, if you have a
software, you might have components within that software which then
split out into something like MPLS package. I am wondering whether a
feature could be something arbitrarily in that component tree or
hierarchy?
Camilo Cardona: I see feature is like a software component in which
general functionality is provided in MPLS. But then you have to give
permission to the network element to use your component.
Robert Wilton: In OpenConfig model, feature might just be augmented
property onto any component. I am not saying we should follow OpenConfig
model because it ends up with complex structures.
Camilo Cardona: That way feature would be a component, and would be an
asset. I have nothing against that.
Robert Wilton: It might be worth considering it. The only thought is
trying to give flexibility of how people model things and get beyond it
just being a string which is sort of untyped and doesn't mean anything.
I am not saying about doing it, I am saying about thinking it.
Mahesh Jethanandani (from chat): I am still struggling with the use case
for trying to define features.
Mahesh Jethanandani: I have to admit I am still struggling with the use
case. This is a good time for us to ask operators here do they have a
use case for this? And how do they see the use of features/capabilities?
Marisol Palmero (from chat): I have one, linked to GREEN. There are
capabilities that consume more energy than others, and there are power
modes to be enabled on network devices.
Daniele Ceccarelli: Let's continue the discussion on the list, where we
may get more feedback.
Kent Watsen: there are requirements in Quantum networking to report the
length in millimeters so uint32 is not sufficient. It could be measured
in meters with decimal64 with three decimal digits.
Aihua Guo: the measurement unit is something we can further discuss.
Bo Wu: can we split the cable and passive device models into different
models?
Aihua Guo: One of the reason of the cable and passive devices being
defined in a single model is that e.g., in access domains you want to
track the list of cables and also the passive device along the path.
Bo Wu: Cable is quite general, but I am not sure in campus and IP
scenarios we use passive devices. Hopefully they won't be coupled in one
model.
Aihua Guo: We could consider defining separate modules.
Olga Havel: How this is related to the topology part? this looks like a
topological relationship, e.g., a potential link that consists of
multiple links, is this showing topological information between the
devices?
Aihua Guo: Yes to some extend. But inventory is a list of devices which
could be used to build the topological relationship.
Olga Havel: This looks like a combination of inventory and topology.
Aihua Guo: There could be a mapping from the topology to the inventory,
we need to think more about that.
Italo Busi: I am not sure passive components are not used in IP networks
especially where there are long links with no optical networks in
between. However, there are some cases where the passive devices and
cable segments are known and other where they are not known (as passive
components, they cannot be discovered by the controller). So we may
think about more flexible mechanisms to modularize the model (e.g., YANG
features) rather than splitting the model into two models.
Aihua Guo: We don't make any assumptions about how the controller knows
about the information, this is out of scope.
Kent Watsen: in Quantum network the passive device (optical cable
connectors) can have its own length and attenuation. Can we add this
information to the model?
Aihua Guo: It is possible to model the internal structure of the passive
devices. We've already described how the fibers are switched in this
device and connected.
Kent Watsen: When we capture the DB loss data, sometimes it is measured,
other times it is estimated. It is excellent if the model could capture
whether or not the value was measure vs. estimated. Sometimes it is also
necessary to put a timestamp of when it was measured, especially when
you deal with environmental conditions like temperature.
Julien Meuric: What Kent has specified is exactly the problem we've
already addressed when doing the optical announcement of topology. It
does make sense to include it. Good news is that we are not starting
from scratch within IETF.