Agenda for the IETF 118 IVY WG meeting

1. Introduction (10 mins)

chairs

Session introduction & WG status

2. A YANG Data Model for Network Inventory (15 mins)

draft:
https://datatracker.ietf.org/doc/html/draft-y3bp-ivy-network-inventory-yang-00

Presenter: Chaode Yu

Marisol: I think that the entitlement should cover more than just
the network inventory at the hardware software level.

Daniele: So you are you are suggesting to call it differently. So,
like, inventory entitlement, as opposed to some you're layering
entitlements in something like that. Is this your proposal?

Marisol: Yeah. Initially, when we were, part of the ops are working
group, we were calling it license and we had a discussion to rename it.
We agreed to call entitlement to the concept that we are bringing in
DMLMO

Chaode Yu: the feature is about the controller or application, not
the hardware and software inside the network element?

Marisol: Feature is the capability of the network device, it could
also be in an application level.

Nigel Davis: Wanted to see if you would consider the
expectation/intention aspect. e.g., you can say that a particular
component is expected in a place, and the wrong component is there. Will
you cover that in the framework?

Chaode Yu: Are you considering aligning with tapi?

Nigel: Not necessarily aligning with tapi. A feature in tapi that
allows you to identify what should be present in a particluar place.

Chaode Yu: consider it as our next step.

Nigel: You mention power. Consider temperature and other
environmental features as other augments.

Bo Wu: With base inventory model, WG seems to agree that the terms
should be defined in a base model. A framework section could be added to
give the whole picture and another section about the terms(e.g., how the
entitlement could be mapped to the network layer allowance).

Diego Lopez: General commment: what makes me uneasy is the
terminology misuse. Believe that inventory is about static data and not
about the dynamic properties of the network model -- we have topology
models, routing models, etc for that. At the end, the inventory will be
linked with other models, but trying to avoid requiremrnt creep.
Reporting the cables (green cable, red cable) connecting devices is ok
since it is the physical element but this is not topology.

Benoit: I'm going to present in the last session. The last slides in
my slides are going to address the same point about topology. I fully
agree with Diego that the topology means higher level. Don't want to
fall into the trap of doing everything. We should all have the same keys
so we can go from one model to another.

Kireeti Kompella: Agree with Benoit that pointers should be easy --
eg should use the same key. Do we want other things in the inventory
aside from the topology -- eg what vlans does this device support, what
ip addresses are available? Or is the inventory is just the
physical/virtual devices in the topology?

Daniele: This is a question for the WG.

Kireeti Kompella: For the state of the device, if you look at
RFC8345, you have mostly devices that are in the network whether
physical or virtual. But also useful to have devices that are planned to
be in the network. So being able to model that would be useful. Is that
in the plan?

Daniele: When we wrote the charter we were considering what is in
the network, what was in the network and optionally, what will be in the
network.

Nigel: I agree on the topoogy point but think you might be talking
about cables which are physical. To clearify the reason why I raised the
temperature point, I wasn't intending temp to be a fundamental part of
the equipement model, but was intending it to be treated the same way as
power, etc.

Oscar de Dios: 2 points. First, if we want to cover what is planned,
this will lead us to mutiple inventories, want to stick to one inventory
view about what we're currently having. Second, cross references are
expensive. The pointer should be in topology and point to what we have
in inventory.

Daniele: Repond to the first point: this doesn't mean everything
needs to be in the same module, we can cover what we have now and
augment it in the future.

Italo: In the ccam draft in the inventory we focused on the physical
elements and capabilities, and then in the toplogy we reference. Idea is
to navigate from the topology to the inventory.

Alexander Clemm: To me the relevance of this model is to provide the
common anchor point. But I wouldn't necessary put all this functionality
in that. eg when you talk about cables that's a completely different
animal because you're talking about facility management, etc. Similarly
concerning the aspect of "is something expected to be there", this is
important but doesn't necessarily belong in this document. Needs a state
model, etc.

Rob Wilton (AD hat): In terms what the WG spends its time on, this
is the one piece of work that's obviously clearly in charter. Should
spend as much time as we need to to progress this work.

Rob Wilton: On this model, I'd like to understand how to extend it.
In terms of the component class augmenting it would mean all the
components would have these properties. So may be good to have a choice
statement so that (eg) you wouldn't see hardware properties in a
software component.

Chaode: There is a choice-based structure in the base model.

Rob: Oh, I didn't see it.

Olga Havel: There are other drafts in other WGs concerning different
layers. My concern is if we have different drafts in different WGs, we
won't have a consistent approach.

Chair: Are you proposing which WG? Or maybe this is a question for
Rob.

Rob: I want to focus on core inventory work first. Get that base
model done, then consider WG rechartering to bring that into scope.

Olga: No I'm talking about moving inventory out of ivy and into the
WG doing topology.

Rob: Not sure about that.

Kireeti Kompella: There is a draft in CCAMP WG called network
hardware inventory, plan for how to manage that draft?

daniele: Inventory for optical, but would dependent on this core
model. Quick comment: figure in section 3 is good, but moving on with
the documents, turn that into examples. We cannot mandate the future
extensions.

3. A YANG Network Data Model of Network Inventory Software Extensions (10 mins)

draft:
https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-software-00

Presenter: Bo Wu

Daniele: Regarding the WG adoption, our first priority now is the
network inventory core model. Will adopt others after that one is
adopted.

Joe Clarke: You have OS. Feels to me like it should be part of the
base inventory. Don't want to conflate it too much, but hardware runs
software and it feels like maybe it could be part of the base.

4. A Network Inventory Topology Model (10 mins)

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

Presenter: Bo Wu

Italo Busi: I think youre'a addressing 2 requirements: (1) the need
to have a physical topology view and (2) to be able to navigate from
topology to inventory. Would suggest you split the model to have a more
flexible way to address these requirements (eg without needing to
implement physical topology)

Bo: will consider that.

Olga Havel: First comment, the naming of network inventory topology
may be confusing and too generic. Second, maybe reuse the pattern of you
how do attributes, eg doing what OSPF/ISIS does. Also agree with the
previous point that we may want to go straight from L2/L3 to inv without
physical. The third thing is about the interface, we need a generic
approach to connect interface at all layers.

Aihua Gao: My understanding is you can have multiple network
elements that form the same node. The current Yang model has a 1:1
leafref.

Bo: I could make the model more flexible than a 1:1 mapping.

Diego Lopez: Consider changing the naming. Make it clear that the
physical inventory is the root that everything points to, when talking
about network elements.

Oscar: I would avoid using the term "port" because people might
misunderstand or think it's just a physical port.

Chair: Do you have a suggestion?

Oscar: Some related work in ccamp. Might be some terminology we can
use from there.

Chair: (Responding to Bo's summary) This work is in the charter.

5. A YANG Network Data Model of Network Inventory Entitlement/License (10 mins)

draft:
https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-entitlement-00

Presenter: Bo Wu

Chair: Would be helpful for the rest of the presentation if you make
it clear the difference between allowances and entitlements.

Bo: Clarified on slide 4.

Chair: Is the difference the level of abstraction?

Marisol Palmero: I'd like to highlight a couple of things. The
linkage that we do with the features/functionality with the base model
is to the asset. The arrow should go through the asset.

Marisol: In the almo modules, what we are looking at is the data
model. Whether it's the controller level, the orchestrator level, that's
an implementation detail.

Bo: Right now we don't have a standard definition of network
features. So in that way, the model augments the base inventory model.

Diego: With almo they're trying to focus on the lifecyle of the
network services that are provided and how you build those services and
make them available to users. A feature is what you're interested in
providing, eg optical connectivity end-to-end, etc. Feature is what
you're interested in, and you're connecting it to assets. With features,
the question is what those assets are able to provide.

Bo: Can L2VPN or L3VPN be a feature?

Diego: We're not tying to change the modelling of the VPN itself.
We're tying to say "to provide this VPN you need this set of elements".

Bo: I'm not clear what the granularity of that feature is.

Diego: You're assuming that there's a set of controllers, network
elements, etc that's not standardized. Almo can be used by a network
controller or not. We're trying to model the lifecycle of a set of
services, that's all. We're not proposing a concrete architecture for
managing the data model.

Bo: In IETF we have model classification. Not sure where the model
can be located.

Diego: Can you explain to me where the entitlement model fits? When
talking about the service, network and device models, a feature can
happen in the network model or the service model. We are not trying to
model a device or a particular service. We're trying to model what you
need to deal with to provide a particular service or network.

Bo: I'm not sure that issue is concerned with my draft.

Diego: I'm saying that, I believe it does not concern your draft,
but you mentioned the almo model. We're trying to model the lifecycle of
building a particular sercice. This is similar in some extent to saying
you have services, subs-services, and a hierachy to manage the assurance
of such services. This has the same philosophy as the SAIN model.

Bo: I agree.

Chaode: In my understanding, a feature could also be some other
stuff, eg the feature defined in the domain controller. Currently I
don't see any draft to define a feature on the controller level. If the
entitlement wants to cover the feature/lifecycle of the domain
controller this entitlement could be a separate data model.

Diego: Yes, they are independent. In one case, the controller knows
about what the device can do; in the other case it's about whether you
can provide a service with the pieces you have.

Daniele: when you compare the trees it is not clear why (e.g., is it
because the scope is the same and you are trying to to see which one is
better, or they have different scopes). Clarifying the scope is
important to understand who does what and where.

6. A YANG model for Power Management (15 mins)

draft: https://datatracker.ietf.org/doc/html/draft-li-ivy-power-01

Presenter: Ron Bonica

Jan Lindblad: Applaud this initiative. The direction you're pointing
is excellent. Some technical yang-related problems as menitoned on the
list. There are other initiatives elsewhere and it would be nice to
integrate with them. Suggest to join the IETF e-impact (IAB program)
mailing list ASAP.

Qin Qu: Lot of other relevant efforts, side meetings, etc. The model
for the traffic planning you define, is it a network model or a device
model?

Ron: Network level. But maybe you have a point and it should be at
the device level.

Qin: (Some points about whether certain items should hang off the
interface)

Ron: Take it to the list, I welcome suggestions.

Daniele: When we speak about power consumption, is there a
difference between a device model and network model?

Ron: I don't see the difference, but maybe there is a dif

Marisol: The power consumption is given by the network elements.
Ron, we are working on another draft, it's called power presented in
OPSAWG. Jan mentioned other initiatives. We have some overlapping
concepts. Should discuss whether to unify the approach. Appreciate it's
hard to do this for such a wide area.

Chaode: power consumption value is quite dynamic, do you want to use
it to report in real time?

Ron: Power consumption is dynamic, but not incredibly dynamic. Yes
there's dynamic behavior but not very much.

Chaode: The current model is working on the power management
solidifying the dependency relationship between power elements. But we
have a lot of other features, eg service configuration, performance
monitorying. Do we need to have another draft/model
to define that dependency?

Ron: I don't think so. There aren't that many service-reliant
components. It would just make the model too complex.

Chaode: Maybe you could define the dependency in the more generic
approach?

Oscar de Dios: What belongs to ivy? In inventory, what I'd like to
see is that information that is independent of what is happening. I
would suggest splitting off other parts.

Chair: Good question. Inventory means power consumption according to
the datasheet. Maybe other power elements don't fall under inventory but
might be something to discuss as part of rechartering.

Rob Wilton: I don't have an answer as to where this work belongs.
But I want the power management stuff to happen quickly.

Samier: I agree there is a mixture of things here. Maybe some
elements fit better in other places.

Chair: If there is a static power value read from the device, but
the user can configure power save mode, that might be confiusing.

Kireti: I think this work fits here in terms of the fine-grained
nature of power management while TE or global optimization for power
would probably belong elsewhere. Let's start by understanding what the
capabilities of the device are and what the components take, then move
on to the second aspect of how we can optimize.

7. Asset Lifecycle Management and Operations: A Problem Statement and YANG Data Model (10 mins)

draft:
https://datatracker.ietf.org/doc/html/draft-palmero-ivy-ps-almo-00
https://datatracker.ietf.org/doc/html/draft-palmero-ivy-dmalmo-00

Presenter: Marisol Palmero

Bo: (Request for clarification about whether/how the model augments
the base inventory model. Agreed to follow up on the list)

8. Mounting YANG-Defined Information from Remote Datastores (10 mins)

draft:
https://datatracker.ietf.org/doc/html/draft-clemm-netmod-peermount-02

Presenter: Alexander Clemm

Daniele: It seems that this work belongs to Netmod.

Alex: yes but IVY could make use of it for the inventory model

Robert: I think this work belongs to Netmod.

Qin Wu: Today we use telemetry to reterive all data from your
device, you propose now to read the state data from the device directly?

Alex: Indepent of the network telemetry. This is an operational
specification.

9. Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives (10 mins)

draft:
https://datatracker.ietf.org/doc/html/draft-havel-opsawg-digital-map-01

Presenter: Benoit Claise

Kireti: L2/L3 inventory here, L1/L0 in CCAMP.

Daniele: Agreed with you as CCAMP chair.

Italo: Confused because I have to manage the inventory of a shelf
board, what is the difference between the fact that this board is
playing a L0/L1 functionality and L2/L3 functionality?

Daniele: Whatever is common fits into L2/L3, technology specific
goes to CCAMP.

Rob: (talk about the WG generally) Lots of people and lots of
interests. Let's focus on the charter and get the core model done, then
we can have a discussion about what the charter should expand to.