draft-ietf-ccamp-transport-nbi-app-statement-11.txt   draft-ietf-ccamp-transport-nbi-app-statement-12.txt 
CCAMP Working Group I. Busi CCAMP Working Group I. Busi
Internet Draft Huawei Internet Draft Huawei
Intended status: Informational D. King Intended status: Informational D. King
Old Dog Consulting Old Dog Consulting
H. Zheng H. Zheng
Huawei Huawei
Y. Xu Y. Xu
CAICT CAICT
Expires: January 8, 2021 July 7, 2020 Expires: July 2021 January 4, 2021
Transport Northbound Interface Applicability Statement Transport Northbound Interface Applicability Statement
draft-ietf-ccamp-transport-nbi-app-statement-11 draft-ietf-ccamp-transport-nbi-app-statement-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 8, 2021. This Internet-Draft will expire on July 4, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 5, line 26 skipping to change at page 5, line 26
The list of the IETF YANG models which are applicable to the ACTN The list of the IETF YANG models which are applicable to the ACTN
MPI can be found in [ACTN-YANG]. MPI can be found in [ACTN-YANG].
The Functional Requirements for the transport API as described in The Functional Requirements for the transport API as described in
the Optical Networking Foundation (ONF) document [ONF TR-527] have the Optical Networking Foundation (ONF) document [ONF TR-527] have
been taken as input for defining the reference scenarios analyzed in been taken as input for defining the reference scenarios analyzed in
this document. this document.
The analysis provided in this document confirms that the IETF YANG The analysis provided in this document confirms that the IETF YANG
models defined in [RFC8345], [TE-TOPO], [OTN-TOPO], [CLIENT-TOPO], models defined in [RFC8345], [RFC8795], [OTN-TOPO], [CLIENT-TOPO],
[TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL] and [CLIENT-SIGNAL] can be [TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL] and [CLIENT-SIGNAL] can be
used together to control a multi-domain OTN network to support used together to control a multi-domain OTN network to support
different types of multi-domain services, such as ODU transit different types of multi-domain services, such as ODU transit
services, Transparent client services and EPL/EVPL Ethernet services, Transparent client services and EPL/EVPL Ethernet
services, over a multi-domain OTN connection, satisfying also the services, over a multi-domain OTN connection, satisfying also the
requirements in [ONF TR-527]. requirements in [ONF TR-527].
2. Terminology 2. Terminology
Domain: A domain, as defined in [RFC4655], is "any collection of Domain: A domain, as defined in [RFC4655], is "any collection of
skipping to change at page 7, line 25 skipping to change at page 7, line 25
failures without the necessity to allocate network resources as failures without the necessity to allocate network resources as
required for dedicated 1+1 protection schemes. On the other hand, required for dedicated 1+1 protection schemes. On the other hand,
restoration times are typically longer than protection switching restoration times are typically longer than protection switching
times. times.
Service Model: As described in [RFC8309] it describes a service and Service Model: As described in [RFC8309] it describes a service and
the parameters of the service in a portable way that can be used the parameters of the service in a portable way that can be used
uniformly and independent of the equipment and operating uniformly and independent of the equipment and operating
environment. environment.
TE Link: As defined in [TE-TOPO], it is an element of a TE topology, TE Link: As defined in [RFC8795], it is an element of a TE topology,
presented as an edge on TE graph. presented as an edge on TE graph.
TE Tunnel: As defined in [TE-TUTORIAL], it is a connection-oriented TE Tunnel: As defined in [TE-TUTORIAL], it is a connection-oriented
service provided by a layer network of delivery of a client's data service provided by a layer network of delivery of a client's data
between source and destination tunnel termination points. between source and destination tunnel termination points.
TE Tunnel Segment: As defined in [TE-TUTORIAL], it is a part of a TE Tunnel Segment: As defined in [TE-TUTORIAL], it is a part of a
multi-domain TE tunnel that spans. multi-domain TE tunnel that spans.
TE Tunnel Hand-off: As defined in [TE-TUTORIAL], it is an access TE Tunnel Hand-off: As defined in [TE-TUTORIAL], it is an access
skipping to change at page 26, line 45 skipping to change at page 26, line 45
Section 5.3 describes how the protection scenarios can be deployed, Section 5.3 describes how the protection scenarios can be deployed,
including end-to-end protection and segment protection, for both including end-to-end protection and segment protection, for both
intra-domain and inter-domain scenario. intra-domain and inter-domain scenario.
5.1. YANG Models for Topology Abstraction 5.1. YANG Models for Topology Abstraction
This section analyses how each PNC can report its respective This section analyses how each PNC can report its respective
abstract topology to the MDSC, as described in section 4.2, using abstract topology to the MDSC, as described in section 4.2, using
the Topology YANG models, defined in [RFC8345], with the TE Topology the Topology YANG models, defined in [RFC8345], with the TE Topology
YANG augmentations, provided in [TE-TOPO], and the OTN YANG augmentations, provided in [RFC8795], and the OTN
technology-specific YANG augmentations, defined in [OTN-TOPO] or the technology-specific YANG augmentations, defined in [OTN-TOPO] or the
Ethernet client technology-specific YANG augmentations, defined in Ethernet client technology-specific YANG augmentations, defined in
[CLIENT-TOPO]. [CLIENT-TOPO].
As described in section 4.1, the OTU4 trails on inter-domain and As described in section 4.1, the OTU4 trails on inter-domain and
intra-domain physical links are pre-provisioned and therefore not intra-domain physical links are pre-provisioned and therefore not
exposed at the MPIs. Only the TE Links they support can be exposed exposed at the MPIs. Only the TE Links they support can be exposed
at the MPI, depending on the topology abstraction performed by the at the MPI, depending on the topology abstraction performed by the
PNC. PNC.
skipping to change at page 27, line 29 skipping to change at page 27, line 29
transparent client layers, defined in section 4.3.3 and in transparent client layers, defined in section 4.3.3 and in
[CLIENT-SIGNAL]. These links can also be multi-function access links [CLIENT-SIGNAL]. These links can also be multi-function access links
that can be configured as a transparent client physical links (e.g., that can be configured as a transparent client physical links (e.g.,
STM-64 physical link) or as an OTUk trail. STM-64 physical link) or as an OTUk trail.
In order to support the EPL and EVPL services, described in sections In order to support the EPL and EVPL services, described in sections
4.3.2 and 4.3.4, the access links, which are capable of being 4.3.2 and 4.3.4, the access links, which are capable of being
configured as Ethernet physical links, are reported by each PNC configured as Ethernet physical links, are reported by each PNC
within its respective Ethernet abstract topology, using the Topology within its respective Ethernet abstract topology, using the Topology
YANG models, defined in [RFC8345], with the TE Topology YANG YANG models, defined in [RFC8345], with the TE Topology YANG
augmentations, defined in [TE-TOPO], and the Ethernet client augmentations, defined in [RFC8795], and the Ethernet client
technology-specific YANG augmentations, defined in [CLIENT-TOPO]. technology-specific YANG augmentations, defined in [CLIENT-TOPO].
These links can also be multi-function access links that can be These links can also be multi-function access links that can be
configured as an Ethernet physical link, an OTUk trail, or as a configured as an Ethernet physical link, an OTUk trail, or as a
transparent client physical links (e.g., STM-64 physical link). In transparent client physical links (e.g., STM-64 physical link). In
this case, these physical access links are represented in both the this case, these physical access links are represented in both the
OTN and Ethernet abstract topologies. OTN and Ethernet abstract topologies.
The PNC reports the capabilities of the access or inter-domain link The PNC reports the capabilities of the access or inter-domain link
ends it can control. It is the MDSC responsibility to request ends it can control. It is the MDSC responsibility to request
configuration of these links matching the capabilities of both link configuration of these links matching the capabilities of both link
skipping to change at page 32, line 18 skipping to change at page 32, line 18
S3-1 AN1-1 AN1-1 S3-1 AN1-1 AN1-1
S6-1 AN1-8 S6-1 AN1-8
S6-2 AN1-2 S6-2 AN1-2
S6-3 AN1-3 S6-3 AN1-3
S7-3 AN1-4 S7-3 AN1-4
S8-4 AN1-5 S8-4 AN1-5
S8-5 AN1-6 S8-5 AN1-6
Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn- Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn-
topology.json") describing how the MPI1 ODU Topology is reported by topology.json") describing how the MPI1 ODU Topology is reported by
the PNC1, using the [RFC8345], [TE-TOPO] and [OTN-TOPO] YANG models, the PNC1, using the [RFC8345], [RFC8795] and [OTN-TOPO] YANG models,
at MPI1. at MPI1.
Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth- Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth-
topology.json") describing how the MPI1 ETH Topology is reported by topology.json") describing how the MPI1 ETH Topology is reported by
the PNC1, using the [RFC8345], [TE-TOPO] and [CLIENT-TOPO] YANG the PNC1, using the [RFC8345], [RFC8795] and [CLIENT-TOPO] YANG
models, at MPI1. models, at MPI1.
It is worth noting that this JSON code example does not provide all It is worth noting that this JSON code example does not provide all
the attributes defined in the relevant YANG models, including: the attributes defined in the relevant YANG models, including:
o YANG attributes which are outside the scope of this document are o YANG attributes which are outside the scope of this document are
not shown; not shown;
o The attributes describing the set of label values that are o The attributes describing the set of label values that are
available at the inter-domain links (label-restriction container) available at the inter-domain links (label-restriction container)
skipping to change at page 34, line 16 skipping to change at page 34, line 16
are available to carry client signals (e.g., Ethernet or STM-N) over are available to carry client signals (e.g., Ethernet or STM-N) over
OTN in the TTPs within the MPI3 OTN Topology. OTN in the TTPs within the MPI3 OTN Topology.
5.1.4. Multi-domain Topology Merging 5.1.4. Multi-domain Topology Merging
MDSC does not have any knowledge of the topologies of each domain MDSC does not have any knowledge of the topologies of each domain
until each PNC reports its own abstract topologies, so the MDSC until each PNC reports its own abstract topologies, so the MDSC
needs to merge these abstract topologies, provided by different needs to merge these abstract topologies, provided by different
PNCs, to build its own topology view of the multi-domain network PNCs, to build its own topology view of the multi-domain network
(MDSC multi-domain native topology), as described in section 4.3 of (MDSC multi-domain native topology), as described in section 4.3 of
[TE-TOPO]. [RFC8795].
The topology of each domain may be in an abstracted shape (refer to The topology of each domain may be in an abstracted shape (refer to
section 5.2 of [RFC8453] for a different level of abstraction), section 5.2 of [RFC8453] for a different level of abstraction),
while the inter-domain link information must be complete and fully while the inter-domain link information must be complete and fully
configured by the MDSC. configured by the MDSC.
The inter-domain link information is reported to the MDSC by the two The inter-domain link information is reported to the MDSC by the two
PNCs, controlling the two ends of the inter-domain link. PNCs, controlling the two ends of the inter-domain link.
The MDSC needs to know how to merge these inter-domain links. One The MDSC needs to know how to merge these inter-domain links. One
possibility is to use the plug-id information, defined in [TE-TOPO]: possibility is to use the plug-id information, defined in [RFC8795]:
two inter-domain TE links, within two different MPI abstract two inter-domain TE links, within two different MPI abstract
topologies, terminating on two LTPs reporting the same plug-id value topologies, terminating on two LTPs reporting the same plug-id value
can be merged as a single intra-domain link, within any MDSC native can be merged as a single intra-domain link, within any MDSC native
topology. topology.
The value of the reported plug-id information can be either assigned The value of the reported plug-id information can be either assigned
by a central network authority and configured within the two PNC by a central network authority and configured within the two PNC
domains. Alternatively, it may be discovered using an automatic domains. Alternatively, it may be discovered using an automatic
discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]).
skipping to change at page 40, line 5 skipping to change at page 40, line 5
implementation. implementation.
However, the configuration of the timeslots used by the ODU2 However, the configuration of the timeslots used by the ODU2
connection at the transport network domain boundaries (e.g., on the connection at the transport network domain boundaries (e.g., on the
inter-domain links) needs to take into account the timeslots inter-domain links) needs to take into account the timeslots
available on physical nodes belonging to different PNC domains available on physical nodes belonging to different PNC domains
(e.g., on node S2 within PNC1 domain and node S31 within PNC3 (e.g., on node S2 within PNC1 domain and node S31 within PNC3
domain). Each PNC provides to the MDSC, at the MPI, the list of domain). Each PNC provides to the MDSC, at the MPI, the list of
available timeslots on the inter-domain links using the TE Topology available timeslots on the inter-domain links using the TE Topology
YANG model and OTN Topology augmentation. The TE Topology YANG model YANG model and OTN Topology augmentation. The TE Topology YANG model
in [TE-TOPO] is being updated to report the label set information. in [RFC8795] is being updated to report the label set information.
See section 1.7 of [TE-TUTORIAL] for more details. See section 1.7 of [TE-TUTORIAL] for more details.
The MDSC, when coordinating the setup of a multi-domain ODU The MDSC, when coordinating the setup of a multi-domain ODU
connection, also configures the data plane resources (i.e., the list connection, also configures the data plane resources (i.e., the list
of timeslots and the TPN) to be used on the inter-domain links. The of timeslots and the TPN) to be used on the inter-domain links. The
MDSC can know the timeslots which are available on the physical OTN MDSC can know the timeslots which are available on the physical OTN
nodes terminating the inter-domain links (e.g., S2 and S31) from the nodes terminating the inter-domain links (e.g., S2 and S31) from the
OTN Topology information exposed, at the MPIs, by the PNCs OTN Topology information exposed, at the MPIs, by the PNCs
controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling
the physical nodes S2 and S31 respectively). the physical nodes S2 and S31 respectively).
skipping to change at page 53, line 35 skipping to change at page 53, line 35
[RFC7926] Farrel, A. et al., "Problem Statement and Architecture for [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic- Information Exchange between Interconnected Traffic-
Engineered Networks", BCP 206, RFC 7926, July 2016. Engineered Networks", BCP 206, RFC 7926, July 2016.
[RFC8345] Clemm, A.,Medved, J. et al., "A Yang Data Model for [RFC8345] Clemm, A.,Medved, J. et al., "A Yang Data Model for
Network Topologies", RFC8345, March 2018. Network Topologies", RFC8345, March 2018.
[RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction
and Control of TE Networks (ACTN)", RFC8453, August 2018. and Control of TE Networks (ACTN)", RFC8453, August 2018.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795, DOI
10.17487/RFC8795, August 2020, <https://www.rfc-
editor.org/info/rfc8795>.
[ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for
the optical transport network", June 2016. the optical transport network", June 2016.
[ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic
protection switching - Linear trail and subnetwork protection switching - Linear trail and subnetwork
protection", May 2014. protection", May 2014.
[ITU-T G.873.1] ITU-T Recommendation G.873.1 (10/17), "Optical [ITU-T G.873.1] ITU-T Recommendation G.873.1 (10/17), "Optical
transport network (OTN): Linear protection", October 2017. transport network (OTN): Linear protection", October 2017.
[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 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical
Transport Network Topology", draft-ietf-ccamp-otn-topo- Transport Network Topology", draft-ietf-ccamp-otn-topo-
yang, work in progress. yang, work in progress.
[CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer
Topology", draft-zheng-ccamp-client-topo-yang, work in Topology", draft-zheng-ccamp-client-topo-yang, work in
progress. progress.
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
skipping to change at page 55, line 8 skipping to change at page 55, line 11
[RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309,
January 2018. January 2018.
[RFC8341] Bierman, A., Bjorklund, M., "Network Configuration Access [RFC8341] Bierman, A., Bjorklund, M., "Network Configuration Access
Control Model", RFC 8341, March 2018. Control Model", RFC 8341, March 2018.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018. Version 1.3", RFC 8446, August 2018.
[RFC8792] Watsen, K. et al., "Handling Long Lines in Artwork in
Internet-Drafts and RFCs", RFC8792, 10.17487/8792, June
2020, <https://www.rfc-editor.org/info/rfc8792>.
[ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
Abstraction and Control of Traffic Engineered Networks", Abstraction and Control of Traffic Engineered Networks",
draft-zhang-teas-actn-yang, work in progress. draft-zhang-teas-actn-yang, work in progress.
[RFC8792] Watsen, K. et al., "Handling Long Lines in Artwork in
Internet-Drafts and RFCs", RFC8792, 10.17487/8792,
June 2020, <https://www.rfc-editor.org/info/rfc8792>.
[TE-TUTORIAL] Bryskin, I. et al., "TE Topology and Tunnel Modeling [TE-TUTORIAL] Bryskin, I. et al., "TE Topology and Tunnel Modeling
for Transport Networks", draft-ietf-teas-te-topo-and- for Transport Networks", draft-ietf-teas-te-topo-and-
tunnel-modeling, work in progress tunnel-modeling, work in progress
[ONF TR-527] ONF Technical Recommendation TR-527, "Functional [ONF TR-527] ONF Technical Recommendation TR-527, "Functional
Requirements for Transport API", June 2016. Requirements for Transport API", June 2016.
[MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration [MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration
(LSO): Reference Architecture and Framework", Technical (LSO): Reference Architecture and Framework", Technical
Specification MEF 55, March 2016, Specification MEF 55, March 2016,
skipping to change at page 55, line 43 skipping to change at page 55, line 46
and guidelines for using the IETF YANG models at the Northbound and guidelines for using the IETF YANG models at the Northbound
Interface (NBI) of a Transport SDN Controller. Interface (NBI) of a Transport SDN Controller.
The authors would like to thank Xian Zhang, Anurag Sharma, Sergio The authors would like to thank Xian Zhang, Anurag Sharma, Sergio
Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar
Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated
the work on gap analysis for transport NBI and having provided the work on gap analysis for transport NBI and having provided
foundations work for the development of this document. foundations work for the development of this document.
The authors would like to thank the authors of the TE Topology and The authors would like to thank the authors of the TE Topology and
Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular, Igor Tunnel YANG models [RFC8795] and [TE-TUNNEL], in particular, Igor
Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their
support in addressing any gap identified during the analysis work. support in addressing any gap identified during the analysis work.
The authors would like to thank Henry Yu and Aihua Guo for their The authors would like to thank Henry Yu and Aihua Guo for their
input and review of the URIs structures used within the JSON code input and review of the URIs structures used within the JSON code
examples. examples.
This work was supported in part by the European Commission funded This work was supported in part by the European Commission funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).
skipping to change at page 60, line 8 skipping to change at page 60, line 8
Figure 9 - XSD-based approach for JSON code validation Figure 9 - XSD-based approach for JSON code validation
The pyang support for the XSD output format was deprecated in 1.5 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 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 9 will stop just at step YANG 1.1 so the process shown in Figure 9 will stop just at step
(1). (1).
Appendix B. Detailed JSON Examples Appendix B. Detailed JSON Examples
The JSON code examples provided in this appendix have been validated The JSON code examples provided in this appendix have been validated
using the tools in Appendix A and folded using the tool in [RFC- using the tools in Appendix A and folded using the tool in
FOLD]. [RFC8792].
B.1. JSON Examples for Topology Abstractions B.1. JSON Examples for Topology Abstractions
B.1.1. JSON Code: mpi1-otn-topology.json B.1.1. JSON Code: mpi1-otn-topology.json
This is the JSON code reporting the OTN Topology @ MPI1: This is the JSON code reporting the OTN Topology @ MPI1:
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========
{ {
 End of changes. 19 change blocks. 
23 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/