CCAMP Working Group                                              Y. Lee
Internet Draft                                                 H. Zheng                                                Futurewei
Intended Status: Standard Track                                 I. Busi
                                                                 Huawei
Expires: October 9, November 27, 2019
                                                               N. Sambo
                                             Scuola Superiore Sant'Anna                                     V. Lopez
                                                             Telefonica

                                                          G. Galimberti
                                                          G. Martinelli
                                                                  Cisco

                                                          Jean Luc Auge
                                                        Ester LE Rouzic
                                                          Julien Meuric
                                                                 Orange

                                                              D. Beller
                                                             S. Belotti
                                                             E. Griseri
                                                                  Nokia

                                                           Gert Grammel
                                                                Juniper

                                                          April 9,

                                                           May 27, 2019

          A Yang Data Model for Optical Impairment-aware Topology

           draft-ietf-ccamp-optical-impairment-topology-yang-00

           draft-ietf-ccamp-optical-impairment-topology-yang-01

Abstract

   In order to provision an optical connection through optical
   networks, a combination of path continuity, resource availability,
   and impairment constraints must be met to determine viable and
   optimal paths through the network. The determination of appropriate
   paths is known as Impairment-Aware Routing and Wavelength Assignment
   (IA-RWA) for WSON, while it is known as Impairment-Aware Routing and
   Spectrum Assigment (IA-RSA) for SSON.

   This document provides a YANG data model for the impairment-aware TE
   topology in optical networks.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 9, November 27, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................3
      1.1. Terminology...............................................4
      1.2. Tree diagram..............................................4
      1.3. Prefixes in Data Node Names...............................5 Names...............................4
   2. Reference Architecture.........................................6 Architecture.........................................5
      2.1. Control Plane Architecture................................6 Architecture................................5
      2.2. Transport Data Plane......................................7 Plane......................................6
      2.3. OMS Media Links...........................................7
         2.3.1. Optical Tributary Signal (OTSi)......................7
         2.3.2. Optical Tributary Signal Group (OTSiG)...............8 (OTSiG)...............7
         2.3.3. Media Channel Group (MCG)............................9
      2.4. Amplifiers................................................9
         2.4.1. In-Line Amplifier...................................10 Amplifiers...............................................11
      2.5. Transponders.............................................10 Transponders.............................................11
      2.6. WSS/Filter...............................................10 WSS/Filter...............................................12
      2.7. Optical Fiber............................................10 Fiber............................................12
   3. YANG Model (Tree Structure)...................................11 Structure)...................................12
   4. Optical Impairment Topology YANG Model........................12 Model........................14
   5. Security Considerations.......................................31 Considerations.......................................34
   6. IANA Considerations...........................................31 Considerations...........................................34
   7. Acknowledgments...............................................32 Acknowledgments...............................................35
   8. References....................................................33 References....................................................36
      8.1. Normative References.....................................33 References.....................................36
      8.2. Informative References...................................33 References...................................36
   9. Contributors..................................................34 Contributors..................................................38
   Authors' Addresses...............................................34 Addresses...............................................38

1. Introduction

   In order to provision an optical connection (an optical path)
   through a wavelength switched optical networks (WSONs) or spectrum
   switched optical networks (SSONs), a combination of path continuity,
   resource availability, and impairment constraints must be met to
   determine viable and optimal paths through the network. The
   determination of appropriate paths is known as Impairment-Aware
   Routing and Wavelength Assignment (IA-RWA) [RFC6566] for WSON, while
   it is known as IA-Routing and Spectrum Assigment (IA-RSA) for SSON.

   This document provides a YANG data model for the impairment-aware
   Traffic Engineering (TE) topology in WSONs and SSONs. The YANG model
   described in this document is a WSON/SSON technology-specific Yang
   model based on the information model developed in [RFC7446] and the
   two encoding documents [RFC7581] and [RFC7579] that developed
   protocol independent encodings based on [RFC7446].

   The intent of this document is to provide a Yang data model, which
   can be utilized by a Multi-Domain Service Coordinator (MDSC) to
   collect states of WSON impairment data from the Transport PNCs to
   enable impairment-aware optical path computation according to the
   ACTN Architecture [RFC8453]. The communication between controllers
   is done via a NETCONF [RFC8341]. [RFC8341] or a RESTCONF [RFC8040]. Similarly,
   this model can also be exported by the MDSC to a Customer Network
   Controller (CNC), which can run an offline planning process to map
   latter the services in the network.

   This document augments the generic TE topology draft [TE-TOPO] where
   possible.

   This document defines one YANG module: ietf-optical-impairment-
   topology (Section 3) according to the new Network Management
   Datastore Architecture [RFC8342].

1.1. Terminology

   Refer to [RFC4847] [RFC6566], [RFC7698], and [RFC5253] [G.807] for the key terms used in
   this document.

   The following terms are defined in [RFC7950] and are not redefined
   here:

   o client

   o server

   o augment

   o data model

   o data node

   The following terms are defined in [RFC6241] and are not redefined
   here:

   o  configuration data

   o  state data

   The terminology for describing YANG data models is found in
   [RFC7950].

1.2. Tree diagram

   A simplified graphical representation of the data model is used in
   Section 2 of this this document.  The meaning of the symbols in
   these diagrams is defined in [RFC8340].

1.3. Prefixes in Data Node Names

   In this document, names of data nodes and other data model objects
   are prefixed using the standard prefix associated with the
   corresponding YANG imported modules, as shown in Table 1.

   +------------------+----------------------------------+------------+
   | Prefix           | YANG module                      | Reference  |
   +------------------+----------------------------------+------------+
   | optical-imp-topo | ietf-optical-impairment-topology | [RFC XXXX] [RFCXXXX]  |
   | layer0-types     | ietf-layer0-types                | [WSON-topo]| [L0-Types] |
   | nw               | ietf-network                     | [RFC8345]  |
   | nt               | ietf-network-topology            | [RFC8345]  |
   | tet              | ietf-te-topology                 | [TE-TOPO]  |
   +------------------+----------------------------------+------------+

             Table 1: Prefixes and corresponding YANG modules

   Note: The RFC Editor will replace XXXX with the number assigned to
   the RFC once this draft becomes an RFC.

2. Reference Architecture

2.1. Control Plane Architecture

   Figure 1 shows the control plane architecture.

                                   +--------+
                                   |  MDSC  |
                                   +--------+
          Scope of this ID  ------->   ||
                        |              ||
                        |  +------------------------+
                        |  |        OPTICAL         |
           +---------+  |  |         DOMAIN         |     +---------+
           | Device  |  |  |       CONTROLLER       |     | Device  |
           | config. |  |  +------------------------+     | config. |
           +---------+  v  //          ||          \\     +---------+
          ______|______   //           ||           \\   ______|______
         /      OT     \ //            ||            \\ /      OT     \
         | +--------+  |//           __--__           \\|  +--------+ |
         | |Vend. A |--|----+       (      )       +----|--| Vend. A| |
         | +--------+  |    |    ~-(        )-~    |    |  +--------+ |
         | +--------+  |    +---/              \---+    |  +--------+ |
         | |Vend. B |--|--+    /                \    +--|--| Vend. B| |
         | +--------+  |  +---(   OLS Segment    )---+  |  +--------+ |
         | +--------+  |  +---(                  )---+  |  +--------+ |
         | |Vend. C |--|--+    \                /    +--|--| Vend. C| |
         | +--------+  |    +---\              /---+    |  +--------+ |
         | +--------+  |    |    ~-(        )-~    |    |  +--------+ |
         | |Vend. D |--|----+       (__  __)       +----|--| Vend. D| |
         | +--------+  |               --               |  +--------+ |
         \_____________/                                \_____________/
                    ^                                       ^
                    |                                       |
                    |                                       |

                 Scope of draft-ietf-ccamp-dwdm-if-param-yang

                   Figure 1. Control Plane Architecture

   The models developed in this document is an abstracted Yang model
   that may be used in the interfaces colored in yellow between the MDSC and the Optical
   Domain Controller (aka MPI) and between the Optical Domain
   Controller and the Optical Device (aka SBI) in Figure 1. It is not
   intended to support detailed device congiuration low-level DWDM interface model.
   Device configuration DWDM
   interface model is supported by the models presented in
   [draft-ietf-ccamp-dwdm-if-parameter-yang]. [draft-ietf-
   ccamp-dwdm-if-parameter-yang].

2.2. Transport Data Plane

   This section provides the description of the reference optical
   network architecture and its relevant components to support optical
   impairment-aware path computation.

   Figure 2 shows the reference architecture.

    +-------------------+                       +-------------------+
    |     ROADM Node    |                       |     ROADM Node    |
    |                   |                       |                   |
    | PA  +-------+ BA  |          ILA         ILA          | PA  +-------+ BA  |
    | +-+ |  WSS/ | +-+ |  _____   +--+  ____  +--+  _____  | +-+ |  WSS/ | +-+ |
   ---|-|
  --|-| |-|Filter |-| |-|-()____)--|  |-()___)-|  |-()____)--|-|  |-()____)-|-| |-|Filter |-| |-|--- |-|--
    | +-+ |       | +-+ |          +--+        +--+         | +-+ |       | +-+ |
    |     +-------+     |  optical              |     +-------+     |
    |       | | |       |   fiber               |       | | |       |
    |       | | |       |                       |       | | |       |
    |       o-o-o       |                       |       o-o-o       |
    |    transponders   |                       |    transponders   |
    +-------------------+                       +-------------------+
                           OTS Link      OTS Link     OTS Link
                          ----------->   -------->
                        ----------->   ---------->

                                  OMS Link
                      ---------------------------------------------->
                      --------------------------------->

   PA: Pre-Amplifier
   BA: Booster Amplifier
   ILA: In-Line Amplifier

      Figure 2. Reference Architecture for Optical Transport Network

   BA (on the left side ROADM) is the ingress Amplifier and PA (on the
   right side ROADM is the egress amplifier for the OMS link shown in
   the Figure.

2.3. OMS Media Links

   According to [G.872], OMS Media Link represents a media link between
   two ROADM. Specifically, it originates at the ROADM's Filter in the
   source ROADM and terminates at the ROADM's Filter in the destination
   ROADM.

   OTS Media Link represents a media link:
   (i)   between ROADM's BA and ILA;
   (ii)  between a pair of ILAs;
   (iii) between ILA and ROADM's PA.

   OMS Media link can be decomposed of in a number sequence of elements, which are
   basically OTS links type
   (i), (ii), and (iii) as discussed above. OMS Media link would give
   an abstracted view of impairment data (e.g., power, OSNR, etc.) to
   the network controller.

   For the sake of optical impairment evaluation OMS Media link can be
   also decomposed in a sequence of elements such as BA, fiber section,
   ILA, concentrated loss and PA.

2.3.1. Optical Tributary Signal Group (OTSiG) (OTSi)

   The Media Channel and Network Media Channel are well modelled by the
   RFC7698, RFC7699 and RFC7792 reflecting the ITU-T Recommendations
   G.694.1 and G.698.2.

   Some work OTSi is in progress defined in ITU-T SG15/Q12 to define Network Media
   Channel (group) Recommendation G.959.1, section 3.2.4
   [G.959.1]. The YANG model defined below assumes that is capable a single OTSi
   consists of accommodating  the a single modulated optical
   tributary signals (OTSi) belonging to carrier. This single
   modulated optical tributary signal group
   (OTSiG). ( see new ITU-T Draft Recommendation G.807)).

   Currently, no models exist (in the IETF nor ITU-T SG15) that define
   how carrier conveys digital information.
   Characteristics of the optical tributary signals OTSi signal are described inside modulation scheme (e.g. QPSK,
   8-QAM, 16-QAM, etc.), baud rate (measure of the Network
   Media Channel symbol rate), pulse
   shaping (e.g. raised cosine - complying with the Nyquist inter
   symbol interference criterion), etc.

2.3.2. Optical Tributary Signal Group in terms (OTSiG)

   The definition of OTSi identifier, OTSi carrier
   frequency and OTSi signal width.

   There are several options how the mentioned parameters can be
   described. One option OTSiG is currently being moved from ITU-T
   Recommendation G.709 [G.709] to use the description defined in draft-
   ggalimbe-ccamp-flexigrid-carrier-label.

   A second option new draft Recommendation G.807
   (still work in progress) [G.807]. The OTSiG is to describe an electrical signal
   that is carried by one or more OTSi's. The relationship between the OTsi carrier frequency relative
   to
   OTSiG and the anchor frequency 193.1THz based on the OTSi's is described in ITU-T draft Recommendation
   G.807, section 10.2 [G.807]. The YANG model below supports both
   cases: the single OTSi case where the OTSiG contains a well-defined granularity
   (e.g. single OTSi carrier frequency = 193100 (GHz) + K * granularity (GHz)
   (see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple
   OTSi case where K is the OTSiG consists of more than one OTSi (see ITU-T
   draft Recommendation G.807, Figure 10-3). From a signed integer value).

   A third option layer 0 topology
   YANG model perspective, the OTSiG is a logical construct that
   associates the OTSi's, which belong to explicitly describe the same OTSiG. The typical
   application of an OTSiG consisting of more than one OTSi carrier frequency is inverse
   multiplexing. Constraints exist for the OTSi's belonging to the same
   OTSiG such as: (i) all OTSi's must be co-routed over the same
   optical fibers and nodes and (ii) the OTSi differential delay between the
   different OTSi's may not exceed a certain limit. Example: a 400Gbps
   client signal width may be carried by 4 OTSi's where each OTSi carries
   100Gbps of client traffic.

                                   OTSiG
          __________________________/\__________________________
         /                                                      \
                                    m=7
   - - - +---------------------------X---------------------------+ - -
   / / / |                                                       | / /
    / / /|      OTSi         OTSi         OTSi         OTSi      |/ / /
   / / / |        ^            ^            ^            ^       | / /
    / / /|        |            |            |            |       |/ / /
   / / / |        |            |            |            |       | / /
    / / /|        |            |            |            |       |/ / /
    -4  -3  -2  -1   0   1   2   3   4   5   6   7   8   9   10  11  12
   --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
                                   n = ?
                  K1           K2            K3           K4

   2.3.3 Media Channel (MC)

   The definition of the MC is currently being moved from ITU-T
   Recommendation G.872 [G.872] to the new draft Recommendation G.807
   (still work in GHz progress) [G.807]. Section 3.2.2 defines the term MC
   and section 7.1.2 provides a more detailed description with some
   examples. The definition of the MC is very generic (see ITU-T draft
   Recommendation G.807, Figure 7-1). In the YANG model below, the MC
   is used with the following semantics:

   The MC is an end-to-end topological network construct and can be
   considered as an "optical pipe" with a certain accuracy.

   It well-defined frequency slot
   between one or more optical transmitters each generating an OTSi and
   the corresponding optical receivers terminating the OTSi's. If the
   MC carries more than one OTSi, it is proposed assumed that these OTSi's
   belong to use the third option which same OTSiG.

                                    m=8
     +-------------------------------X------------------------------+
     |                               |                              |
     |     +----------X----------+   |   +----------X----------+    |
     |     |        OTSi         |       |         OTSi        |    |
     |     |          o          |   |   |          o          |    |
     |     |          |          |       |          |          |    |
  -4  -3  -2  -1   0   1   2   3   4   5   6   7   8   9   10  11  12
    --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--
                      |             n=4             |
                     K1                            K2

     <------------------------ Media Channel ----------------------->

   The frequency slot of the MC is independent defined by the n value defining the
   central frequency of the
   n, MC and the m values alredy define value that defines the width
   of the MC following the flexible grid definition in ITU-T
   Recommendation G.694.1.

   The OTSi carrier G.694.1 [G.694.1]. In this model, the effective
   frequency is described slot as defined in GHz with 3 fractional
   digits (decimal 64 fraction digits 3). ITU-T draft Recommendation G.807 is
   equal to the frequency slot of this end-to-end MC. It is also
   assumed that ROADM devices can switch MCs. For various reasons (e.g.
   differential delay), it is preferred to use a single MC for all
   OTSi's of the same OTSiG. It may however not always be possible to
   find a single MC for carrying all OTSi's of an OTSiG due to spectrum
   occupation along the OTSiG path.

2.3.3. Media Channel Group (MCG)
   The OTSi signal width definition of the MCG is described currently work in GHz with 3 fractional digits
   (decimal 64 fraction digits 3) progress in ITU-T and includes
   is defined in section 7.1.3 of the signal roll off as
   well as some guard band. new ITU-T draft Recommendation
   G.807 (still work in progress) [G.807]. The accuracy of 0.001 GHz does not impose YANG model below assumes
   that the MCG is a requirement on logical grouping of one or more MCs that are used
   to to carry all OTSi's belonging to the
   optical transceiver components (optical transmitter) in terms same OTSiG.

   The MCG can be considered as an association of
   carrier frequency tuneability precision. Today's components
   typically provide MCs without defining
   a tunability precision in hierarchy where each MC is defined by its (n,m) value pair. An MCG
   consists of more than one MC when no single MC can be found from
   source to destination that is wide enough to accommodate all OTSi's
   (modulated carriers) that belong to the range same OTSiG. In such a case
   the set of 1..1.5GHz
   (carrier frequency offset compared OTSi's belonging to a single OTSiG have to be split
   across 2 or more MCs.

                         MCG1 = {M1.1, M1.2}
           _______________________/\_____________________________
          /                                                      \
                   M1.1                   M2           M1.2
           ________/\____________     _____/\______   ____/\_____
          /                      \   /              \/           \

      - - +-------------------------------------------------------+ - -
      / / |                           | / / / / / / /|            | / /
       / /|   OTSi    OTSi    OTSi    |/ / / / / / / |    OTSi    |/ /
      / / |     ^       ^       ^     | / / / / / / /|      ^     | / /
       / /|     |       |       |     |/ / / / / / / |      |     |/ /
      / / |     |       |       |     | / / / / / / /|      |     | / /
       / /|     |       |       |     |/ / / / / / / |      |     |/ /
         -7         -1 0 1 2 3 4 5 6 7 8 9 10  . . . .  . 17 . . 21
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      n=0                   n=11         n=17
                  K1      K2      K3                          K4

   The MCG is relevant for path computation because all end-to-end MCs
   belonging to the configured nominal carrier
   frequency). Future components may provide a better precision as
   technology evolves.

   If needed, a controller may retrieve the transceiver  properties in
   terms of carrier frequency tuneability precision in order same MCG have to be
   capable co-routed, i.e., have to follow
   the same path. Additional constraints may exist (e.g. differential
   delay).

2.4. Amplifiers

   Optical amplifiers are in charge of properly configuring the underlying transceiver.

   [Note from amplifying the Editor]:

   As this description is arbitrarily proposed by optical signal in
   the authors optical itself without any electrical conversion. There are
   three main technologies to cover
   a lack build amplifiers: Erbium Doped Fiber
   Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor
   Optical Amplifier (SOA). Nowadays, most of information optical networks uses
   EDFAs. However, RFA has an attractive feature that it works in IETF and ITU-T, any
   wavelength band with a liaison request to ITU-T
   is needed.

   The authors are willing to contribute to Liaison editing and similar or lower noise figures compared to
   consider any feedback
   EDFA. On the other hand, RFAs consumes more power and proposal from ITU-T.

2.4. are more
   expensive than EDFAs.

   Amplifiers can be classified according to their location in the
   communication link. There are three basic types of amplifiers. amplifiers: ILA,
   Pre-Amplifier and Booster. ILA is In-Line Amplifier which is a
   separate node type while Pre-Amplifier and Booster Amplifier are
   integral elements of ROADM node. From a data modeling perspective,
   Pre-Amplifier and Booster Amplifier are internal functions of a
   ROADM node and as such these elements are hidden within ROADM node.
   In this document, we would avoid internal node details, but attempt
   to abstract as much as possible.

   One modeling consideration of the ROADM internal is to model power
   parameter through the ROADM, factoring the output power from the
   Pre-Amplifier minus the ROADM power loss would give the input power
   to the Booster Amplifier. In other words, Power_in (@ ROADM Booster)
   = Power_out (@ ROADM Pre-Amplifier) - Power_loss (@ ROADM
   WSS/Filter).

2.4.1. In-Line Amplifier

   (Need to explain details including VOA)

2.5. Transponders

   A Transponder is the element that sends and receives the optical
   signal from a fiber. A transponder is typically characterized by its
   data rate and the maximum distance the signal can travel. Channel
   frequency, per channel input power, FEC and Modulation are also
   associated with a transponder. From a path computation point of
   view, the selection of the compatible source and destination
   transponders is an important factor for optical signal to traverse
   through the fiber. There are three main approaches to determine
   optical signal compatibility. Application Code based on G.682.2 G.698.2 is
   one approach that only checks the code at both ends of the
   interface. link.
   Another approach is organization codes that are specific to an
   organization or a vendor. The third approach is specify all the
   relevant parameters explicitly, e.g., FEC type, Modulation type,
   etc.

   [Editor's Note: The current YANG model described in Section 3 with
   respect to the relationship between the transponder attributes and
   the OTSi will need to be investigated in the future revision]

2.6. WSS/Filter

   WSS separates the incoming light input spectrally as well as
   spatially, then chooses the wavelength that is of interest by
   deflecting it from the original optical path and then couple it to
   another optical fibre port. WSS/Filter is internal to ROADM. So this
   document does not model the inside of ROADM.

2.7. Optical Fiber

   There are various optical fiber types defined by ITU-T. There are
   several fiber-level parameters that need to be factored in, such as,
   fiber-type, length, loss coefficient, pmd, connectors (in/out).

   ITU-T G.652 defines Standard Singlemode Fiber; G.654 Cutoff Shifted
   Fiber; G.655 Non-Zero Dispersion Shifted Fiber; G.656 Non-Zero
   Dispersion for Wideband Optical Transport; G.657 Bend-Insensitive
   Fiber. There may be other fiber-types that need to be considered.

3. YANG Model (Tree Structure)

module: ietf-optical-impairment-topology
  augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
    +--rw optical-impairment-topology!
  augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes:
    +--ro OMS-attributes
       +--ro generalized-snr?                        decimal64
       +--ro equalization-mode                       identityref
       +--ro (power-param)?
       |  +--:(channel-power)
       |  |  +--ro nominal-channel-power?            decimal64
       |  +--:(power-spectral-density)
       |     +--ro nominal-power-spectral-density?   decimal64
       +--ro network-media-channel-group* media-channel-group* [i]
       |  +--ro i                 int16
       |  +--ro current-channels* [flex-n]
          | media-channels* [flexi-n]
       |     +--ro flex-n flexi-n      uint16
       |  |     +--ro flex-m? flexi-m?     uint16
       |     +--ro OTSiG-container* [carrier-id]
          |     +--ro carrier-id                int16
          |     +--ro OTSi-carrier-frequency?   decimal64
          |     +--ro OTSi-signal-width?        decimal64 OTSiG-ref?   leafref
       |     +--ro channel-delta-power?      decimal64 OTSi-ref?    leafref
       +--ro OMS-elements* [elt-index]
          +--ro elt-index    uint16
          +--ro uid?         string
          +--ro type         identityref
          +--ro element
             +--ro (element)?
                +--:(amplifier)
                |  +--ro amplifier
                |     +--ro type_variety    string
                |     +--ro operational
                |        +--ro actual-gain
                |        |       decimal64
                |        +--ro tilt-target
                |        |       decimal64
                |        +--ro out-voa
                |        |       decimal64
                |        +--ro in-voa
                |        |       decimal64
                |        +--ro (power-param)?
                |           +--:(channel-power)
                |           |  +--ro nominal-channel-power?
                |           |          decimal64
                |           +--:(power-spectral-density)
                |              +--ro nominal-power-spectral-density?
                |                      decimal64
                +--:(fiber)
                |  +--ro fiber
                |     +--ro type_variety    string
                |     +--ro length          decimal64
                |     +--ro loss_coef       decimal64
                |     +--ro total_loss      decimal64
                |     +--ro pmd?            decimal64
                |     +--ro conn_in?        decimal64
                |     +--ro conn_out?       decimal64
                +--:(concentratedloss)
                   +--ro concentratedloss
                      +--ro loss?   decimal64
  augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: /nw:networks/nw:network/nw:node/tet:te
            /tet:tunnel-termination-point:
    +--ro OTSiG-element* [OTSiG-identifier]
    |  +--ro OTSiG-identifier    int16
    |  +--ro OTSiG-container
    |     +--ro OTSi* [OTSi-carrier-id]
    |        +--ro OTSi-carrier-id           int16
    |        +--ro OTSi-carrier-frequency?   decimal64
    |        +--ro OTSi-signal-width?        decimal64
    |        +--ro channel-delta-power?      decimal64
    +--ro transponders-list* [transponder-id]
       +--ro transponder-id                   uint32
       +--ro (mode)?
       |  +--:(G.692.2)
       |  |  +--ro G.692.2? standard_mode?             layer0-types:standard-mode
       |  +--:(organizational_mode)
       |  |  +--ro operational-mode?
       |  |  |       layer0-types:operational-mode
       |  |  +--ro organization-identifier?
       |  |          layer0-types:vendor-identifier
       |  +--:(explicit_mode)
       |     +--ro available-modulation*      identityref
       |     +--ro modulation-type?           identityref
       |     +--ro available-baud-rates*      uint32
       |     +--ro configured-baud-rate?      uint32
       |     +--ro available-FEC*             identityref
       |     +--ro FEC-type?                  identityref
       |     +--ro FEC-code-rate?             decimal64
       |     +--ro FEC-threshold?             decimal64
       +--ro power?                           int32
       +--ro power-min?                       int32
       +--ro power-max?                       int32
  augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point: /nw:networks/nw:network/nw:node/tet:te
            /tet:tunnel-termination-point:
    +--ro transponder-list* [carrier-id]
       +--ro carrier-id    uint32

4. Optical Impairment Topology YANG Model

<CODE BEGINS> file ietf-optical-impairment-topology@2018-02-27.yang ietf-optical-impairment-topology@2018-05-22.yang
module ietf-optical-impairment-topology {
  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology";

  prefix "optical-imp-topo";

  import ietf-network {
    prefix "nw";
  }
  import ietf-network-topology {
    prefix "nt";
  }

  import ietf-te-topology {
    prefix "tet";
  }

  import ietf-layer0-types {
    prefix "layer0-types";
  }

  organization
    "IETF CCAMP Working Group";

  contact
    "Editor:   Young Lee  <leeyoung@huawei.com> <younglee.tx@gmail.com>
     Editor:   Haomian Zheng <zhenghaomian@huawei.com>
     Editor:   Nicola Sambo <nicosambo@gmail.com>
     Editor:   Victor Lopez <victor.lopezalvarez@telefonica.com>
     Editor:   Gabriele Galimberti <ggalimbe@cisco.com>
     Editor:   Giovanni Martinelli <giomarti@cisco.com>
     Editor:   Auge Jean-Luc <jeanluc.auge@orange.com>
     Editor:   Le Rouzic Esther <esther.lerouzic@orange.com>
     Editor:   Julien Meuric <julien.meuric@orange.com>
     Editor:   Italo Busi <Italo.Busi@huawei.com>"; <Italo.Busi@huawei.com>
     Editor:   Dieter Beller <dieter.beller@nokia.com>
     Editor:   Sergio Belotti <Sergio.belotti@nokia.com>
     Editor:   Griseri Enrico <enrico.griseri@nokia.com>
     Editor:   Gert Grammel <ggrammel@juniper.net>";

  description
    "This module contains a collection of YANG definitions for
     impairment-aware optical networks.

     Copyright (c) 2019 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD
     License set forth in Section 4.c of the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info).";

  revision 2019-02-27 2019-05-22 {
    description
      "Initial Version";
    reference
      "RFC XXXX: A Yang Data Model for Impairment-aware
       Optical Networks";
  }

  identity modulation {
    description "base identity for modulation type";
  }

  identity QPSK {
    base modulation;
    description
      "QPSK (Quadrature Phase Shift Keying) modulation";
  }

  identity DP_QPSK {
    base modulation;
    description
      "DP-QPSK (Dual Polarization Quadrature
       Phase Shift Keying) modulation";
  }
  identity QAM8 {
    base modulation;
    description
      "8QAM (8-State Quadrature Amplitude Modulation) modulation";
  }
  identity QAM16 {
    base modulation;
    description
      "QAM16 (Quadrature Amplitude Modulation)";
  }
  identity DP_QAM8 {
    base modulation;
    description
      "DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)";
  }
  identity DC_DP_QAM8 {
    base modulation;
    description
      "DC DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)";
  }
  identity DP_QAM16 {
    base modulation;
    description
      "DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)";
  }
  identity DC_DP_QAM16 {
    base modulation;
    description
      "DC DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)";
  }

  identity FEC {
    description
      "Enumeration that defines the type of
       Forward Error Correction";
  }
  identity reed-solomon {
    base FEC;
      description
  "Reed-Solomon error correction";
  }
  identity hamming-code {
    base FEC;
      description
  "Hamming Code error correction";
  }
  identity golay {
    base FEC;
      description "Golay error correction";
  }

  typedef fiber-type {
    type enumeration {
      enum G.652 {
      description "G.652 Standard Singlemode Fiber";
      }
      enum G.654 {
        description "G.654 Cutoff Shifted Fiber";
      }
      enum G.653 {
        description "G.653 Dispersion Shifted Fiber";
      }
      enum G.655 {
        description "G.655 Non-Zero Dispersion Shifted Fiber";
      }
      enum G.656 {
        description "G.656 Non-Zero Dispersion for Wideband
               Optical Transport";
      }
      enum G.657 {
        description "G.657 Bend-Insensitive Fiber";
      }
    }
    description
      "ITU-T based fiber-types";

  }

  grouping transponder-attributes {
    description "Configuration of an optical transponder";

    leaf-list available-modulation {
      type identityref {
      base modulation;
      }
      config false;
    description
      "List determining all the available modulations";
    }

    leaf modulation-type {
      type identityref {
      base modulation;
      }
    config false;
      description
      "Modulation configured for the transponder";
    }

    leaf-list available-baud-rates {
      type uint32;
      units Bd;
      config false;
      description
        "list of available baud-rates. Baud-rate is the unit for
         symbol rate or modulation rate in symbols per second or
         pulses per second. It is the number of distinct symbol
         changes (signaling events) made to the transmission medium
         per second in a digitally modulated signal or a line code";
    }

    leaf configured-baud-rate {
      type uint32;
      units Bd;
    config false;
      description "configured baud-rate";
    }

    leaf-list available-FEC {
      type identityref {
      base FEC;
      }
      config false;
      description "List determining all the available FEC";
    }
    leaf FEC-type {
      type identityref {
      base FEC;
      }
      config false;
    description
      "FEC type configured for the transponder";
    }

    leaf FEC-code-rate {
      type decimal64 {
      fraction-digits 8;
      range "0..max";
      }
      config false;
      description "FEC-code-rate";
    }

    leaf FEC-threshold {
      type decimal64 {
      fraction-digits 8;
      range "0..max";
      }
      config false;
    description
        "Threshold on the BER, for which FEC is able to correct errors";
    }

  }

  grouping sliceable-transponder-attributes {
    description
      "Configuration of a sliceable transponder.";
    list transponder-list {
      key "carrier-id";
      config false;
      description "List of carriers";
      leaf carrier-id {
        type uint32;
        config false;
        description "Identifier of the carrier";
      }
    }
  }

  grouping optical-fiber-data {
    description
    "optical link (fiber) attributes with impairment data";
    leaf fiber-type {
      type fiber-type;
      config false;
      description "fiber-type";
    }

    leaf span-length {
      type decimal64 {
        fraction-digits 2;
      }
      units "km";
      config false;
      description "the lenght of the fiber span in km";
    }

    leaf input-power {
      type decimal64 {
        fraction-digits 2;
      }
      units "dBm";
      config false;
      description
      "Average input power level estimated at the receiver
         of the link";
    }

    leaf output-power {
      type decimal64 {
        fraction-digits 2;
      }
      units "dBm";
      description
      "Mean launched power at the transmitter of the link";
    }

    leaf pmd {
      type decimal64 {
        fraction-digits 8;
        range "0..max";
      }
      units "ps/(km)^0.5";
      config false;
      description
      "Polarization Mode Dispersion";
    }

    leaf cd {
      type decimal64 {
        fraction-digits 5;

      }
      units "ps/nm/km";
      config false;
      description
      "Cromatic Dispersion";
    }

    leaf osnr {
      type decimal64 {
        fraction-digits 5;
      }
      units "dB";
      config false;
      description
      "Optical Signal-to-Noise Ratio (OSNR) estimated
         at the receiver";
    }

    leaf sigma {
      type decimal64 {
        fraction-digits 5;
      }
      units "dB";
      config false;
      description
      "sigma in the Gausian Noise Model";
    }
  }

  grouping optical-channel-data {
  description
    "optical impairment data per channel/wavelength";
  leaf bit-rate {
    type decimal64 {
      fraction-digits 8;
        range "0..max";
    }
    units "Gbit/s";
    config false;
    description
      "Gross bit rate";
  }

    leaf BER {
    type decimal64 {
      fraction-digits 18;
            range "0..max";
    }
    config false;
      description
      "BER (Bit Error Rate)";
  }

    leaf ch-input-power {
          type decimal64 {
           fraction-digits 2;
        }
        units "dBm";
        config false;
        description
    "Per channel average input power level
          estimated at the receiver of the link";
        }

  leaf ch-pmd {
    type decimal64 {
        fraction-digits 8;
      range "0..max";
    }
    units "ps/(km)^0.5";
    config false;
    description
      "per channel Polarization Mode Dispersion";
  }

  leaf ch-cd {
    type decimal64 {
            fraction-digits 5;
    }
    units "ps/nm/km";
    config false;
          description
      "per channel Cromatic Dispersion";
  }

  leaf ch-osnr {
    type decimal64 {
      fraction-digits 5;
    }
      units "dB";
    config false;
    description
      "per channel Optical Signal-to-Noise Ratio
            (OSNR) estimated at the receiver";
        }

    leaf q-factor {
    type decimal64 {
      fraction-digits 5;
    }
    units "dB";
    config false;
      description
      "q-factor estimated at the receiver";
  }
  }

  grouping standard_mode {
    description
      "ITU-T G.698.2 standard mode that guarantees interoperability.
       It must be an string with the following format:
       B-DScW-ytz(v) where all these attributes are conformant
       to the ITU-T recomendation";

    leaf standard_mode {
      type layer0-types:standard-mode;
      config false;
      description
        "G.698.2 standard mode";
    }
  }

  grouping organizational_mode {
    description
      "Transponder operational mode supported by organizations or
       vendor";

    leaf operational-mode {
      type layer0-types:operational-mode;
      config false;
      description
        "configured organization- or vendor-specific
         application identifiers (AI) supported by the transponder";
    }

    leaf organization-identifier {
      type layer0-types:vendor-identifier;
      config false;
      description
      "organization identifier that uses organizational
         mode";

    }
  }

    /*
   * Identities
   */
  identity type-element {
    description
      "Base identity for element type";
  }

  identity Fiber {
    base type-element;
    description
      "Fiber element";
  }

  identity Roadm {
    base type-element;
    description
      "Roadm element";
  }

  identity Edfa {
    base type-element;
    description
      "Edfa element";
  }

  identity Concentratedloss {
    base type-element;
    description
      "Concentratedloss element";
  }

  identity type-power-mode {
    description
      "power equalization mode used within the OMS and its elements";
  }

  identity power-spectral-density {
    base type-power-mode;
    description
      "all elements must use power spectral density (W/Hz)";
  }

  identity channel-power {
    base type-power-mode;
    description
      "all elements must use power (dBm)";
  }

  /*
   * Groupings
   */
  grouping amplifier-params {
    description "describes parameters for an amplifier";
    container amplifier{
    description "amplifier type, operatonal parameters are described";
      leaf type_variety {
        type string ;
        mandatory true ;
        description
          "String identifier of amplifier type referencing
          a specification in a separate equipment catalog";
      }
      container operational {
        description "amplifier operationnal parameters";
        leaf actual-gain {
          type decimal64 {
            fraction-digits 2;
          }
          units dB ;
      mandatory true ;
          description "..";
        }
        leaf tilt-target {
          type decimal64 {
            fraction-digits 2;
          }
          mandatory true ;
          description "..";
        }
        leaf out-voa {
          type decimal64 {
            fraction-digits 2;
          }
          units dB;
      mandatory true;
          description "..";
        }
        leaf in-voa {
          type decimal64 {
            fraction-digits 2;
          }
          units dB;
      mandatory true;
          description "..";
        }
        uses power-param;
      }
    }
  }
  grouping fiber-params {
    description "String identifier of fiber type referencing a specification in a
separate equipment catalog";
    container fiber {
    description "fiber characteristics";
      leaf type_variety {
        type string ;
    mandatory true ;
        description "fiber type";
      }
      leaf length {
        type decimal64 {
          fraction-digits 2;
        }
        units km;
    mandatory true ;
    description "length of fiber";
      }
      leaf loss_coef {
        type decimal64 {
          fraction-digits 2;
        }
        units dB/km;
    mandatory true ;
    description "loss coefficient of the fiber";
      }
      leaf total_loss {
        type decimal64 {
          fraction-digits 2;
        }
        units dB;
    mandatory true ;
        description
          "includes all losses: fiber loss and conn_in and conn_out losses";
      }
      leaf pmd{
        type decimal64 {
          fraction-digits 2;
        }
        units sqrt(ps);
    description "pmd of the fiber";
      }
      leaf conn_in{
        type decimal64 {
          fraction-digits 2;
        }
        units dB;
    description "connector-in";
      }
      leaf conn_out{
        type decimal64 {
          fraction-digits 2;
        }
        units dB;
    description "connector-out";
      }
    }
  }

  grouping roadm-params{
    description "roadm parameters description";
    container roadm{
    description "roadm parameters";
      leaf type_variety {
        type string ;
        mandatory true ;
        description "String identifier of roadm type referencing a specification in a
separate equipment catalog";
      }
      leaf loss {
        type decimal64 {
          fraction-digits 2;
        }
        units dB ;
        description "..";
      }
    }
  }

  grouping concentratedloss-params{
    description "concentrated loss";
    container concentratedloss{
    description "concentrated loss";
      leaf loss {
        type decimal64 {
          fraction-digits 2;
        }
        units dB ;
        description "..";
      }
    }
  }

  grouping power-param{
    description
      "optical power or PSD after the ROADM or after the out-voa";
    choice power-param {
      description
        "select the mode: channel power or power spectral density";
      case channel-power {
 /*       when "../../equalization-mode='channel-power'"; "equalization-mode='channel-power'"; */
        leaf nominal-channel-power{
          type decimal64 {
              fraction-digits 1;
          }
          units dBm ;
          description
            " Reference channel power after the ROADM or after the out-voa. ";
        }
      }
      case power-spectral-density{
 /*       when "../../equalization-mode='power-spectral-density'"; "equalization-mode='power-spectral-density'"; */
        leaf nominal-power-spectral-density{
          type decimal64 {
              fraction-digits 16;
          }
          units W/Hz ;
          description
            " Reference power spectral density after the ROADM or after the out-voa.
              Typical value : 3.9 E-14, resolution 0.1nW/MHz";
        }
      }
    }
  }

  grouping oms-general-optical-params {
    description "OMS link optical parameters";
    leaf generalized-snr {
      type decimal64 {
        fraction-digits 5;
      }
      units "dB@0.1nm";
      description "generalized snr";
    }
    leaf equalization-mode{
      type identityref {
        base type-power-mode;
      }
      mandatory true;
      description "equalization mode";
    }
    uses power-param;
  }

  grouping network-media-channel-group OTSiG {
    description "network media channel group";
    list network-media-channel-group {
     key "i";
      description
        "list of network media channel group's member";
      leaf i "OTSiG definition , representing client digital information stream
supported by 1 or more OTSi";

    container OTSiG-container {
        type int16;
      config false;
      description "index
        "the container contains the related list of network media channel group member";
      } OTSi.
       The list current-channels {
        key "flex-n";
        description
          "list could also be of media channels in the OMS";

        uses layer0-types:flex-grid-channel;
     } only 1 element";
     list OTSiG-container OTSi {
       key "carrier-id"; "OTSi-carrier-id";
       description
         "list of OTSi OTSi's under OTSi-G";
       leaf carrier-id OTSi-carrier-id {
         type int16;
         description "carrier-id under OTSi-G"; "OTSi carrier-id";
         }
       leaf OTSi-carrier-frequency {
         type decimal64 {
           fraction-digits 3;
         }
         units GHz;
         config false;
         description
           "OTSi carrier frequency";
       }
       leaf OTSi-signal-width {
         type decimal64 {
           fraction-digits 3;
         }
         units GHz;
         config false;
         description
           "OTSi signal width";
       }
       leaf channel-delta-power {
         type decimal64 {
           fraction-digits 2;
         }
         units dB;
         config false;
         description
           "optional ; delta power to ref channel input-power applied
          to this media channel";
       }

     }
    }  // OTSiG container
  } // OTSiG grouping
  grouping media-channel-groups {
    description "media channel groups";
    list media-channel-group {
    key "i";
      description
        "list of media channel groups";
      leaf i {
        type int16;
          description "index of media channel group member";
      }

      list media-channels {
        key "flexi-n";
        description
          "list of media channels represented as (n,m)";
        uses layer0-types:flexi-grid-channel;
        leaf OTSiG-ref {
          type leafref {
           path "/nw:networks/nw:network/nw:node/tet:te" +
                "/tet:tunnel-termination-point/OTSiG-element/OTSiG-identifier" ;

          }
          description
             "Reference to the OTSiG list to get OTSiG identifier of the
              OSiG carried by this media channel that reports the transient stat";
        }
        leaf OTSi-ref {
          type leafref {
            path "/nw:networks/nw:network/nw:node/tet:te" +
                "/tet:tunnel-termination-point/OTSiG-element[OTSiG-
identifier=current()/../OTSiG-ref]/"+
                "OTSiG-container/OTSi/OTSi-carrier-id" ;
          }
          description
             "Reference to the OTSi list supporting the related OTSiG" ;
        }

      } // media channels list
    } // media-channel-groups list
  } // media media-channel-groups grouping

  grouping oms-element {
    description "OMS description";
    list OMS-elements {
        key "elt-index";
        description
          "defines the spans and the amplifier blocks of the amplified lines";
        leaf elt-index {
          type uint16;
          description
            "ordered list of Index of OMS element (whether it's a Fiber, an EDFA or a
Concentratedloss)";
        }
        leaf uid {
          type string;
          description
            "unique id of the element if it exists";
        }
        leaf type {
          type identityref {
             base type-element;
          }
      mandatory true;
      description "element type";
        }

        container element {
          description "element of the list of elements of the OMS";
          choice element {
        description "OMS element type";
            case amplifier {
 /*             when "../..type "type = 'Edfa'"; */
              uses amplifier-params ;
            }
            case fiber {
/*              when "../../type "type = 'Fiber'"; */
              uses fiber-params ;
            }
            case concentratedloss {
/*             when "../../type "type = 'Concentratedloss'"; */
              uses concentratedloss-params ;
            }
          }
        }
    }
  }

/* Data nodes */

  augment "/nw:networks/nw:network/nw:network-types"
   + "/tet:te-topology" {
   description "optical-impairment topology augmented";
   container optical-impairment-topology {
     presence "indicates an impairment-aware topology of optical networks";
     description
     "Container to identify impairment-aware topology type";
   }

  }

  augment "/nw:networks/nw:network/nt:link/tet:te"
   + "/tet:te-link-attributes"   {
   when "/nw:networks/nw:network/nw:network-types"
    +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" {
    description
      "This augment is only valid for Optical Impairment.";
   }
   description "Optical Link augmentation for impairment data.";
   container OMS-attributes {
       config false;
       description "OMS attributes";
     uses oms-general-optical-params;
     uses network-media-channel-group; media-channel-groups;
     uses oms-element;
     }
  }

  augment "/nw:networks/nw:network/nw:node/tet:te"
   + "/tet:tunnel-termination-point" {
   when "/nw:networks/nw:network/nw:network-types"
    +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" {
    description
      "This augment is only valid for Impairment with non-sliceable
       transponder model";
   }
   description
     "Tunnel termination point augmentation for non-sliceable
      transponder model.";

     list OTSiG-element {
         key "OTSiG-identifier";
         config false;
         description
         "the list of possible OTSiG representing client digital stream";

         leaf OTSiG-identifier {
            type int16;
             description "index of OTSiG element";
         }
         uses OTSiG;
     }

     list transponders-list {
         key "transponder-id";
     config false;
         description "list of transponders";
         leaf transponder-id {

       type uint32;
       description "transponder identifier";
         }

         choice mode {
             description "standard mode, organizational mode or explicit mode";

             case G.692.2 {
               uses standard_mode;
             }

             case organizational_mode {
               uses organizational_mode;
             }

             case explicit_mode {
               uses transponder-attributes;
             }
         }

         leaf power {
           type int32;
           units "dBm";
           config false;
           description "per channel power";
         }

         leaf power-min {
           type int32;
           units "dBm";
           config false;
           description "minimum power of the transponder";
         }

         leaf power-max {
           type int32;
           units "dBm";
           config false;
           description "maximum power of the transponder";
         }
   }
  }

  augment "/nw:networks/nw:network/nw:node/tet:te"
   + "/tet:tunnel-termination-point" {
   when "/nw:networks/nw:network/nw:network-types"
    +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" {
    description
      "This augment is only valid for optical impairment with sliceable
      transponder model";
   }
   description
     "Tunnel termination point augmentation for sliceable transponder model.";
   uses sliceable-transponder-attributes;
  }
}
<CODE ENDS>

5. Security Considerations

   The configuration, state, and action data defined in this document
   are designed to be accessed via a management protocol with a secure
   transport layer, such as NETCONF [RFC6241].  The NETCONF access
   control model [RFC6536] provides the means to restrict access for
   particular NETCONF users to a preconfigured subset of all available
   NETCONF protocol operations and content.

   A number of configuration data nodes defined in this document are
   read-only; however, these data nodes may be considered sensitive or
   vulnerable in some network environments (TBD).

6. IANA Considerations

   This document registers the following namespace URIs in the IETF XML
   registry [RFC3688]:

   --------------------------------------------------------------------
   URI: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.
   --------------------------------------------------------------------

   This document registers the following YANG modules in the YANG
   Module Names registry [RFC7950]:

   --------------------------------------------------------------------
   name:      ietf-optical-impairment-topology
   namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-
   topology
   prefix:    optical-imp-topo
   reference: RFC XXXX (TDB)
   --------------------------------------------------------------------

7. Acknowledgments

   We thank Dieter Bella Daniele Ceccarelli and Sergio Belotti Oscar G. De Dios for useful
   discussions and motivation for this work.

8. References

8.1. Normative References

   [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
             RFC 7950, August 2016.

   [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol",
             RFC 8040, January 2017.

   [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
             Access Control Model", RFC 8341, March 2018.

8.2. Informative References

   [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
             and A. Bierman, Ed., "Network Configuration Protocol
             (NETCONF)", RFC 6241, June 2011.

   [RFC6566]  Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework
             for the Control of Wavelength Switched Optical Networks
             (WSONs) with Impairments", RFC 6566, March 2012.

   [RFC7446] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and
             Wavelength Assignment Information Model for Wavelength
             Switched Optical Networks", RFC 7446, Feburary 2015.

   [RFC7579] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General Network
             Element Constraint Encoding for GMPLS Controlled
             Networks", RFC 7579, June 2015.

   [RFC7581] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
             Wavelength Assignment Information Encoding for Wavelength
             Switched Optical Networks", RFC 7581, June 2015.

   [RFC7950] Bjorklund, M.,

   [RFC7698] O. Gonzalez de Dios, Ed. and R. Casellas, Ed., "The YANG 1.1 Data Modeling Language",
             RFC 7950, August 2016.

   [RFC8341] Bierman, A. "Framework
             and Requirements for GMPLS-Based Control of Flexi-Grid
             Dense Wavelength Division Multiplexing (DWDM) Networks",
             RFC 7698, November 2015.

   [RFC8340] M. Bjorklund, "Network Configuration
             Access Control Model", L. Berger, Ed., "YANG Tree Diagrams", RFC 8341,
             8340, March 2018.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
             and R. Wilton, "Network Management Datastore Architecture
             (NMDA)", RFC 8342, March 2018.

   [RFC8345]  A. Clemm, et al, "A YANG Data Model for Network
             Topologies", RFC 8345, March 2018.

   [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work
             in progress: draft-ietf-teas-yang-te-topo.

   [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
             Control of Traffic Engineered Networks", RFC 8453, August
             2018.

   [WSON-Topo] Y. Lee, Ed., "A Yang Data Model for WSON Optical
             Networks", draft-ietf-ccamp-wson-yang-13, work in
             progress.

   [L0-Types] Y. Lee, Ed., "A YANG Data Model for Layer 0 Types",
             draft-ietf-ccamp-layer0-types, work in progress.

   [G.807] "Draft new Recommendation ITU-T G.807 (ex G.media)", ITU-T
             Recommendation G.807, work in progress.

   [G.709] "Interfaces for the Optical Transport Network (OTN)", ITU-T
             Recommendation G.709, June 2016.

   [G.694.1] "Spectral grids for WDM applications: DWDM frequency
             grid", ITU-T Recommendation G.694.1, February 2012.

   [G.959.1] "Optical transport network physical layer interfaces",
             ITU-T Recommendation G.959.1, February 2012.

   [G.872] "Architecture of optical transport networks", ITU-T
             Recommendation G.872, January 2017.

9. Contributors

   Jonas Martensson
   Acro
   RISE

   Email: jonas.martensson@ri.se

   Aihua Guo
   Huawei Technologies

   Email: aguo@futurewei.com

Authors' Addresses

   Young Lee
   Huawei
   Futurewei Technologies

   Email: leeyoung@huawei.com younglee.tx@gmail.com

   Haomian Zheng
   Huawei Technologies

   Email: zhenghaomian@huawei.com

   Italo Busi
   Huawei Technologies

   Email: Italo.Busi@huawei.com

   Nicola Sambo
   Scuola Superiore Sant'Anna

   Email: nicosambo@gmail.com

   Victor Lopez
   Telefonica

   Email: victor.lopezalvarez@telefonica.com

   G. Galimberti
   Cisco
   Email: ggalimbe@cisco.com

   Giovanni Martinelli
   Cisco
   Email: giomarti@cisco.com

   AUGE Jean Luc
   Orange

   Email:  jeanluc.auge@orange.com

   LE ROUZIC Esther
   Orange

   Email: esther.lerouzic@orange.com

   Julien Meuric
   Orange

   Email: julien.meuric@orange.com

   Dieter Beller
   Nokia

   Email: dieter.beller@nokia.com

   Sergio Belotti
   Nokia

   Email: Sergio.belotti@nokia.com

   Griseri Enrico
   Nokia

   Email: enrico.griseri@nokia.com

   Gert Grammel
   Juniper

   Email: ggrammel@juniper.net