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
The NF calculated by the preamp model is compliant with the MW-MW noise
mask in the OpenROADM MSA spec. The booster is noise-free, which is
modeled by setting the NF to zero (-inf in dB units). This is obviously
unphysical but it is the simplest way to model the total noise
contribution from a ROADM, including preamp and booster, that is
compliant with the the OpenROADM MSA.
This also introduces two new EDFA type varieties,
"openroadm_mw_mw_preamp" and "openroadm_mw_mw_booster" in the equipment
library. I would prefer to also change the names of the existing
"openroadm" type_def and "standard"/"low_noise" type_variety,
representing an OpenROADM inline-amplifier, for better consistency but
this probably needs to be discussed first.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I7344ff53623f166649efb389c95c04ff92718e35
Signed-off-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
Co-authored-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
As Jonas pointed out in Ia2ee3fdde1c4eed0b7ef1de77153959230ba1c01, the
documentation was wrong and the default NF implementation was not the
advanced_model. Let's not describe what the backwards-compatible
behavior is (we do not want our users to rely on that), and instead just
say that "adavnced_model" activates, well, the advanced model.
Change-Id: Ie57340d491a6f73d696d77c07091f85952cb4a08
The numbered list was very hard to read; split that into one sentence
per line. Also do that everywhere else but in the tables (in RST I'm
afraid this would be super-painful).
Change-Id: Ib80c05b66cbc98af2d0dda612943f91d923425b0
Relative links within the source tree work, but they were not being
turned into nice usable hyperlink that go back to GitHub under the
generated documentation.
Reported-by: Melin, Stefan M. <Stefan.Melin@teliacompany.com>
Change-Id: I137ad95fa75a6ee5e1b03a252782e6357d36a3af
This was identified during today's coders call where Andrea asked what
the best place for documentation of `sim_params.json` is. Let's split
docs about tangible equipment from those of global "simulation options".
Of course these options are still done in `eqpt_config.json`, which
might get super-confusing to the user -- so please make sure that this
is correctly explained when adding docs for `sim_params.json` in future.
Change-Id: If43894e8f562ca8a768b0efb6cc6c1afeb4aa514
Thanks to Stefan for reporting this.
Reported-by: Melin, Stefan M. <Stefan.Melin@teliacompany.com>
Change-Id: I9ab3aa5f829ffe3ef722df2d46f1393f748a52dc
