https://datatracker.ietf.org/meeting/122/materials/agenda-122-ivy
Wednesday, March 19, 2025
Session I: 09:30 - 11:30 (Asia - Bangkok)
Room: Boromphimarn 3
(https://datatracker.ietf.org/meeting/122/floor-plan?room=boromphimarn-3)
Meetecho: https://meetings.conf.meetecho.com/ietf122/?session=33821
Onsite tool:
https://meetings.conf.meetecho.com/onsite122/?session=33821
Audio Only: https://mp3.conf.meetecho.com/ietf122/33821.m3u
Chat Only: https://zulip.ietf.org/#narrow/stream/ivy
slides: https://datatracker.ietf.org/meeting/122/session/ivy
Notes: https://notes.ietf.org/notes-ietf-122-ivy
Daniele Ceccarelli (daniele.ietf@gmail.com)
Qiufang Ma (maqiufang1@huawei.com)
Slide #12
Mahesh Jethanandani: If you are looking for examples on how an
augmentation can be made, maybe look at the BGP YANG model which shows
an example on how the BGP model can be augmented. The inventory base
model should be as simple as possible, guidelines are good but let's
keep it to an example of how that augmentation should be made.
Mohamed Boucadair (from chat): It seems this slide 12 is stale as it
does not reflect the discussion on the mailing list (with Mahesh in
particular) with examples of items to cover in these guidance.
Bo Wu: Following Mahesh's suggestion, software component extension
already provides some examples as well as inventory topology draft, both
documents do the augmentation. Maybe refer to them as some examples.
Mahesh Jethanandani (from chat): I would agree with Bo that the software
inventory model might be an example that might be closer to what people
might want to look for.
Slide #3
Joe Clarke:
Slide #4
Swamynathan Balasundaram: Why the non-pluggable case is an open issue to
be further analyzed? When you are able to differentiate a transceiver
vs. a non-transceiver, and you already have parent-child relationship, I
think that's already covered.
Aihua Guo: The issue is that you cannot distinguish whether it's an
empty hole or it's a non-pluggable port.
Swamynathan Balasundaram: Wouldn't that already be determined by whether
you have a termination point or not?
Aihua Guo: Yes, termination point exists but is not part of inventory,
so probably more discussion is needed.
Slide #13 and #14
Aihua Guo: More discussion is needed whether we should cover both
options or if there is any common definition for both.
Nigel Davis: The distinction is that, in option #1, clearly there is two
slot elements which are physically attached to the same inventory item
in the inventory list; in option #2, the sub-shelf definition is more
related to "physical topology" than inventory, it's debatable whether
that should be distinct in modeling from a normal set of interconnected
shells with physical topology. But probably we need to represent both
with different modeling strategy.
Aihua Guo: Need further discussion for the modeling of two options.
Bo Wu: Is the intra-NE cable also in the option of modeling?
Aihua Guo: Yes in case the main shelf and sub-shelf are represented as
different NEs, and intra-NE cable becomes a "link". There is a typical
deployment of multi-shelf configurations, and in a lot of cases there is
just one network element from the management's perspective, it might be
better to just consider this as a single network element.
Bo Wu: I suggest to consider this in the passive inventory work or as an
enhancement on the base inventory work. We want to progress base
inventory work quickly.
Rob Wilton: My instinct here is to model the physical things. In option
2, it's fine if all are integrated into one device and just model those
shelves. I'm not so keen in this case of having the complexity for the
sub-shelves I would flatten that and maybe have a leaf-ref or something
to show the relationship between them.
Rob Wilton: Either modeling as a single network element or treat them as
separate network devices and have the relationship to show the
connection relationship. Or if this is getting some complexity, maybe
defer until a future document.
Nigel Davis: My point was aligning with Rob's, just make all the shelves
equal in the network element and then show their topological
relationship.
Mahesh Jethanandani (from chat): To Rob's point, unless we know how deep
the sub-shelfs might go, it would be difficult to model this in a
hierarchical fashion.
Slide #15
Daniele Ceccarelli: is it possible to remind the WG of the meaning of
priority 1 and priority 2 open issues?
Aihua Guo: Priority 1 issues are those must be resolved before WGLC,
priority 2 are important but can be solved in a second time.
Slide #3
Qiufang Ma: Why there are some nodes in the tree that are RO and others
are RW?
Bo Wu: It is probably a mistake.
Slide #4
Aihua Guo: As you said, the underlying physical infrastructure might be
containing a list of cables and there is also passive device in between,
so a direct mapping from a link to a cable probably is not the best way.
There is a End-to-End concept we call physical span, maybe map the link
to the physical span, I would rather leave this to the passive inventory
discussion.
Maybe it is an option to have some augmentation.
Slide #5
Bo Wu: A question to Scott Mansfield who is an author of
I-D.ietf-ccamp-if-ref-topo-yang: do you think it is reasonable we are
doing the physical interface association to termination point which is
not based on TE topology but based network topology in RFC 8345?
Scott Mansfield: TE topology is not just about traffic engineering, I
think it is a little misnamed. I think augmenting TE topology is the
correct thing because you get the most bang for your buck out of doing
that.
Bo Wu: CCAMP TE topology (? maybe Bo was referring to CCAMP interface
reference topology) tries to focus on the traffic engineering cases, but
this model tries to do the inventory mapping.
Scott Mansfield: TE topology isn't just for TE. If you want to do the
one that provides you with the most knobs you can use and that is TE
topology.
Bo Wu: I will send this issue to the mailing list for more discussion.
Daniele Ceccarelli: Just a clarification, TE topology is a TEAS WG
document, rather than a CCAMP one.
Swamynathan Balasundaram: Is the network element a starting point to
describe capabilities? Or are the capabilities at the higher-level
(i.e., network/subnetwork)? When you build the hierarchy, it may be at a
higher level to iteratively drill it down.
Diego Lopez: This is something we would like to hear from the WG.
Swamynathan Balasundaram: A related question is that in terms of the
inventory and asset, do you only look at the network but also include
the controller as well?
Diego Lopez: Controller is part of the network to me, but we can
discuss.
Daniele Ceccarelli: the model for entitlement is all rw, shouldn't it be
ro?
Diego Lopez: The point is whether an inventory management system can
make changes or just exposing entitlements. This is something we will
try to address.
Mahesh Jethanandani:
Diego Lopez: Who is the customer here?
Mahesh Jethanandani: The customer is an operator that is offering
service to their customers. Is the idea that people will be able to
figure out what set of entitlements they need to offer a particular
service?
Diego Lopez: No because that depends on the business model of the
different technology providers. The point is whether you are trying to
activate a capability and whether you have the entitlement and not which
would you need.
Juan Cardona (from chat): This is not a catalogue of entitlements, it is
an inventory.
Mohamed Boucadair (from chat): On the ro/rw, this depends on how the
model is intended to be used. if this can be used to populate them (and
because this can't be automatically discovered, which is likely), the rw
makes sense.
Mahesh Jethanandani (from chat): @Med, it is not clear in the draft
whether it the model is pre-provisioned or that the capabilities are
being discovered. The idea is for the draft to make it clear.
One can sense the confusion based on how many folks have raised similar
questions to Daniele and me.
Mohamed Boucadair (from chat): +1 to Mahesh.
Mahesh Jethanandani: What drives the choice of augmenting network
element and not network inventory model?
Diego Lopez: Because capabilities are associated with the element.
Aihua Guo: Following the discussion of capability level, do you consider
drilling down to individual components for the capabilities?
Diego Lopez: We've discussed this and have preferred not to address it
yet. It is only about identifying which are the components and whether
the capabilities are associated to the components. Frankly I don't see
the need to declare a capability for a hardware component like cable or
rack. But it is a different case when it comes to software.
Qin Wu (from chat): Distinguish automatic discovery from pre-provision
makes sense, if this is something we can agreement, inconsistency is not
a issue?
Bo Wu: Are the entitlement and capability are network model or device
model? I am unsure whether the device can support a specific capability
directly.
Diego Lopez: I think it should be associated with the device model as
well.
Bo Wu: I see some parts of the entitlement model as ro, but others like
holders, are those just for annotation?
Diego Lopez: It is listing who is owning an entitlement that has been
installed in a server. Probably the upper part of the model should be
ro, the lower part should be ro.
Bo Wu: Regarding the attachment on the components, I don't see there is
a reference to the capability but just a reference to the component.
Diego Lopez: We are trying to make it as a reference by name, you're not
pointing to the capability. We can discuss this further. Instead of
doing a model for exchanging information, we try to make a model for
building a database. In a model keeping the consistency of
cross-reference can be a nightmare.
Qiufang Ma (from chat): As a contributor, I agree we should navigate
from entitlement to capability.
Qin Wu (from chat): Is entitlement applied to device, network and
service?
Holger Keller (from chat): @Qin in a Multi-vendor Environment you can’t
apply it on Network or Service, just to the capabilities of a device.
Nigel Davis: I fully agree the point of models for exchanging
information vs. models in databases. I strongly support this work and
would like to participate. I've long worked on similar models, including
those in ONF, now in ITU-T. We considered capabilities of providers,
focusing on specific things. We found modeling capabilities complex due
to their nested and structured nature. We looked at capabilities of
terminations, connections, devices, and equipment compatibility in
slots. Generalizing the capability model to components was tough. We
also considered operating rules, similar to your entitlements. The
challenges led me to introduce a modeling boundaries draft into IETF
three and two and a half years ago. Our work's insights are in ITU-T
G711's appendix and ONF TR512, though ONF is disbanded. I can bring
these insights to our discussion.
Diego Lopez: Instead of creating a comprehensive ontology of
functionalities like what a rotor can do, we should focus on a simpler
model based on inventory and capabilities—what you've paid for. In NMOP,
we've discussed reaching the limits of certain things we want to do. I'm
open to discussing these limits and how to navigate them, and I'd
appreciate your insights and solutions from the ONF context. Let's
proceed with this discussion.
Joe Clarke: I agree we need this, but I am with Mahesh. Maybe that's
what's difficult to be without model but just trees. I would think
capabilities would have the component ID, like I have a capability
that's bound to this software component that requires this entitlement.
Please take some concrete examples here and help us figure out if it's
sufficient.
Mahesh Jethanandani (from chat): +1 to Joe's comment.
Diego Lopez: Camilo was working on some examples. We decide to first
bring the idea to see if there are push-back and next we're going to
continue exploring this and bring some examples.
Nigel Davis: Support Joe's comments on examples. It is absolutely
critical.
Juan Cardona: What we are trying to solve comes from real-world problems
of modeling licenses in Cisco/Nokia/Juniper devices. We do have examples
of them and we can add them but they might look complex, we may decide
whether we want to embrace the complexity.
Mahesh Jethanandani (from chat): We (Arrcus), as an NOS vendor, want to
provide an entitlement capability but have struggled with how to
implement it.
Rob Wilton: I also find it hard to understand exactly what this is. The
openconfig inventory model have a structure that are common and simple
and allows you to model complicated things, but then you have more
complexity in terms of what ends up being built. What you have here is a
more concrete structure with some predefined nodes but it looks more
complicated.
Diego Lopez: A simple approach can handle a large number of cases. You
have a piece of hardware running multiple software elements, each with
its own license. Sometimes, the hardware might need specific enableness
for a particular feature. This is where a "pay as you grow" license
model. This approach could solve most common deployments. We cannot
model everything on the universe.
Rob Wilton: If you can get a simple model that solves 80% that is good
enough without adding the complexity everywhere.
Juan Cardona: Because you don't have Nokia devices in your network in
which you buy licenses to expand the bandwidth. You can cover 80% but it
doesn't mean the other 20% are corner cases. This is happening in my
network. We can offer our experience and please give us ideas how to
model this. You can know this is not going to be simple.
Rob Wilton: Maybe 80% is setting the bar too low, maybe 80% of
deployments. Is that sufficient?
Diego Lopez: It is up to the WG to decide whether it should be there or
it is better that we wait till we make another augmentation in the
future.
Slide #7
Mahesh Jethanandani: I was confused by the distinction between an
optical cable and other passive devices. If you can generalize that to
all passive devices, that would be good.