Expectation/Intention and Actual

[nigel-r-davis]

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]

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):

• a 'missing component' error can be detected when the expected component is defined by there is no actual component installed;
• an 'unexpected component' error/warning can be detected when there is an actual component is installed but no expected component is defined;
• a 'component mismatch' error can be detected when the actual component does not match the expected component

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]

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]

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

[QiufangMa]

Hi, my comments as a contributor is that, support of pre-provisioning is not that complex. This is something that could be leveraged by NMDA. What is configured which represents the clients' intention is present in intended ds, and if the server cannot apply the configuration successfully (e.g., because it doesn't match the real hardware), the intention won't be present in operational ds, i.e., only what is actual in use is present in operational ds. A couple of IETF-published YANG has followed this way, e.g.,

• RFC 8348, regarding how the server supports pre-provisioning of hardware: `When the server detects a new hardware component, it initializes a list entry in the operational state.

     If the server does not support configuration of hardware
     components, list entries in the operational state are
     initialized with values for all nodes as detected by the
     implementation.
  
     Otherwise, this procedure is followed:
  
       1. If there is an entry in the '/hardware/component' list
          in the intended configuration with values for the nodes
          'class', 'parent', and 'parent-rel-pos' that are equal
          to the detected values, then the list entry in the
          operational state is initialized with the configured
          values, including the 'name'.
  
       2. Otherwise (i.e., there is no matching configuration
          entry), the list entry in the operational state is
          initialized with values for all nodes as detected by
          the implementation.`

• RFC 8345, section 4.4.10. Supporting Client-Configured and System-Controlled Network Topologies

• RFC 8343, pre-provisioning of interface configuration When a system-controlled interface is created in the operational state by the system, the system tries to apply the interface configuration in the intended configuration with the same name as the new interface. If no such interface configuration is found, or if the configured type does not match the real interface type, the system creates the interface without applying explicit configuration.

• and also refer to the 8342 itself for the examples of pre-provisioning of interfaces: https://datatracker.ietf.org/doc/html/rfc8342#appendix-C.3.1

[italobusi]

I like the proposal to rely on NMDA but I think there are some detailed issues that require further investigation and discussion to make sure that the model fulfil the requirements for expected/intended inventory management

See: https://mailarchive.ietf.org/arch/msg/inventory-yang/XruJJPI5QlMmx1lkM6H9xTkwapY/