RFC: YANG: taming the autodesign

[jktjkt]

Today, it might be difficult to represent a network as-is in GNPy, that is, to completely switch off any autodesign-driven transformations. Here's a YANG proposal which (I hope) will make this easier:

module: ietf-network
  +--rw networks
     +--rw network* [network-id]
        + ...
        +--rw node* [node-id]
        |  + ...
        |  +--rw (tip-topo:element)
        |     +--:(tip-topo:amplifier-placeholder)
        |     |  +--rw tip-topo:amplifier-placeholder    empty
        |     +--:(tip-topo:amplifier)
        |     |  +--rw tip-topo:amplifier
        |     |     +--rw tip-topo:model             -> /tip-pe:amplifier/tip-pe:type
        |     |     +--rw tip-topo:gain-target?      tip-pe:gain
        |     |     +--rw tip-topo:out-voa-target?   tip-pe:db-ratio
        |     |     +--rw tip-topo:tilt-target?      tip-pe:db-ratio
        |     |     +--rw tip-topo:delta-p?          tip-pe:db-ratio
        |     +--:(tip-topo:attenuator)
        |     |  +--rw tip-topo:attenuator
        |     |     +--rw tip-topo:attenuation?   tip-pe:db-ratio
        |     +--:(tip-topo:transceiver)
        |     |  +--rw tip-topo:transceiver
        |     |     +--rw tip-topo:model    -> /tip-pe:transceiver/tip-pe:type
        |     +--:(tip-topo:roadm)
        |        +--rw tip-topo:roadm
        |           +--rw tip-topo:model                              -> /tip-pe:roadm/tip-pe:type
        |           +--rw tip-topo:target-egress-per-channel-power?   tip-pe:power
        +--rw nt:link* [link-id]
           + ...
           +--rw nt:source
           |  +--rw nt:source-node?   -> ../../../nw:node/nw:node-id
           |  + ...
           +--rw nt:destination
           |  +--rw nt:dest-node?   -> ../../../nw:node/nw:node-id
           |  + ...
           +--rw (tip-topo:link-type)?
              +--:(tip-topo:tentative-link)
              |  +--rw tip-topo:tentative-link
              |     +--rw tip-topo:type      -> /tip-pe:fiber/tip-pe:type
              |     +--rw tip-topo:length    decimal64
              +--:(tip-topo:fiber)
              |  +--rw tip-topo:fiber
              |     +--rw tip-topo:type              -> /tip-pe:fiber/tip-pe:type
              |     +--rw tip-topo:length            decimal64
              |     +--rw tip-topo:loss-per-km?      decimal64
              |     +--rw tip-topo:attenuation-in?   tip-pe:db-ratio
              |     +--rw tip-topo:conn-att-in?      tip-pe:db-ratio
              |     +--rw tip-topo:conn-att-out?     tip-pe:db-ratio
              |     +--rw tip-topo:raman!
              |        +--rw tip-topo:temperature    uint16
              |        +--rw tip-topo:pump* [frequency]
              |           +--rw tip-topo:frequency    tip-pe:frequency-raman-pump
              |           +--rw tip-topo:power        tip-pe:power
              |           +--rw tip-topo:direction    enumeration
              +--:(tip-topo:patch)
                 +--rw tip-topo:patch
                    +--rw tip-topo:roadm-target-egress-per-channel-power?   tip-pe:power

As usual, the network consists of nodes and links. Unlike today's GNPy, though, some interesting "GNPy elements" are no longer represented as nodes, but they become links. A prime example is the Fiber element.

Some constructs are wroth a special attention. The fiber element now corresponds to a real-world fiber, i.e., something which is already known to exist. Its length and attenuation is already known, and GNPy won't be allowed to split this fiber into smaller chunks. If the automatic splitting is desirable, then there are two options:

• The tentative-link, where only the length is known, and amplifiers can be auto-inserted at will. Think of this as a "link intention": I know I want to connect these cities which are 5000km apart, but I have no clue how many amps I need for that. GNPy, please help me design my network.
• The amplifier-placeholder, on the other hand, connects two physical fiber instances together (or a fiber and tentative-link, or even two tentative-links; there's probably no need for an artificial limitation). Think of it as a hut along the fiber path; GNPy can either replace that by a specific amplifier, or it can use this location to splice the two fibers. That's done via the attenuator node.

Another difference compared to today's GNPy-JSON is fiber vs. patch. The features currently supported by the Fused GNPy element (which is a node in GNPy's internal network representation) will be handled either by the patch (as a graph edge, for joining, e.g., two ROADMs together), or by the the attenuator node.

This proposal does not require ports, but there are some hacks (such as the ROADM's per-degree options which are presently implemented inside a patch, which looks a bit ugly) which might warrant using ports. If we do that, though, we might as well introduce "bidirecitonal nodes" (i.e., a node which has both east-to-west and west-to-east EDFA).

Also, this will need a set of heuristics when opening a legacy-style JSON file. I'm trying to solve some ambiguities in the existing format, and that might make it rather hard to support a full legacy-JSON → YANG-JSON → legacy-JSON round trip.

Thoughts, opinions?

Cc: @Sme791, @AndreaDAmico