mirror of
https://github.com/Telecominfraproject/oopt-gnpy.git
synced 2025-10-30 17:47:50 +00:00
936b17c151
The topology model (`tip-photonic-topology`) uses `leafref`s for "instantiating" actual nodes from models defined in the equipment library. The topology is unidirectional. At first, I used an ad-hoc, custom topology for simplicity. This was changed in response to Jonas' comment; there's clearly no need to reinvent this particular wheel. Now the model builds on top of RFC8345. Both [`ietf-network-topology`](https://tools.ietf.org/html/rfc8345#section-4.2) and the associated `ietf-network` are needed. The augmentations make it a bit harder to see the YANG rendering of the resulting modules, but that's just how the IETF model was designed. There's nothing to fix on our side. The `must` statements which ensure that a topology is well-connected leaves much to be desired. I guess I just don't buy the reasoning about `require-instance: false` given in the RFC. If you need to break topology, use a datastore which is defined to have broken referential integrity, e.g., `operational`. Oh well. Unlike the previous JSON files, this puts the fiber data into `nt:link`. This occurred to me when in Angers at the face-to-face meeting. I talked with Esther about the way the draft-ietf-ccamp-optical-impairment-topology-yang is structured. Basically, they decided to stick the whole Optical Multiplex Section (OMS) into a `te:link` instead of using topologies and layer adaptations -- something which felt strange to me, given my software engineering background and (especially) my lack of hands-on experience with building and running of optical networks (it looks like CESNET's focus is quite unusual after all). One of the reasons for not using a `nw:node` and using an `nt:link` instead is that "there's no NETCONF end point to use to talk to a fiber". The situation is similar here; there's little point in using a full-blown node when modeling something which just boils down to a link. This doesn't mean that the GNPy code shall change -- it's just about changing the representation in user-facing data, such as network topologies. This cuts quite a lot of boilerplate, so it's a good change, IMHO. On the other hand, I wasn't really able to "optimize out" the extra `Fused` nodes just yet. Change-Id: I2208fa81e63df6e13cb502bd2c4b0cfbfdb0ed3b