italobusi
commented
2 years ago These are the slides presented by Chaode today:
Closed YuChaode closed 2 years ago
italobusi
commented
2 years ago These are the slides presented by Chaode today:
italobusi
commented
2 years ago 2022-01-26 Network Inventory weekly call
Reviewed slides: https://github.com/italobusi/ietf-network-inventory/files/7897916/Inventory.Model.Design_0119.pptx
The proposed model is applicable also to IP
Aihua: When the system is getting big, there would be scalability problems. Most of the YANG data models are currently running on a single NE or on a small network environment with not so much data as in big networks
Jeff: I am not sure we need the equipment room information in the MDSC
Chaode: all the racks are in the equipment room so we can have some default values for the equipment rooms. Dr Zheng from CU has a special use for the equipment room
Italo: with the CU proposal we can keep the equipment-room optional: if not implemented, the racks will not be pointed by any equipment room. So we can still keep the equipment-room as an optional and use the YANG feature to indicate whether this option is supported or not by the server
Chaode: the fiber does not belong to any NE so it should be at the same level as NE
Italo: if we follow the same logic as per equipment-room, also the fiber object can be kept as optional
Jeff: when you retrieve a board in a NE, is there a way to know in which slot this boards is located?
Chaode: we have a location attribute in the board which reports in which equipment-room, rack, shelf, slot/sub-slot the board is located
Chaode: I have investigated within Huawei and this model is applicable to IP, optical and also MW equipment
Jeff: we have investigated about the stack of two chassis and it is no more quite common in IP
Chaode: what about not differentiating between shelf and sub-shelf and just provide an attribute indicating whether it is a sub-shelf
Aihua: not sure if IP and DCI worlds would use the term shelf
Jeff: shelf is only for optical, IP usually uses the terms chassis
Agreement: rename the shelf as chassis which is a more generic term and explain that in optical networks it is also called shelf
Italo: what about the relationship between a shelf and its contained sub-shelves?
We need to identify also the list of sub-shelves contained by a shelf
Chaode: in TMF there a figure showing the appearance for each objects and we can reference this figure to avoid any ambiguity
jbouqui153
commented
2 years ago As agreed here are the slides presented yesterday. First part is on clarifications on China Unicom scalability issues and on the need also to align on definitions between all of us and second part is presenting some examples of NE configurations to be taken into account. VF questions & inputs on NE configurations v1.pptx
zhchenfang
commented
2 years ago Here are the the slides for questions on China Unicom proposal and definition alignment of port and transceiver. RE：VF.questions.inputs.on.NE.configurations.v1.pptx
italobusi
commented
2 years ago 2022-02-09 Network Inventory weekly call
Review slides from Jeff:
Chengfang: the port and the transceiver are not the same
Jeff: they have a transceiver plugged into a daughter board or in a board and the port is where the fiber is plugged-in
Need to clarify the definition of port: hardware inventory is concern only with the physical ports (entities where the fibers are plugged-in) and not with logical ports (e.g., VLANs, LAGs)
Need to clarify the relationship between logical port and physical port: new open issue #33
In inventory model you have physical port (entities where the fibers are plugged-in), but in the topology you can also have physical ports (for example low level of LTP in RFC8795) and logical ports. The former can be associated with the physical ports in the network inventory bridging between the two models
Need more details on the MPO ports (also considering different possible configurations) and evaluate how to model them within the hardware network inventory: new open issue #34
Need to better understand the problem of scalability that is the base of the proposed model by China Unicom.
italobusi
commented
2 years ago 2022-02-16 Network Inventory weekly call
[ ] @italobusi send a mail to the co-authors soliciting investigation and feedbacks before next week call
[ ] @jbouqui153 / @anton1688 check internally about scalability and report to all the feedback
Anton: The scalability issue of inventory can be existing in other data model, should be deal with some other protocols or technology.
Aihua: The scalability issue maybe solved by streaming like grpc or other protocols. And some of the data can be saved in memory like Redis, but some of them need to be saved in database.
Chaode: The scalability issue is also existing in other YANG data models' integration. And right now the filtering mechanism of restconf protocol is not quite mature. There is only one individual draft of filtering and pagination in IETF under discussion. The scalability issue for our current generic model is not caused by longer time of retrieval in a single node, but the accumulated time in each node of large network. The generic model provided by RFC8348 is used in a single node level, while our inventory model is used in network level, the integration issue is different.
italobusi
commented
2 years ago 2022-03-30 Network Inventory weekly call
- [ ] Jeff/Anton will check internally about scalability and report to all the feedback.
Aihua: it could be interesting to make a test, in case we decide to go for a flat model, trying to get a list of single object (e.g., transceivers) check if Restconf has still problem of scalability.
Chaode: with flat model it is easy for client and server to align with the content of the model.
Changing the model to a flat approach may not be sufficient to resolve the scalability issue; for example some export mechanism is required which is a protocol issue.
T-API streaming improves the resynchronization when the client and server are initially connected or when they lose temporarily communication.
Split the discussion into two issues:
The flat model can still be considered as an option e.g., for readability and for alignment between client and server (to get better understanding of what are the real objects).
The solution for the model should be selected considering pros&cons from a modelling perspective.
The solution for the protocol scalability can be generalized and submitted as a separated draft (e.g., to Netconf).
[ ] Everybody: prepare a list of pros&cons of the different modelling approaches for review during next week
[ ] Jeff: to check with Anton whether the flat modelling can simplify the mapping to the internal database structure
italobusi
commented
2 years ago 2022-04-06 Network Inventory weekly call
- [x] Aihua: check if there are some export mechanisms in OpenConfig
There is no definition for official export mechanisms but in the fields there are RPCs implemented to export e.g., the fault log
Question: should we define an export mechanisms within the Inventory draft or define a more generic mechanism applicable to the Inventory or other models in a separated draft?
Chaode has suggested to collect as many requirements as possible, especially from operators' perspective, to know what kind of functions operator want to use from inventory. So that we can try to provide these functions by these two modules. It will help to judge which model is easier for integration.
Reviewed slides from Chaode on requirements: Requirements of Inventory.pptx
Pending actions:
[ ] Everybody: prepare a list of pros&cons of the different modelling approaches for review during next week
[ ] Jeff/Anton will check internally about scalability and report to all the feedback.
[ ] Jeff: to check with Anton whether the flat modelling can simplify the mapping to the internal database structure
italobusi
commented
2 years ago 2022-04-20 Network Inventory weekly call
Question: should we define an export mechanisms within the Inventory draft or define a more generic mechanism applicable to the Inventory or other models in a separated draft?
Jeff: our draft should focus only on the YANG model. The other issue is much bigger problem to tackle which requires discussion with other WGs (e.g., Netmod, Netconf)
Aihua: the scalability issue seems quite generic to justify a generic solution. The question is whether we need a network inventory specific RPC or do we leave it to the implementor to implement
Italo: I think the answer depends on the generic solution: if it can be used as it is to retrieve the inventory, there is no need for inventory specific RPC
Jeff: it is not fully clear what is the limit between the data model and the RESTCONF interface for the scalability issue
The focus is to decide the modelling approach and identify which elements are generic and which are technology-specific
[ ] Everybody: prepare a list of pros&cons of the different modelling approaches for review during next week
[x] Jeff/Anton will check internally about scalability and report to all the feedback.
[x] Jeff: to check with Anton whether the flat modelling can simplify the mapping to the internal database structure
italobusi
commented
2 years ago 2022-04-27 Network Inventory weekly call
- [x] Anton: check internally about scalability and report to all the feedback
It seems that the flat model is more suitable for bigger scale and it assumes that the client will do the resolution of the references
However, there is no quantitative information about the network size that would cause an issue with the generic model
The flat model is also easier to map with the internal structure for most implementations since it maps with the internal tables
The client need to resolve the references and the complexity would depend on the client implementation
Flat model is like a puzzle: you have all the pieces but you need to re-create reference among them . From this point hierarchical model is by default structured.
Chenfang: in CU there are at least tens of thousand NEs within one domain. The super-controller should manage more than 30 provinces
Continued to review the slides from Chaode on requirements: Requirements of Inventory.pptx
Some specific RPCs may need to be defined in the YANG model to support some of the required queries. However, it is better to identify the most common requirements not to define RPCs for any possible requirement.
italobusi
commented
2 years ago 2022-05-11 Network Inventory weekly call
- [ ] Everybody: prepare a list of pros&cons of the different modelling approaches for review during next week
Chaode has presented a comparison between the generic model and the CU proposal considering the requirements described in Requirements of Inventory: Model Comparison
italobusi
commented
2 years ago 2022-05-18 Network Inventory weekly call
[x] Everybody: prepare a list of pros&cons of the different modelling approaches for review during next week
[x] Everybody: review the comparison table in Model Comparison. The goal is to take a decision on how to proceed next week
There are some scalability issues with large networks and some of them depends on RESTCONF, so changing the model would not solve all the scalability issues. Even with a flat model there could be scalability issues in the large network that could be solved using different methods than RESTCONF operations
Depending on the queries, there are benefits using the CU model but when quering the NE details, the complexity of the two models are very similar. If the most common requirements are the latter one, then there is no big difference between the two models
Agreement: keep working to enhance the current hierarchical model and park this issue for the time being. We can re-structure the model in future if needed
In large network scenarios, the scalability issues of the current hierarchical model could be addressed at the protocol level.
italobusi
commented
2 years ago 2022-05-25 Network Inventory weekly call
Jeff: confirmation from the operations that most of the queries are on NE-based components where the CU model and the hierarchical models have no big difference in performances
Agreement confirmed to keep working to enhance the current hierarchical model and park this issue for the time being. We can re-structure the model in future if needed
italobusi
commented
2 years ago It has been agreed this is a protocol issue rather than a data model issue
We found a possible integration issue if we use our current generic model. Domain controller and orchestrator or OSS will waste time on component translation and classification. This issue will be aggravated in large scale of network. The hardware model in RFC8348 is adapted on the single site level, but the inventory model we are discussing is a network level. There could be some differences between these two levels. More information can refer to the slide attached. PS: China Unicom also has an update model, it seems to be able to alleviate this issue.