]> Huawei Technologies

italo.busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com

Nokia

sergio.belotti@nokia.com

Routing Common Control and Measurement Plane next generation unicorn sparkling distributed ledger This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction describes key use cases, where a client needs to request underlying Software-Defined Network (SDN) controllers for path computation. In some of these use cases, the underlying SDN controller can control a single-layer optical technologies, including Optical Transport Network (OTN), Wavelength Switched Optical Networks (WSON), Flexi-grid, and multi-layer Optical network. This document defines YANG data models, which augment the generic Path Computation RPC defined in , with technology-specific augmentations required to request path computation to an underlying Optical SDN controller. These models allow a client to delegate path computation tasks to the underlying Optical SDN controller without having to obtain optical-layer information from the controller and performing feasible path computation itself. This is especially helpful in cases where computing optically-feasible paths require knowledge of physical-layer states, such as optical impairments, which are visible only to the Optical controller.

Terminology and Notations Refer to and for the key terms used in this document. The following terms are defined in and are not redefined here:

• client
• server
• augment
• data model
• data node

The following terms are defined in and are not redefined here:

• configuration data
• state data

The terminology for describing YANG data models is found in .

Tree Diagram A simplified graphical representation of the data model is used in of this document. The meaning of the symbols in these diagrams is defined in .

Prefix 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 . Prefixes and corresponding YANG modules

Prefix	YANG module	Reference
l0-types	ietf-layer0-types	[RFCZZZZ]
te	ietf-te	[RFCKKKK]
tepc	ietf-te-path-computation	[RFCYYYY]
wdm-pc	ietf-wdm-path-computation	RFCXXXX

RFC Editor Note: Please replace XXXX with the RFC number assigned to this document. Please replace ZZZZ with the RFC number assigned to . Please replace KKKK with the RFC number assigned to . Please replace YYYY with the RFC number assigned to . Please remove this note.

YANG Data Models for WDM Path Computation

YANG Models Overview The YANG data models for requesting WDM path computation are defined as augmentations of the generic Path Computation RPC defined in , as shown in .

Relationship between WDM and TE path computation models

The entities and Traffic Engineering (TE) attributes, such as requested path and tunnel attributes, defined in , are still applicable when requesting WDM path computation and the models defined in this document only specifies the additional technology-specific attributes/information, using the attributes defined in .

Attributes Augmentation The common characteristics for layer 0 (WSON and Flexi-grid) path computation are under definition in and re-used in the ietf-wdm-path-computation YANG models.

Bandwidth Augmentation As described in Section 4.2 of , there is some overlap between bandwidth and label in layer0. The WSON and flexi-grid label resource information described in , is sufficient to describe also the spectrum resources within WSON and flexi-grid networks. Therefore, the model does not define any augmentation for the te-bandwidth containers defined in .

Label Augmentations The models augment all the occurrences of the label-restriction list with WSON and Flexi-grid technology-specific attributes using the l0-label-range-info and flexi-grid-label-range-info groupings defined in . Moreover, the models augment all the occurrences of the te-label container with the WSON, Flexi-grid and OTN technology-specific attributes using the wson-label-start-end, wson-label-hop, wson-label-step, flexi-grid-label-start-end, flexi-grid-label-hop and flexi-grid-label-step defined in .

WDM Path Computation Tree Diagrams below shows the tree diagram of the YANG data model defined in module ietf-wdm-path-computation.yang.

WDM path computation tree diagram

YANG Models for WDM Path Computation

WDM path computation YANG module WG List: Editor: Aihua Guo Editor: Italo Busi Editor: Sergio Belotti "; description "This module defines a model for requesting WDM Path Computation. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2022 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 Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision "2024-02-29" { description "Initial version."; reference "RFC XXXX: YANG Data Models for requesting Path Computation in Optical Networks."; // RFC Ed.: replace XXXX with actual RFC number, update date // information and remove this note } /* * Data nodes */ /* * Augment tunnel attributes */ augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:tunnel-attributes" { description "Augment with WDM tunnel-specific constraints."; uses wdm-tnl:wdm-constraint; } /* * Augment path computation request */ augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:optimizations/tepc:algorithm/" + "tepc:metric/tepc:optimization-metric/" + "tepc:explicit-route-exclude-objects/" + "tepc:route-object-exclude-object/tepc:type/" + "tepc:numbered-node-hop" { description "Augment with transceiver configurations."; uses wdm-tnl:path-transceiver-config; } //??? augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:optimizations/tepc:algorithm/" + "tepc:metric/tepc:optimization-metric/" + "tepc:explicit-route-exclude-objects/" + "tepc:route-object-exclude-object/tepc:type" { description "Augment the route hop for the optimization of the explicit route objects excluded by the path computation of the requested path."; case oms-element { leaf oms-element-uid { type string; description "The unique id of the OMS element."; } description "The OMS element route hop type"; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:optimizations/tepc:algorithm/" + "tepc:metric/tepc:optimization-metric/" + "tepc:explicit-route-include-objects/" + "tepc:route-object-include-object/tepc:type/" + "tepc:numbered-node-hop" { description "Augment with transceiver configurations."; uses wdm-tnl:path-transceiver-config; } //??? augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:optimizations/tepc:algorithm/" + "tepc:metric/tepc:optimization-metric/" + "tepc:explicit-route-include-objects/" + "tepc:route-object-include-object/tepc:type" { description "Augment the route hop for the optimization of the explicit route objects included by the path computation of the requested path."; case oms-element { leaf oms-element-uid { type string; description "The unique id of the OMS element."; } description "The OMS element route hop type"; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:explicit-route-objects/" + "tepc:route-object-exclude-always/tepc:type/" + "tepc:numbered-node-hop" { description "Augment with transceiver configurations."; uses wdm-tnl:path-transceiver-config; } //??? augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:explicit-route-objects/" + "tepc:route-object-exclude-always/tepc:type" { description "Augment the route hop for the explicit route objects always excluded by the path computation of the requested path."; case oms-element { leaf oms-element-uid { type string; description "The unique id of the OMS element."; } description "The OMS element route hop type"; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:explicit-route-objects/" + "tepc:route-object-include-exclude/tepc:type/" + "tepc:numbered-node-hop" { description "Augment with transceiver configurations."; uses wdm-tnl:path-transceiver-config; } //??? augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:explicit-route-objects/" + "tepc:route-object-include-exclude/tepc:type" { description "Augment the route hop for the explicit route objects included or excluded by the path computation of the requested path."; case oms-element { leaf oms-element-uid { type string; description "The unique id of the OMS element."; } description "The OMS element route hop type"; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:synchronization/tepc:exclude-objects/tepc:excludes/" + "tepc:type/tepc:numbered-node-hop" { description "Augment with transceiver configurations."; uses wdm-tnl:path-transceiver-config; } //??? augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:synchronization/tepc:exclude-objects/tepc:excludes/" + "tepc:type" { description "Augment the route hop for the explicit route objects to always exclude from synchronized path computation."; case oms-element { leaf oms-element-uid { type string; description "The unique id of the OMS element."; } description "The OMS element route hop type"; } } /* * Augment path computation response */ augment "/te:tunnels-path-compute/te:output/" + "te:path-compute-result/tepc:response/" + "tepc:computed-paths-properties/" + "tepc:computed-path-properties/tepc:path-properties" { description "Augment with additional properties for WDM paths."; uses l0-types:l0-path-properties; } augment "/te:tunnels-path-compute/te:output/" + "te:path-compute-result/tepc:response/" + "tepc:computed-paths-properties/" + "tepc:computed-path-properties/tepc:path-properties/" + "tepc:path-route-objects/tepc:path-route-object/" + "tepc:type/tepc:numbered-node-hop" { description "Augment with transceiver configurations."; uses wdm-tnl:path-transceiver-config; } //??? augment "/te:tunnels-path-compute/te:output/" + "te:path-compute-result/tepc:response/" + "tepc:computed-paths-properties/" + "tepc:computed-path-properties/tepc:path-properties/" + "tepc:path-route-objects/tepc:path-route-object/" + "tepc:type" { description "Augment the route hop for the route object of the computed path."; case oms-element { leaf oms-element-uid { type string; description "The unique id of the OMS element."; } description "The OMS element route hop type"; } } /* * Augment TE label range information */ augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-in-segment/" + "tepc:label-restrictions/tepc:label-restriction" { description "Augment TE label range information for the ingress segment of the requested path."; uses l0-types:wdm-label-range-info; } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-out-segment/" + "tepc:label-restrictions/tepc:label-restriction" { description "Augment TE label range information for the egress segment of the requested path."; uses l0-types:wdm-label-range-info; } /* * Augment TE label. */ augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:optimizations/tepc:algorithm/" + "tepc:metric/tepc:optimization-metric/" + "tepc:explicit-route-exclude-objects/" + "tepc:route-object-exclude-object/tepc:type/tepc:label/" + "tepc:label-hop/tepc:te-label/tepc:technology" { description "Augment TE label hop for the optimization of the explicit route objects excluded by the path computation of the requested path."; case wdm { uses l0-types:wdm-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:optimizations/tepc:algorithm/" + "tepc:metric/tepc:optimization-metric/" + "tepc:explicit-route-include-objects/" + "tepc:route-object-include-object/tepc:type/tepc:label/" + "tepc:label-hop/tepc:te-label/tepc:technology" { description "Augment TE label hop for the optimization of the explicit route objects included by the path computation of the requested path."; case wdm { uses l0-types:wdm-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:explicit-route-objects/" + "tepc:route-object-exclude-always/tepc:type/tepc:label/" + "tepc:label-hop/tepc:te-label/tepc:technology" { description "Augment TE label hop for the explicit route objects always excluded by the path computation of the requested path."; case wdm { uses l0-types:wdm-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:explicit-route-objects/" + "tepc:route-object-include-exclude/tepc:type/tepc:label/" + "tepc:label-hop/tepc:te-label/tepc:technology" { description "Augment TE label hop for the explicit route objects included or excluded by the path computation of the requested path."; case wdm { uses l0-types:wdm-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-in-segment/" + "tepc:label-restrictions/tepc:label-restriction/" + "tepc:label-start/tepc:te-label/tepc:technology" { description "Augment TE label range start for the ingress segment of the requested path."; case wdm { uses l0-types:wdm-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-in-segment/" + "tepc:label-restrictions/tepc:label-restriction/" + "tepc:label-end/tepc:te-label/tepc:technology" { description "Augment TE label range end for the ingress segment of the requested path."; case wdm { uses l0-types:wdm-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-in-segment/" + "tepc:label-restrictions/tepc:label-restriction/" + "tepc:label-step/tepc:technology" { description "Augment TE label range step for the ingress segment of the requested path."; case wdm { uses l0-types:wdm-label-step; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-out-segment/" + "tepc:label-restrictions/tepc:label-restriction/" + "tepc:label-start/tepc:te-label/tepc:technology" { description "Augment TE label range start for the egress segment of the requested path."; case wdm { uses l0-types:wdm-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-out-segment/" + "tepc:label-restrictions/tepc:label-restriction/" + "tepc:label-end/tepc:te-label/tepc:technology" { description "Augment TE label range end for the egress segment of the requested path."; case wdm { uses l0-types:wdm-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:path-request/tepc:path-out-segment/" + "tepc:label-restrictions/tepc:label-restriction/" + "tepc:label-step/tepc:technology" { description "Augment TE label range end for the egress segment of the requested path."; case wdm { uses l0-types:wdm-label-step; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "tepc:synchronization/tepc:exclude-objects/tepc:excludes/" + "tepc:type/tepc:label/tepc:label-hop/" + "tepc:te-label/tepc:technology" { description "Augment TE label hop for the explicit route objects to always exclude from synchronized path computation."; case wdm { uses l0-types:wdm-label-hop; } } augment "/te:tunnels-path-compute/te:output/" + "te:path-compute-result/tepc:response/" + "tepc:computed-paths-properties/" + "tepc:computed-path-properties/tepc:path-properties/" + "tepc:path-route-objects/tepc:path-route-object/" + "tepc:type/tepc:label/" + "tepc:label-hop/tepc:te-label/tepc:technology" { description "Augment TE label hop for the route object of the computed path."; case wdm { uses l0-types:wdm-label-hop; } } } ]]>

Manageability Considerations This document provides a method for requesting path computations for WSON and Flexi-Grid tunnels. Consideration of mechanisms to gather and collate information required for the path computations will be necessary. Furthermore, storing path computation requests and responses and triggering actions will also need to be carefully managed and secured. Future versions of this document will contain additional information.

Security Considerations The YANG module defined in this document will be accessed via the NETCONF protocol or RESTCONF protocol . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access to particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. Some of the RPC operations defined in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus essential to control access to these operations. Operations defined in this document, and their sensitivities and possible vulnerabilities, will be discussed further in future versions of this document.

IANA Considerations This document registers the following URIs in the "ns" subregistry within the "IETF XML registry" . This document registers the following YANG module in the "YANG Module Names" registry .

References Normative References Huawei Technologies Nokia Telefonica Google China Unicom There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. Nokia Huawei Nokia Orange Futurewei Technologies This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid. This document updates RFCs 3471 and 6205 by introducing a new label format. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. Informative References This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE). Huawei Technologies Futurewei Technologies Nokia This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. FiberCop Vodafone Huawei Old Dog Consulting Cisco This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture Samsung Huawei Technologies Futurewei Nokia Lancaster University ETRI CTTC This document provides a YANG data model for WSON TE tunnel. Naudit HPCN Universidad Autonoma de Madrid Old Dog Consulting Nokia Huawei Technologies Nokia Cisco This document defines a YANG model for managing flexi-grid optical tunnels (media-channels), complementing the information provided by the flexi-grid topology model. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA).

Change Log The initial YANG data model requesting path computation in optical networks was draft-gbb-ccamp-optical-path-computation-yang-00. This document included path computation request capabilities for WSON, Flexi-Grid and OTN technologies. However, it was proposed at IETF 113 (March 25, 2022) to split the initial document into separate documents for WDM (WSON and Flexi-Grid) and OTN technologies, as each technology may be developed and implemented separately. The WDM technology capabilities were kept in this document, and the OTN capabilities were moved into . Editors note, please remove this appendix before publication.

Acknowledgments The authors of this document would like to thank the authors of for having identified the gap and requirements to trigger this work. The authors of this document would also like to thank Young Lee, Haomian Zheng, Victor Lopex, Ricard Vilalta, Bin Yeong Yoon, Jorge E. Lopez de Vergara Mendez, Daniel Perdices Burrero, Oscar Gonzalez de Dios, Gabriele Galimberti, Zafar Ali, Daniel Michaud Vallinoto and Dhruv Dhody who have contributed to the development of path computation augmentations for WSON and Flexi-grid topology in earlier versions of and of . This document was prepared using kramdown.

Contributors Old Dog Consulting

daniel@olddog.co.uk