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
GNPy: Optical Route Planning and DWDM Network Optimization
GNPy is an open-source, community-developed library for building route planning and optimization tools in real-world mesh optical networks. We are a consortium of operators, vendors, and academic researchers sponsored via the Telecom Infra Project's OOPT/PSE working group. Together, we are building this tool for rapid development of production-grade route planning tools which is easily extensible to include custom network elements and performant to the scale of real-world mesh optical networks.
Quick Start
Install either via Docker, or as a Python package. Read our documentation, learn from the demos, and get in touch with us.
This example demonstrates how GNPy can be used to check the expected SNR at the end of the line by varying the channel input power:
GNPy can do much more, including acting as a Path Computation Engine, tracking bandwidth requests, or advising the SDN controller about a best possible path through a large DWDM network. Learn more about this in the documentation.