search

ietf-ivy-wg / network-inventory-yang

Other
0 stars 3 forks source link

Expectation/Intention and Actual #28

Open nigel-r-davis opened 1 year ago

nigel-r-davis commented 1 year ago

https://github.com/ietf-ccamp-wg/ietf-network-inventory/blob/e633109c5dff36ea26e1844c6abd32e664eb9f0a/draft-ietf-ccamp-network-inventory-yang.txt#L629

It TAPI we support the preprovisioning of slots. The NE essentially expects an equipment to be inserted. This is a traditional capability and is a rudimentary planning/intent model. Many devices support this capability. It is important to represent this. In TAPI we use the equipment (component) to represent both the expectation and actual. If we were to do that here, the component would have a structure for expectation and a structure for actual along with a mismatch representation capability. We should discuss this in more detail.

italobusi commented 1 year ago

I would like to get confirmation about the need to support this requirement since I am not sure addressing this requirement is as easy as it appears at the first glance ...

For a given holder we can define two attributes, one reported the expected component (e.g., component X) and the actual component (e.g., component Y):

However, the mismatch may happen anywhere in the hierarchy of components/holders: the holders and sub-components for expected component X can be completely different than the holders and sub-components for the actual component Y

How this case can be managed?

Maybe, a more flexible/complete solution could be to define two hierarchies of components: one for the expected components and one for the actual components which may match/mismatch at any level

Another doubt: is the expected component only reported (read-only) in the network-inventory or would it be also possible to configure the expected component?

If we allow the configuration of the expected components, how to deal with the cases where there are different expected components at the controller's NBI and on the device?

NMDA could help but the behavior needs to be clarified especially in case of a hierarchy of controllers

nigel-r-davis commented 12 months ago

In the ONF core we explored the use of two hierarchies and realized that we could have a flexible split. If the actual and expected match suitably, a single hierarchy can be used to deal with both aspects. Once there is a discrepancy the model can split into two hierarchies from that point on. Worth a discussion.

If the equipment supports expectation, then it should be configurable. Expectation may need to deal with constraints like intent. This aspect needs a further discussion.

italobusi commented 7 months ago

A slot can have the following states:

  • Empty: no component is installed and no expected component has been provisioned;
  • Installed & not expected: a component is inserted but no expected component has been provisioned;
  • Expected & not Installed: an expected component has been provisioned but no component is currently installed;
  • Installed & Expected: an expected component has been provisioned and it is currently installed;
  • Mismatch of Installed & Expected: there is an inconsistency between the expected component and the installed component;
  • Unavailable: this holder cannot accept the installation or provisioning of components (this is typically caused by a double width card installed next to this slot);
  • Unknown: the state of the slot is not known;

Is there a need to manage/report these states within the network inventory?

See also: https://github.com/ietf-ccamp-wg/ietf-network-inventory/issues/15#issue-1023941241