-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added minutes of the call on June 14, 2023
- Loading branch information
Showing
1 changed file
with
98 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,98 @@ | ||
| # Network Inventory weekly call (June 14, 2023) | ||
|
|
||
| ## Participants | ||
|
|
||
| - Aihua Guo | ||
| - Fabio Peruzzini | ||
| - Italo Busi | ||
| - Jeff Bouquier | ||
| - Nigel Davis | ||
| - Oscar González de Dios | ||
| - Phil Bedard | ||
| - Roberto Manzotti | ||
| - Sergio Belotti | ||
|
|
||
| ## Admin | ||
|
|
||
| ### Closed Issue | ||
|
|
||
| None | ||
|
|
||
| ### Next calls | ||
|
|
||
| - June 21st at 4pm CEST / 10am NA EDT / 10pm CST | ||
| - June 28th at 4pm CEST / 10am NA EDT / 10pm CST | ||
|
|
||
| ## Discussion | ||
|
|
||
| ### Inventory models coordination (issue #26) | ||
|
|
||
| Draft charter updated: | ||
|
|
||
| https://datatracker.ietf.org/doc/charter-ietf-ivy/ | ||
|
|
||
| An e-mail soliciting comments (to be sent to IESG) has been sent to the list (deadline for comments is next monday, June 19) | ||
|
|
||
| https://mailarchive.ietf.org/arch/msg/inventory-yang/SZh3AUYGUr7tiBSyAUFeC6e73uU/ | ||
|
|
||
| Comments should be sent to IESG (iesg@ietf.org) but it is better to keep also the inventory mailing list informed (inventory-yang@ietf.org) | ||
|
|
||
| The comments discussed earlier are still applicable to the latest version of the draft charter: | ||
|
|
||
| > - [ ] **Jeff/Fabio**: send a mail to the inventory mailing list expressing the urgent need from operators perspective | ||
| > | ||
| Oscar thinks that the urgency was quite understood from IETF offline discussions | ||
|
|
||
| Jeff is concerned that covering also enterprise and software inventory would require longer discussion | ||
|
|
||
| A possible approach could be to focus the initial RFC to cover only hardware network inventory in a carrier network, making sure that the model is open to future extensions to support enterprise network and software inventory | ||
|
|
||
| > Comments: | ||
| > | ||
| > D: multi-layer is not a proper name for inventory objects. Better to use the term layer-independent or layer-agnostic for inventory | ||
| > | ||
| > E: correlation might be understood as implying some complex processing, better to use relationship instead | ||
| > | ||
| > - [ ] **Nigel**: raise the comment on the Inventory mailing list | ||
| > | ||
| Discussion about the next steps after the IVY WG is formed | ||
|
|
||
| Our proposal is to propose the IVY WG to use the model in our draft as the base common model for network inventory | ||
|
|
||
| Question about whether to move the optical aspects outside the draft. The current model is not covering the functional aspects (including the optical functional aspects). Functional aspects are usually covered in the interface and topology models | ||
|
|
||
| Aihua reported some discussion in BBF meeting about the possibility to use the model in our draft as a common basis also for the access networks | ||
|
|
||
| It is not clear whether there are gaps in our model to model access NEs: to be checked on a case-by-case basis if the gap is specific to access networks, to be covered by a BBF augmentation, or is generic to be covered by our model | ||
|
|
||
| Having more examples of devices that are modelled using our inventory model is anyway good to check the completeness of the model | ||
|
|
||
| ### Use node-id instead of uuid for indexing elements (issue #74) | ||
|
|
||
| > It was clarified the issue applies to the identification of the network element and not to the identification of the components | ||
| > | ||
| > Using the node-id, which is an URI, allows also using UUID to identifiy NEs but allows other types of identification | ||
| > | ||
| > Chaode has raised concerns with using the node-id to correlate a node in the topology model with a NE in the inventory model in case of multi-layer NE | ||
| > | ||
| > Need to continue the discussiong it | ||
| > | ||
| It has been clarified that the URI used for xxx is not correlated with the node-id in the topology model: the navigation between the inventory and the topology view can be done using the ietf-hw-inventory-ref-topo model | ||
|
|
||
| Agreement to change the key for the network-element list to be an URI rather than a UUID | ||
|
|
||
| ### Add timestamp to know when a component information was retrived (issue #73) | ||
|
|
||
| > - [ ] **Oscar/Fabio/Jeff**: Provide more information about the use cases | ||
| > | ||
| Oscar:In general what I've got from operation department is to have the possibility to understand how old are the inventory information.Would be a timestamp indicating when the component was inserted and another one for the last time it was reported. | ||
|
|
||
| Nigel:In T-API notification/streaming there is fine grained timestamps but not on traditional T-API GET inventory. | ||
|
|
||
| Jeff: will ask in next TIP MUST optical weekly call the other operators but seems more reasonable not to modify our YANG model to consider these timestamps. probably these timestamps can be managed through notifications mechanism at a protocol level. | ||
|
|
||
| Discussions about flexibility to have these timestamps vs increased complexity for implementing it. |