Wednesday, March 20, 2024
Session I: 09:30 - 11:30 (Australia – Eastern Time – Brisbane)
Room: Plaza-P3
(https://datatracker.ietf.org/meeting/119/floor-plan?room=p3)
Daniele Ceccarelli (daniele.ietf@gmail.com)
Qiufang Ma (maqiufang1@huawei.com)
Presenter: chairs
Session introduction & WG status
Presenter: Mahesh Jethanandani
Mahesh thanks Rob for his support of the working group as AD.
NOTE: It was noted on the IVY WG list, in the side meeting on 19 Mar
2024 and in this IVY session chat: The side meeting on 19 March 2024 to
discuss the BBF LS was a meeting of individuals to exchange
information between themselves about the topics noted in the liaison to
the extent of the information included in the liaison. (i.e., similar to
meeting in the hallway) It was not a meeting between BBF and IVY. No
decisions or work progress can be made in that meeting. Any
representations otherwise are erroneous. Any output or information from
that meeting must be brought into each respective group (BBF/IVY) for
discussion and debate to have any standing.
Mahesh: What did BBF want from their network resource model? Is there an
overlap between IVY and BBF work?
Daniele: Not so much an overlap, but want to use IVY work if possible.
They are building an SDN control for the access network. They have found
RFC 8345 and the IVY model. They want to undertsand the models and how
to extend them (and why we built the models the way they are).
Benoit Claise (NMOP cochair) - What is the role for NMOP and digital map
for the liaison reply?
Daniele: NMOP planning to update RFC 8345. From digital map point of
view - probably falls into scope of 8345 update.
Benoit: You mention one thing is inventory, the other is topology,
topology may be something within NMOP.
Daniele: NMOP has no WG doc to reference in the reply. We will make sure
to reference NMOP in the LS reply.
https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-01
Presenter: Chaode Yu
Quifang: Have authors identified any component-specific parameters?
Chaode: Currently no discussion. CCAMP had discussed, but we need to
revisit after this meeting.
Mahesh: you specified element managed by management system, but there
could be multiple management systems, is it network wide or domain?
Chaode: What do you mean network wide inventory. I think the current
model is network wide inventory model.
Mahesh: May need to clarify text seems to say single domain.
Daniele: Maybe that different controllers can seem only parts of the
network. Maybe export to an overarching orchestrator. We can clarify
that domain controllers export the inventory they can see and these can
be "stitched" together.
Mahesh: Comment on the prefix of the model, has already been used by
RFC8529. Maybe nivy.
Kent: Does it only restrict to hardware like line card or also licenses
and capability like numbers of VPNs that could be supported also be
considered?
Daniele: We don't target to use inventory to report how many VPNs can be
supported. There could be augmentation to satisfy such requirements but
we prefer not to include in the core model.
Chaode: Inventory has a broad concept. I agree to keep the base/core
model neat. Capability may need to be defined in the topology model. The
boundary between topology and inventory need to be clarified.
Daniele: Probably should be a seperate augmentation but I wouldn't call
it topology.
Italo: Respond to Mahesh's first comment: we can clarify that the model
could be used in hierarchical architecture. Topology can be used to
report how many VPNs can be supported by what is installed in the
network. It is challenging to report which board can be inserted in the
network or increase the number of supported VPNs.
Kireeti: To follow up what Kent has said: it's insteresting to have
capabilities of devices. It could be a seperate augmentation.
Bo Wu: We have a draft working on the relation between network topology
and inventory. Feedback is welcome.
Diego: We have already been working on the draft ALMO, we call it
features instead of capabilities but quite similar.
Juan Cardona (from chat): As Diego mentioned.. we are working on
"features' with respect of licenses (entitlements), and yes.. it would
be independent from the WG main model.
Mahesh: Question for Kireeti: spec like number of routes, isn't it
something that can be specified up front because system capability can
change?
Kireeti: Not want inventory to be a replacement of services. I would
like to see the capability (e.g., the support of VPN type and how many)
in the model.
Robert: Suggest to keep the base model simple, the rest of the
discussion of capabilities could be done as augmentation.
Kent: Integrating licencing with capabilities would be necessary.
Disagree with Rob to do the minimum possible to get it fast, that's not
going to meet the actual expectations of operators.
Daniele: I agree with Rob. Building an augmentation on top of that is
step two.
Kent: The topology augmentation was quite a mess because of the
simplicity of the model.
Benoit: I don't believe we should redefine the scope of this WG. This is
a pointer to different databases (capabilities, energy management,
performance metrics, etc). (Robert agrees)
Qin Wu: I support the proposal of inventory capability concept.
Italo: Trade-off between monster monolithic model and "too many models"
that have to be combined. Maybe the best approach is to be modular to be
more flexible and provide some applicability statements to describe how
the different modules can be put together to address a specific use
case.
The number of VPN you can support should be reported in the topology
model which is used to configure services and tunnels.
Chaode: We have two different capability. Static capablity (number of
VPNs supported) other current capability (what the current can support).
First should be license inventory not base model.
Aihua Gao: Topology can be more abstracted and is different from what is
in inventory model. We may consider adding capabilities to the inventory
model, but that is differnt from what we talk about in the topology
model.
Mohamed Boucadair (from chat): Agree with Daniele. The key point is to
carefully describe the provisions for more rich functionalities.
Mohamed Boucadair (from chat): Italo, capabilities can be separated from
topology. However, the actual activation/use in a context of a network,
topo is important. The top/inventory mapping I-D can be used then (with
the link with SAPs).
Robert (from chat): To handle capabilities properly may need YANG
language changes (e.g., part of the YANG Next) work, so that it is
possible for configuration constraints to reference the capabilities
during validation.
Juan Cardona (from chat): features/capabilities could be independent
defined from licenses, but we need them to define licenses because in
the number of vpns in the router is limited by a license, then the model
should be able to express this.
Rob (from chat): Regarding the discussion, it is worth noting the IVY WG
charter and milestones:
Jul 2024 Request publication of the below YANG data model.
Oct 2023 Adopt an Internet-Draft describing a core network inventory
YANG data model that can be used as a foundation by other YANG models to
establish technology-specific inventory models.
Presenter: Nigel Davis
Haomian: to confirm when we say 'out of scope' it means we suggest not
support these via augmentation of ivy models. (Nigel: Yes)
Haomian: for those 'in the scope' do we have a boundary for the base
model?
Nigel: We don't have a proper line yet.
Daniele: Our proposal is to have in the draft a definition followed by
an explicit list of what is in and what is out. Please send the proposal
of the list to the mailing list and then we discuss.
Robert: It's a tricky problem, I'm more insterested in what is scope
than what is explcitly out of scope, I suggest to say nothing in the
document about what is not in scope.
Daniele: We might have something in scope yet not be listed explicitly.
Robert: Some of these (what is out of scope now) may end up in the
charter. The current focus is on the base model, and then the WG may
recharter at that point then saying these things (out of scope). Good if
there could be some level of flexibility with them.
Joe: The terms specified as 'physical' is quite clear in the
presentation, but in the base model draft there is description about
'virtual network element'. Is it a physical thing?
Nigel: Virtual things is a grouping of stuff that has no hardware. It's
only functional things.
Joe: I will wait for the inventory list and reply there.
Mahesh: My current confusion is whether the capabilities description
belongs to ivy, or somewhere else?
Nigel: The capability is essential for network management but just
propose to leave it out of ivy.
Christopher Janz: I am trying to understand the motivational things.
What do you really intend in that category? Is the different between
operational status vs. non-operational status?
Nigel: There isn't jsut physical stuff information and function. It is a
more general term and I am not sure it goes anywhere.
Rob (from chat): Once that core work is done, then the WG may want to
discuss the next steps and recharter to explicitly cover the
extensions/augmentations that are being that it is interested in.
Marisol (from chat): Even in ALMO, it is not considered license or
entitlement as an asset, this could be changed, as i attribute type for
asset is considered, where we should consider entitlement/license as
augmented model from the ASSET YANG model. We will appreciate if we
could get consensus on this point from the WG.
Presenter: Italo Busi
Kent: Happy to see this. Use case I have is to pre-provision a device in
the network especially for ZTP where device has not yet been placed into
network but I have modeled the network as if some devices exist and I've
even configured services on that network, when the equipment show up I
want the services to turn on automatically. Another use case part of
being able to do that is the notion of a connector, e.g. a chasis with
PIM slots, but might have different versions of PIM slots. When I am
trying to model my network equipment, I am able to make those
connections. Does this make sense and does it match what you are trying
to do?
Italo: We are discussing that, that is part of the planning. You want to
do this from northbound of controller? Yes, this is an important use
case to consider. At the moment we only capture what is installed but
this is still under discussion.
Nigel: We have to be careful with planning. If I already know what I am
going to put in there, that could in scope. The way out of scope is
probably the vague abstraction planning.
Kireeti: Why are we so stuck in physical? Let's treat virtual NE as a
full-fledged member of this. Planning is really important. If we do
capability, should we do it in CCAMP, or IVY?
Italo: Capability should be in topology model, OTN capability is a node
in the OTN topology, layer three capability is a node in the IP
topology. If I need to set up a service between P1 and P2, I don't care
about which network elements they are, I need to know are P1 and P2 have
enough VRFs. Another question would be I know P1 doesn't have enough
VRFs but I want more VRFs so the question is which kind of board do I
need to buy. That is more complex.
Kireeti: I agree with you, the question is where should this be
discussed. Even it is probably out of scope of IVY, it might be in scope
of somewhere.
Daniele: The way I prefer is let's do the work and let's see if it fits
here or not.
Diego: We should try to avoid the distinction between physical and
virtual, because at the end we should treat the whole thing the same. A
physical thing you have in a box is as virtual as a software image you
have not installed. Once you have installed the physical thing, you
deploy the virtual thing.
We may put a note somewhere this can be physical or virtual.
Daniele: We need to be clear about the virtualized switching routing
function and what virtual thing is in, and what virtual thing is out.
Diego: I would not make the distinction between this is a physical sutff
and this is a virtual stuff. At the end we are going to treat the same.
The intention of making a unique guidance about how to use it should be
something we should avoid.
Haomian: I am trying to figure out who is the right person to use the
inventory model, the maintenance team is responsible for maintenance of
physical things to identify what is the problem during troubleshooting,
and travel onsite to work. For the informational things, it can be
people sitting at the office to do investment evaluations. It is hard to
believe two people I describe can be one single person. I suggest to
seprate these two models.
Nigel: We need to be careful not to put the word physical amongst the
functional things. We need physical for purely physical.
https://datatracker.ietf.org/doc/html/draft-wbbpb-ivy-network-inventory-location-00
Presenter: Bo Wu
Daniele: For sure this is part of our charter.
Diego: This is valuable, but there are other cases where informational
stuff that is not deployed, it can be somewhere in a repo/databse, it
would be important to deal with these locations as well. This is
something authors can consider, or leave as augmentation in the future.
Daniele: What type of location information would you foresee?
Diego: Typically a URI would be more general.
Mahesh: Are we moving the location information out of the CCAMP WG
document to the draft here?
Daniele: The origin plan was to do every non-technology specific work
here, and technology specific work there. But we realize that the
distinction is hard to do, probably we can consider moving a network
here.
Kent: Operators have different ways to describe locations. Some talks
city building floor, others talk about states and etc, racks can also be
called differently. Hardcoding values/labels would need to be cautious.
I would allow the operator to specify their own hierarchy of location
types and allow opertors to use the term they are familar with.
Vishnu Beeram (from chat): Does "velocity" (from the imported
geo-location module) make sense for network inventory location?
https://datatracker.ietf.org/doc/html/draft-palmero-ivy-ps-almo-00
https://datatracker.ietf.org/doc/html/draft-palmero-ivy-dmalmo-00
Presenter: Diego Lopez
Daniele: Do you think some features like the number of supported VPNs
could fit here?
Diego: Let's distinguish the feature and capability (need to check with
co-authors).
https://datatracker.ietf.org/doc/draft-cwbgp-ivy-energy-saving-management-01
Presenter: Qin Wu
Daniele: How this draft is related to the power management work proposed
by Tony Li?
Marisol (from chat): I had the same question than Danielle, as I see
similarities with Tony's draft and POWEFF as well. There is a side
meeting tomorrow 9:00 am to discuss on power metrics, it will be great
to have further discussion there.
Qin Wu: We need to work together, we have similar goal but different
solutions currently.
Daniele: A question to Mahesh: should we consider only work that is
purely related to inventory, should we refrain to do any work on green
networking?
Mahesh: I had a discussion with Rob, there is going to be a WG forming
BOF targeting for IETF 120. At this point work like this one could be
deferred and wait for that WG to be formed. this is certainly not in
scope in IVY.
Daniele: Stuff which is purely inventory related like the power
consumption of a given device that is something inventory in the end. Do
you expect the new WG to augment the inventory core model when it comes
to inventory related stuff? Or it will be completely decoupled?
Mahesh: I don't have the charter details in what the WG is going to be.
Is it an augmentation? that is a question WG can try to figure out, I
don't have an opinion.
Rob: Why I am trying to suggest doing a BOF is trying to get the power
management related stuff both states and control to be standardized
quickly. BOF charter discussion would be a good place to decide where
the work happens, I think it would be best for the work to happen within
the new WG if it gets formed. Having one home for the stuff would help.
Daniele: If you are working on the charter, if you could specify
somewhere everything that is inventory related should be on top of
inventory model, that would be helpful.
Rob: You can write whatever you like in the charter, but it is not going
to be me writing the charter.
Kent: I am wondering about the applicability and happy to know there is
going to be a new WG. I filed a patent for power based routing 20 years
ago which is about certain DCs have solar panels and you can calculate
the route that would actually have the most renewable energy, which
seems more important to me than worrying about the power of a specific
device.
Daniele: Agree, that's more a power metric you're using in routing. What
fits more in the inventory is not just how much power a given device
comsumes but where that power comes from.
Qin: A question to AD: Can we create a mailing list for dedicate
discussion?
Rob: Yes, that will happen.
Marisol: There is a side meeting on power metrics and we would like to
put all related work together and discuss our next steps. We are
considering using inventory model in IVY, we're building on top of ALMO.