You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I look at those YANG objects, as an example:
+--rw lsp-lifetime? uint16
+--rw lsp-refresh-interval? uint16
Do we need those properties for our Digital Map use cases?
If I look at the use cases described in the draft (design, capacity planning planning, what-if), I am not sure.
There is anyway a different way to get the information. From the core model, we have the nodeId instance. This nodeId can point the NE element ISIS YANG module where we could be retrieving/checking any properties.
So the questions is: how many properties do we need in this IS-IS model?
We will have more use cases in the future (ex: config mismatch, such as a hello timer). So, some of those use case-specific augmentation/properties might be required. The question is: where do we stop with this core IS-IS topology YANG model.
The text was updated successfully, but these errors were encountered:
If I look at those YANG objects, as an example:
+--rw lsp-lifetime? uint16
+--rw lsp-refresh-interval? uint16
Do we need those properties for our Digital Map use cases?
If I look at the use cases described in the draft (design, capacity planning planning, what-if), I am not sure.
There is anyway a different way to get the information. From the core model, we have the nodeId instance. This nodeId can point the NE element ISIS YANG module where we could be retrieving/checking any properties.
So the questions is: how many properties do we need in this IS-IS model?
We will have more use cases in the future (ex: config mismatch, such as a hello timer). So, some of those use case-specific augmentation/properties might be required. The question is: where do we stop with this core IS-IS topology YANG model.
The text was updated successfully, but these errors were encountered: