[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

CCAMP Working Group                                       I. Busi (Ed.)
Internet Draft                                                   Huawei
Intended status: Informational                            D. King (Ed.)
                                                   Lancaster University

Expires: April 2018                                    October 30, 2017



          Analysis of Transport North Bound Interface Use Case 1
             draft-tnbidt-ccamp-transport-nbi-analysis-uc1-01


Status of this Memo

   This Internet-Draft is submitted 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 April 30, 2018.

Copyright Notice

   Copyright (c) 2017 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



Busi, King et al.       Expires April 30, 2018                 [Page 1]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   This document analyses how YANG models being defined by IETF (TEAS
   and CCAMP WGs in particular) can be used to support Use Case 1
   (single-domain with single-layer) scenarios, as referenced later in
   this document.

Table of Contents


   1. Introduction...................................................2
      1.1. Assumptions...............................................3
      1.2. Feedbacks provided to the IETF Working Groups.............3
   2. Conventions used in this document..............................4
   3. High-level Overview............................................5
      3.1. Topology Abstraction......................................5
         3.1.1. ODU White Topology Abstraction.......................5
      3.2. Service Configuration.....................................8
         3.2.1. ODU Transit Service..................................8
         3.2.2. EPL over ODU Service................................10
         3.2.3. OTN Client Private Line Service.....................11
         3.2.4. EVPL over ODU Service...............................12
   4. Topology Abstraction: detailed JSON examples..................12
      4.1. ODU White Topology Abstraction...........................12
   5. Service Configuration: detailed JSON examples.................13
      5.1. ODU Transit Service......................................13
   6. Security Considerations.......................................13
   7. IANA Considerations...........................................13
   8. Conclusions...................................................13
   9. References....................................................13
      9.1. Normative References.....................................13
      9.2. Informative References...................................14
   10. Acknowledgments..............................................14
   Appendix A. Validating a JSON fragment against a YANG Model......15
      A.1. DSDL-based approach......................................15
      A.2. Why not using a XSD-based approach.......................15
      A.3. JSON Code: use-case-1-topology-01.json...................16
      A.4. JSON Code: use-case-1-topology-01.json...................16

1. Introduction

   This document analyses how YANG models being developed by IETF (TEAS
   and CCAMP WGs) can be used to support Use Case 1 (single-domain with
   single-layer) scenarios, as described in [TNBI-UseCases].


Busi, King et al.       Expires April 30, 2018                 [Page 2]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


1.1. Assumptions

   This document analyses how existing models developed by the IETF can
   be used at the MPI between the Transport PNC and the MDSC to support
   the use case 1 scenarios, as defined in section 3 of [TNBI-UseCases].

   This document assumes the applicability of the YANG models to the
   ACTN interfaces as defined in [ACTN-YANG] and therefore considers the
   TE Topology YANG model defined in [TE-TOPO], with the OTN Topology
   augmentation defined in [OTN-TOPO] and the TE Tunnel YANG model
   defined in [TE-TUNNEL], with the OTN Tunnel augmentation defined in
   [OTN-TUNNEL].

   The analysis of how to use the attributes in the I2RS Topology YANG
   model, defined in [I2RS-TOPO], is for further study.

   Moreover, this document is making the following assumptions, still to
   be validated with TEAS WG:

   1. The MDSC can request, at the MPI, the Transport PNC to setup a
      Transit Tunnel Segment using the TE Tunnel YANG model: in this
      case, since the endpoints of the E2E Tunnel are outside the domain
      controlled by the Transport PNC, the MDSC would not specify any
      source or destination TTP (i.e., it would leave the source,
      destination, src-tp-id and dst-tp-id attributes empty) and it
      would use the explicit-route-object list to specify the ingress
      and egress links of the Transit Tunnel Segment.

   2. The Transport PNC provides to the MDSC, at the MPI, the list of
      available timeslots on the access links using the TE Topology YANG
      model and OTN Topology augmentation. The TE Topology YANG model in
      [TE-TOPO] is being updated to report the label set information.

1.2. Feedbacks provided to the IETF Working Groups

   The analysis done in this version of this document has triggered the
   following feedbacks to CCAMP WG:

   o  A set of YANG models have been submitted in draft-zheng-ccamp-
      client-topo-yang and draft-zheng-ccamp-otn-client-signal-yang,
      providing an initial proposal, to be reviewed and discussed by the
      DT and the CCAMP WG, to resolve the open issues for EPL, other OTN
      client Private Line and EVPL services described in this version of
      the document.





Busi, King et al.       Expires April 30, 2018                 [Page 3]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


2. Conventions used in this document

   This document provides some detailed JSON code examples to describe
   how the YANG models being developed by IETF (TEAS and CCAMP WG in
   particular) can be used.

   The examples are provided using JSON because JSON code is easier for
   humans to read and write.

   Different objects need to have an identifier. The convention used to
   create mnemonic identifiers is to use the object name (e.g., S3 for
   node S3), followed by its type (e.g., NODE), separated by an "-",
   followed by "-ID". For example the mnemonic identifier for node S3
   would be S3-NODE-ID.

   JSON language does not support the insertion of comments that have
   been instead found to be useful when writing the examples. This
   document inserts comments into the JSON code as JSON name/value pair
   with the JSON name string starting with the "//" characters. For
   example, when describing the example of a TE Topology instance
   representing the ODU Abstract Topology exposed by the Transport PNC,
   the following comment has been added to the JSON code:

      "// comment": "ODU Abstract Topology @ MPI",

   The JSON code examples provided in this document have been validated
   against the YANG models following the validation process described in
   Appendix A, which would not consider the comments.

   In order to have successful validation of the examples, some
   numbering scheme has been defined to assign identifiers to the
   different entities which would pass the syntax checks. In that case,
   to simplify the reading, another JSON name/value pair, formatted as a
   comment and using the mnemonic identifiers is also provided. For
   example, the identifier of node S3 (S3-NODE-ID) has been assumed to
   be "10.0.0.3" and would be shown in the JSON code example using the
   two JSON name/value pair:

      "// te-node-id": "S3-NODE-ID",

      "te-node-id": "10.0.0.3",

   The first JSON name/value pair will be automatically removed in the
   first step of the validation process while the second JSON name/value
   pair will be validate against the YANG model definitions.




Busi, King et al.       Expires April 30, 2018                 [Page 4]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


3. High-level Overview

   Use Case 1 is described in [TNBI-UseCases] as a single-domain with
   single layer network scenario supporting different types of services.
   This section provides a high-level overview of how IETF YANG models
   can be used to support these uses cases at the MPI between the
   Transport PNC and the MDSC.

   Section 3.1 describes the topology abstraction provided to the MDSC
   by the Transport PNC at the MPI.

   Section 3.2 describes how the difference services, defined in section
   4.3 of [TNBI-UseCases], can be requested to the Transport PNC by the
   MDSC at the MPI.

3.1. Topology Abstraction

3.1.1. ODU White Topology Abstraction

   In case the Transport PNC exports to the MDSC a white topology, at
   the MPI there will be one TE Topology instance for the ODU layer
   (called "ODU Topology") containing one TE Node (called "ODU Node")
   for each physical node, as shown in Figure 1 below.


























Busi, King et al.       Expires April 30, 2018                 [Page 5]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


                   ..................................
                   :                                :
                   :   ODU Abstract Topology @ MPI  :
                   :                                :
                   :        +----+        +----+    :
                   :        |    |        |    |    :
                   :        | S1 |--------| S2 |- - - - -(C-R4)
                   :        +----+        +----+    :
                   :         /               |      :
                   :        /                |      :
                   :    +----+   +----+      |      :
                   :    |    |   |    |      |      :
         (C-R1)- - - - -| S3 |---| S4 |      |      :
                   :S3-1+----+   +----+      |      :
                   :        \       \        |      :
                   :         \       \       |      :
                   :        +----+    \      |      :
                   :        |    |     \     |      :
                   :        | S5 |      \    |      :
                   :        +----+       \   |      :
         (C-R2)- - - - -    /   \         \  |      :
                   :S6-1 \ /     \         \ |      :
                   :    +----+   +----+   +----+    :
                   :    |    |   |    |   |    |    :
                   :    | S6 |---| S7 |---| S8 |- - - - -(C-R5)
                   :    +----+   +----+   +----+    :
                   :     /                          :
         (C-R3)- - - - -                            :
                   :S6-2                            :
                   :................................:

             Figure 1 White Topology Abstraction (ODU Topology)

   The ODU Nodes in Figure 1 are using with the same names as the
   physical nodes to simplify the description of the mapping between the
   ODU Nodes exposed by the Transport PNCs at the MPI and the physical
   nodes in the data plane. This does not correspond to the reality of
   the usage of the topology model, as described in section 4.3 of [TE-
   TOPO], in which renaming by the client it is necessary.

   As described in section 3.2 of [TNBI-UseCases], it is assumed that
   the physical links between the physical nodes are pre-configured up
   to the OTU4 trail using mechanisms which are outside the scope of
   this document. The Transport PNC exports to the MDSC via the MPI, one
   TE Link (called "ODU Link") for each of these physical links.




Busi, King et al.       Expires April 30, 2018                 [Page 6]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


   Access links in Figure 1 are shown as ODU Links: the modeling of the
   access links for other access technologies is currently an open
   issue.

   The modeling of the access link in case of non-ODU access technology,
   has also an impact on the need to model ODU TTPs and layer transition
   capabilities on the edge nodes (e.g., nodes S2, S3, S6 and S8 in
   Figure 1).

   If, for example, the physical NE S6, is implemented in a "pizza box",
   the data plane would have only set of ODU termination resources
   (where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and
   160xODUflex can be terminated). The traffic coming from each of the
   10GE access links can be mapped into any of these ODU terminations.

   Instead if, for example, the physical NE S6 can be implemented as a
   multi-board system where access links reside on different/dedicated
   access cards with separated set of ODU termination resources(where up
   to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex for each
   resource can be terminated). The traffic coming from one 10GE access
   links can be mapped only into the ODU terminations which reside on
   the same access card.

   The more generic implementation option for a physical NE (e.g., S6)
   would be case is of a multi-board system with multiple access cards
   with separated sets of access links and ODU termination resources
   (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex
   for each resource can be terminated). The traffic coming from each of
   the 10GE access links on one access card can be mapped only into any
   of the ODU terminations which reside on the same access card.

   In the last two cases, only the ODUs terminated on the same access
   card where the access links resides can carry the traffic coming from
   that 10GE access link. Terminated ODUs can instead be sent to any of
   the OTU4 interfaces

   In all these cases, terminated ODUs can be sent to any of the OTU4
   interfaces assuming the implementation is based on a non-blocking ODU
   cross-connect.

   If the access links are reported via MPI in some, still to be
   defined, client topology, it is possible to report each set of ODU
   termination resources as an ODU TTP within the ODU Topology of Figure
   1 and to use either the inter-layer lock-id or the transitional link,
   as described in sections 3.4 and 3.10 of [TE-TOPO], to correlate the
   access links, in the client topology, with the ODU TTPs, in the ODU
   topology, to which access link are connected to.


Busi, King et al.       Expires April 30, 2018                 [Page 7]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


   The "external-domain" container allows the MDSC to glue together the
   ODU Topology provided by the Transport PNC with the information
   provided by the IP PNC to know which access link is connected with
   each link/router in the IP domain (e.g., that C-R1 is connected with
   the access link terminating on S3-1 LTP in the ODU Topology).

   Further details about how the MDSC can glue together the access link
   information will be added in a future version of this document.

3.2. Service Configuration

3.2.1. ODU Transit Service

   In this case, the access links are configured as ODU Link, as
   described in section 3.1.1 above.

   As described in section 4.3.1 of [TNBI-UseCases], the MDSC needs to
   setup an ODU2 trail, supporting an IP link, between C-R1 and C-R3.

   From the topology information described in section 3.1.1 above, the
   MDSC can know that C-R1 is attached to the access link terminating on
   S3-1 LTP in the ODU Topology and that C-R3 is attached to the access
   link terminating on S6-2 LTP in the ODU Topology.

   Based on the assumption 1) in section 1.1, MDSC would then request
   the Transport PNC to setup an ODU2 (Transit Segment) Tunnel between
   S3-1 and S6-2 LTPs:

   o  Source and Destination TTPs are not specified (since it is a
      Transit Tunnel)

   o  Ingress and egress points are indicated in the explicit-route-
      objects of the primary path:

       o The first element of the explicit-route-objects references the
          access link terminating on S3-1 LTP

       o Last element of the explicit-route-objects references the
          access link terminating on S6-2 LTP

   The configuration of the timeslots used by the ODU2 connection within
   the transport network domain (i.e., on the internal links) is a
   matter of the Transport PNC and its interactions with the physical
   network elements and therefore is outside the scope of this document.

   However, the configuration of the timeslots used by the ODU2
   connection at the edge of the transport network domain (i.e., on the


Busi, King et al.       Expires April 30, 2018                 [Page 8]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


   access links) needs to take into account not only the timeslots
   available on the physical nodes at the edge of the transport network
   domain (e.g., S3 and S6) but also on the devices, outside of the
   transport network domain, connected through these access links (e.g.,
   C-R1 and C-R3).

   Based on the assumption 2) in section 1.1, the MDSC, when requesting
   the Transport PNC to setup the (Transit Segment) ODU2 Tunnel, it
   would also configure the timeslots to be used on the access links.
   The MDSC can know the timeslots which are available on the edge OTN
   Node (e.g., S3 and S6) from the OTN Topology information exposed by
   the Transport PNC at the MPI as well as the timeslots which are
   available on the devices outside of the transport network domain
   (e.g., C-R1 and C-R3), by means which are outside the scope of this
   document.

   The Transport PNC performs path computation and sets up the ODU2
   cross-connections within the physical nodes S3, S5 and S6, as shown
   in section 4.3.1 of [TNBI-UseCases].

   The Transport PNC reports the status of the created ODU2 (Transit
   Segment) Tunnel and its path within the ODU Topology as shown in
   Figure 2 below:


























Busi, King et al.       Expires April 30, 2018                 [Page 9]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


                   ..................................
                   :                                :
                   :   ODU Abstract Topology @ MPI  :
                   :                                :
                   :        +----+        +----+    :
                   :        |    |        |    |    :
                   :        | S1 |--------| S2 |- - - - -(C-R4)
                   :        +----+        +----+    :
                   :         /               |      :
                   :        /                |      :
                   :    +----+   +----+      |      :
                   :    |    |   |    |      |      :
         (C-R1)- - - - -  S3 |---| S4 |      |      :
                   :S3-1 <<==+   +----+      |      :
                   :       =        \        |      :
                   :       = \       \       |      :
                   :       == ---+    \      |      :
                   :        =    |     \     |      :
                   :        = S5 |      \    |      :
                   :        == --+       \   |      :
         (C-R2)- - - - -     =  \         \  |      :
                   :S6-1 \ / =   \         \ |      :
                   :    +--- =   +----+   +----+    :
                   :    |    =   |    |   |    |    :
                   :    | S6 = --| S7 |---| S8 |- - - - -(C-R5)
                   :    +--- =   +----+   +----+    :
                   :     /   =                      :
         (C-R3)- - - - -  <<==                      :
                   :S6-2                            :
                   :................................:

                        Figure 2 ODU2 Transit Tunnel

3.2.2. EPL over ODU Service

   As described in section 4.3.2 of [TNBI-UseCases], the MDSC needs to
   setup an EPL service between C-R1 and C-R3 supported by an ODU2 end-
   to-end connection between S3 and S6.

   As described in section 3.1.1 above, it is not clear in this case how
   the Ethernet access links between the transport network and the IP
   router, are reported by the PNC to the MDSC.

   If the 10GE physical links are not reported as ODU links within the
   ODU topology information, described in section 3.1.1 above, than the
   MDSC will not have sufficient information to know that C-R1 and C-R3
   are attached to nodes S3 and S6.


Busi, King et al.       Expires April 30, 2018                [Page 10]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


   Assuming that the MDSC knows how C-R1 and C-R3 are attached to the
   transport network, the MDSC would request the Transport PNC to setup
   an ODU2 end-to-end Tunnel between S3 and S6.

   This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In case
   nodes S3 and S6 support more than one TTP, the MDSC should decide
   which TTP to use.

   As discussed in section 3.1.1, depending on the different hardware
   implementations of the physical nodes S3 and S6, not all the access
   links can be connected to all the TTPs. The MDSC should therefore not
   only select the optimal TTP but also a TTP that would allow the
   Tunnel to be used by the service.

   It is assumed that in case node S3 or node S6 supports only one TTP,
   this TTP can be accessed by all the access links.

   Once the ODU2 Tunnel setup has been requested, unless there is a one-
   to-one relationship between the S3 and S6 TTPs and the Ethernet
   access links toward C-R1 and C-R3 (as in the case, described in
   section 3.1.1, where the Ethernet access links reside on
   different/dedicated access card such that the ODU2 tunnel can only
   carry the Ethernet traffic from the only Ethernet access link on the
   same access card where the ODU2 tunnel is terminated), the MDSC also
   needs to request the setup of an EPL service from the access links on
   S3 and S6, attached to C-R1 and C-R3, and this ODU2 Tunnel.

3.2.3. OTN Client Private Line Service

   As described in section 3.1.1 above, it is not clear in this case how
   the access links (e.g., the STM-N access links) between the transport
   network and the IP router, are reported by the PNC to the MDSC.

   As described in section 4.3.3 of [TNBI-UseCases], the MDSC needs to
   setup an STM-64 Private Link service between C-R1 and C-R3 supported
   by an ODU2 end-to-end connection between S3 and S6.

   The same issues, as described in section 3.2.2, apply here:

   o  the MDSC needs to understand that C-R1 and C-R3 are connected,
      thought STM-64 access links, with S3 and S6

   o  the MDSC needs to understand which TTPs in S3 and S6 can be
      accessed by these access links

   o  the MDSC needs to configure the private line service from these
      access links through the ODU2 tunnel


Busi, King et al.       Expires April 30, 2018                [Page 11]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


3.2.4. EVPL over ODU Service

   As described in section 3.1.1 above, it is not clear in this case how
   the Ethernet access links between the transport network and the IP
   router, are reported by the PNC to the MDSC.

   As described in section 4.3.3 of [TNBI-UseCases], the MDSC needs to
   setup EVPL services between C-R1 and C-R3, as well as between C-R1
   and C-R4, supported by ODU0 end-to-end connections between S3 and S6
   as well as between S3 and S2.

   The same issues, as described in section 3.2.2, apply here:

   o  the MDSC needs to understand that C-R1, C-R3 and C-R4 are
      connected, thought the Ethernet access links, with S3, S6 and S2

   o  the MDSC needs to understand which TTPs in S3, S6 and S2 can be
      accessed by these access links

   o  the MDSC needs to configure the EVPL services from these access
      links through the ODU0 tunnels

   In addition, the MDSC needs to get the information that the access
   links on S3, S6 and S2 are capable to support EVPL (rather than just
   EPL) as well as to coordinate the VLAN configuration, for each EVPL
   service, on these access links (this is a similar issue as the
   timeslot configuration on access links discussed in section 3.2.1
   below).

4. Topology Abstraction: detailed JSON examples

4.1. ODU White Topology Abstraction

   Section 3.1.1 describes how the Transport PNC can provide a white
   topology abstraction to the MDSC via the MPI. Figure 1 is an example
   of such ODU Topology.

   This section provides the detailed JSON code describing how this ODU
   Topology is reported by the PNC, using the [TE-TOPO] and [OTN-TOPO]
   YANG models at the MPI.

   JSON code "use-case-1-topology-01.json" has been provided at in the
   appendix of this document.






Busi, King et al.       Expires April 30, 2018                [Page 12]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


5. Service Configuration: detailed JSON examples

5.1. ODU Transit Service

   Section 3.2.1 describes how the MDSC can request a Transport PNC, via
   the MPI, to setup an ODU2 transit service over an ODU Topology
   described in section 3.1.1.

   This section provides the detailed JSON code describing how the setup
   of this ODU2 transit service can be requested by the MDSC, using the
   [TE-TUNNEL] and [OTN-TUNNEL] YANG models at the MPI.

   JSON code "use-case-1-odu2-service-01.json" has been provided at in
   the appendix of this document.

6. Security Considerations

   This section is for further study

7. IANA Considerations

   This document requires no IANA actions.

8. Conclusions

   This section is for further study

9. References

9.1. Normative References

   [TNBI-UseCases]   Busi, I., King, D. et al, "Transport Northbound
             Interface Applicability Statement and Use Cases", draft-
             ietf-ccamp-transport-nbi-use-cases, work in progress.

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

   [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport
             Network Topology", draft-ietf-ccamp-otn-topo-yang, work in
             progress.

   [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
             Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
             te, work in progress.




Busi, King et al.       Expires April 30, 2018                [Page 13]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


   [OTN-TUNNEL]   Zheng, H. et al., "OTN Tunnel YANG Model", draft-ietf-
             ccamp-otn-tunnel-model, work in progress.

9.2. Informative References

   [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
             Abstraction and Control of Traffic Engineered Networks",
             draft-zhang-teas-actn-yang, work in progress.

   [I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies",
             draft-ietf-i2rs-yang-network-topo, work in progress.

10. Acknowledgments

   The authors would like to thank all members of the Transport NBI
   Design Team involved in the definition of use cases, gap analysis and
   guidelines for using the IETF YANG models at the Northbound Interface
   (NBI) of a Transport SDN Controller.

   The authors would like to thank Xian Zhang, Anurag Sharma, Sergio
   Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar
   Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated
   the work on gap analysis for transport NBI and having provided
   foundations work for the development of this document.

   The authors would like to thank the authors of the TE Topology and
   Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor
   Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their
   support in addressing any gap identified during the analysis work.

   This document was prepared using 2-Word-v2.0.template.dot.


















Busi, King et al.       Expires April 30, 2018                [Page 14]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


Appendix A.                 Validating a JSON fragment against a YANG Model

   The objective is to have a tool that allows validating whether a
   piece of JSON code is compliant with a YANG model without using a
   client/server.

A.1. DSDL-based approach

   The idea is to generate a JSON driver file (JTOX) from YANG, then use
   it to translate JSON to XML and validate it against the DSDL schemas,
   as shown in Figure 3.

   Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson

                           (2)
               YANG-module ---> DSDL-schemas (RNG,SCH,DSRL)
                      |                  |
                      | (1)              |
                      |                  |
      Config/state  JTOX-file            | (4)
             \        |                  |
              \       |                  |
               \      V                  V
      JSON-file------------> XML-file ----------------> Output
                 (3)

           Figure 3 - DSDL-based approach for JSON code validation

   In order to allow the use of comments following the convention
   defined in section 2 without impacting the validation process, these
   comments will be automatically removed from the JSON-file that will
   be validate.

A.2. Why not using a XSD-based approach

   This approach has been analyzed and discarded because no longer
   supported by pyang.

   The idea is to convert YANG to XSD, JSON to XML and validate it
   against the XSD, as shown in Figure 4:









Busi, King et al.       Expires April 30, 2018                [Page 15]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


                     (1)
         YANG-module ---> XSD-schema - \       (3)
                                        +--> Validation
         JSON-file------> XML-file ----/
                     (2)

           Figure 4 - XSD-based approach for JSON code validation

   The pyang support for the XSD output format was deprecated in 1.5 and
   removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG
   1.1 so the process shown in Figure 4 will stop just at step (1).

A.3. JSON Code: use-case-1-topology-01.json

   The JSON code for this use case is currently located on GitHub at:

   https://github.com/danielkinguk/transport-nbi/blob/master/Internet-
   Drafts/Use-Case-1-Analysis/use-case-1-topology-01.json

A.4. JSON Code: use-case-1-topology-01.json

   The JSON code for this use case is currently located on GitHub at:

   https://github.com/danielkinguk/transport-nbi/blob/master/Internet-
   Drafts/Use-Case-1-Analysis/use-case-1-odu2-service-01.json
























Busi, King et al.       Expires April 30, 2018                [Page 16]


Internet-Draft        T-NBI Use Case 1 Analysis            October 2017


   Authors' Addresses

   Italo Busi (Editor)
   Huawei
   Email: italo.busi@huawei.com



   Daniel King (Editor)
   Lancaster University
   Email: d.king@lancaster.ac.uk


   Sergio Belotti
   Nokia
   Email: sergio.belotti@nokia.com


   Gianmarco Bruno
   Ericsson
   Email: gianmarco.bruno@ericsson.com


   Carlo Perocchio
   Ericsson
   Email: carlo.perocchio@ericsson.com























Busi, King et al.       Expires April 30, 2018                [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/