Hi Dojo, when working with Skyline protocols, I've often found DVE support already included in protocols where different cards are hosted behind the same polling IP.
What are the key things to look for in an API (or on a device) to undertsand if the DVE approach can be suitable also where it has not been implemented yet? What's the best way to asses the load coming from the related QActions?
Asking as I've been working with a few SDN components and I can have different software switches all belonging to the same piece of hardware, yet it proved difficult to get the DVE feature extended for SDN components running behind the same polling IP.
Any hints from the community?
Is the Dynamic Virtual Element (DVE) something that can be used for SDN components too or is it by definition just tied with the concept of a piece of hardware that can be inserted in a chassis?
Keen to get an insight from the community to understand a viable strategy around the integration for a few multipurpose devices where DVEs are not fully supported yet.
In my use case, these are all Fixed Services, so I don't see much room yet for virtual functions and SRM, as the set-up is permanent and it has no need to be booked.
Hi Alberto,
DVEs are often implemented when interfacing with a chassis that has multiple physical cards. In that case, a DVE per card is created to have a dedicated element for each card with only the information from that card. This same concept can also be applied for products that don't have "physical cards", but for example run different "virtual" components (software, VMs,...).
Note that instead of "DVEs", it's also possible to use a "Manager/Standalone" implementation. In that case, a protocol is created for the "main" product being integrated, and separate protocols for each "type" of component the main product exposes. The element for the "main" product would then be manually created, and would automatically created additional elements for each detected component.
Choosing between a "DVE" vs "Manager/Standalone" implementation is not that straight forward. We are working on an article that should highlight all the pros and cons of both implementations to make it as clear as possible which one would make most sense in a specific situation. Note however that in both cases, you would end up with the same end result which is 1 element for the "main" product and separate elements for each "component".
In that case, I don’t really see any constraints to also extending the DVE functionality to also export the SDN components.
Using a combination of DVE and manager/standalone is not something I would use as you will increase complexity quite a bit and you will also combine the cons of both implementations.
If it would make sense to use a manager/standalone approach in the long run, then it could be an option to change the DVE implementation into manager/standalone as well in a separate branch. This would have to be checked case by case as it off course will imply more of an effort and it will not be fully backwards compatible.
Thanks for the prompt feedback, Joey – much appreciated
What about a device protocol that is already supporting DVEs for cards but has not yet a scope for the software defined components?
Are there any constraints to get the DVE support extended to the SDN components? Or would it be a straight-forward feature request?
When going for a manager/standalone approach, can this coexist with DVEs or is it a protocol development fork (either DVEs or manager/standalone)?