Addition of references to NG.126 (#3134)

Co-authored-by: collivier <ollivier.cedric@gmail.com>

doc/ref_arch/openstack/chapters/chapter01.rst

@@ -6,7 +6,8 @@ Overview
 
 This Reference Architecture is focussed on OpenStack as the Virtualised
 Infrastructure Manager (VIM) chosen based on the criteria laid out in
-the Reference Model :doc:`ref_model:chapters/chapter01`.
+the Cloud Infrastructure Reference Model :cite:p:`refmodel`
+(referred to as "Reference Model" or "RM" in the document).
 OpenStack :cite:p:`openstack` has the advantage of being a
 mature and widely accepted open-source technology; a strong ecosystem of
 vendors that support it, the OpenInfra Foundation for managing the

doc/ref_arch/openstack/chapters/chapter02.rst

@@ -8,7 +8,8 @@ for implementation.
 Reference Model Requirements
 ----------------------------
 
-The tables below contain the requirements from the Reference Model to
+The tables below contain the requirements from the Reference Model
+:cite:p:`refmodel` to
 cover the Basic and High-Performance profiles.
 
 To ensure alignment with the infrastructure profile catalogue, the
@@ -92,8 +93,8 @@ Cloud Infrastructure Software Profile Requirements for Compute
      - Must support
      - :ref:`chapters/chapter04:consumable infrastructure resources and services`
 
-[*] Defined in the .bronze configuration in
-:ref:`ref_model:chapters/chapter04:storage extensions`
+[*] Defined in the .bronze configuration in "Storage extensions"
+in :cite:p:`refmodel`.
 
 
 Cloud Infrastructure Software Profile Extensions Requirements for Compute

doc/ref_arch/openstack/chapters/chapter03.rst

@@ -111,14 +111,14 @@ NUMA alignment, and SMT.
 
 The configuration of the virtual resources will depend on the software
 and hardware profiles and the flavour (resource sizing) needed to host
-VNF components. Profiles are defined in the
-:ref:`ref_model:chapters/chapter02:profiles, profile extensions & flavours`.
+VNF components. Profiles are defined in "Profiles, Profile Extensions
+& Flavours" in :cite:p:`refmodel`.
 
 Virtual Storage
 ~~~~~~~~~~~~~~~
 
-The Reference Model
-:ref:`ref_model:chapters/chapter03:storage for tenant consumption`
+In the Reference Model :cite:p:`refmodel`, the
+"Storage for tenant consumption" section
 details consumption models for tenants: Platform native,
 object storage, shared file storage and archival.
 The choice of a solution will depend on the storage use case needs.
@@ -261,8 +261,8 @@ over the native networking implementations of orchestrators, including:
 -  BGP as a Service (BGPaaS) for distribution of routes between
    privately managed customer networks and service provider networks
 
-Based on the network layering concepts introduced in the Reference
-Model Section :ref:`ref_model:chapters/chapter03:network`, the
+Based on the network layering concepts introduced in the
+"Network" section in :cite:p:`refmodel`, the
 Tungsten Fabric Controller performs functions of both the SDN underlay
 (SDNu) and overlay (SDNo) controllers.
 
@@ -394,8 +394,8 @@ Cloud Controller Services
 The following OpenStack components are deployed on the Infrastructure.
 Some of them will be only deployed on control hosts and some of them
 will be deployed within both control and compute hosts. The table below
-also maps the OpenStack core services to the Reference Model (RM)
-:ref:`ref_model:chapters/chapter03:virtual infrastructure manager`.
+also maps the OpenStack core services to the Virtual Infrastructure
+ Manager in the Reference Model (RM) :cite:p:`refmodel`.
 
 .. list-table:: OpenStack components deployment
    :widths: 20 10 20 10 10 10
@@ -536,8 +536,7 @@ the resources of a project are not affected by resources of another
 project.
 
 This document uses the term "project" when referring to OpenStack
-services and "tenant" (RM Section
-:ref:`ref_model:chapters/chapter03:virtual resources`)
+services and "tenant" (RM Section "Virtual resources")
 to represent an independently manageable logical pool of resources.
 
 Cloud partitioning: Host Aggregates, Availability Zones
@@ -578,8 +577,8 @@ In OpenStack a flavor defines the compute, memory, and storage capacity
 of nova instances. When instances are spawned, they are mapped to
 flavors which define the available hardware configuration for them. For
 simplicity, operators may create named flavors specifying both the
-sizing and the
-:doc:`software and hardware profile configurations <ref_model:chapters/chapter05>`.
+sizing and the "Software and Hardware Profile Configurations"
+:cite:p:`refmodel`.
 
 Underlying Resources
 --------------------
@@ -642,8 +641,7 @@ up (in a shipping container), and what resources are required of the DC
 -  Storage
 
    - Storage technologies are multiple, they are extensively
-     described in
-     :ref:`ref_model:chapters/chapter03:storage implementation stereotypes`.
+     described in "Storage Implementation Stereotypes" :cite:p:`refmodel`.
      Storage backends are discussed in
      :ref:`chapters/chapter04:storage backend`.
 
@@ -660,10 +658,9 @@ Cloud Infrastructure physical Nodes
 
 The physical resources required for the Cloud Infrastructure are mainly
 based on COTS x86 hardware for control and data plane nodes. HW profiles
-are defined in Reference Model chapters
-:ref:`ref_model:chapters/chapter05:cloud infrastructure hardware profile description`
-and
-:ref:`ref_model:chapters/chapter05:cloud infrastructure hardware profiles features and requirements.`.
+are defined in the chapters "Cloud Infrastructure Hardware Profile
+Description" and "Cloud Infrastructure Hardware Profiles Features and
+Requirements" in :cite:p:`refmodel`.
 
 Network
 ^^^^^^^
@@ -762,7 +759,7 @@ Assumptions and conventions:
 -  Shared storage is optional, but it is important to ensure shared
    assets are distributed across serving clouds such as boot images.
    Storage needs, per deployment and use cases, can be found in
-   :ref:`ref_model:chapters/chapter03:storage scenarios and architecture fit`.
+   "Storage Scenarios and Architecture Fit" :cite:p:`refmodel`.
 
 .. list-table:: Cloud Topology: Redundancy Models
    :widths: 8 15 8 8 8 8 8 17

doc/ref_arch/openstack/chapters/chapter04.rst

@@ -17,7 +17,7 @@ structure of control and user planes, operating systems, hypervisors, and
 BIOS configurations, and architectural details of underlay and overlay
 networking, and storage, and the distribution of OpenStack service
 components among nodes. The chapter also covers implementation support
-for the :ref:`ref_model:chapters/chapter02:profiles, profile extensions & flavours`;
+for the "Profiles, Profile Extensions & Flavours" :cite:p:`refmodel`;
 the OpenStack flavor types capture both the sizing and the profile
 configuration (of the host).
 
@@ -70,8 +70,8 @@ OpenStack Control Plane Servers (Control Nodes)
 -  BIOS Requirements
 
 For OpenStack control nodes we use the BIOS parameters for the basic
-profile defined in :ref:`ref_model:chapters/chapter05:\
-cloud infrastructure hardware profiles features and requirements.`.
+profile defined in "Cloud Infrastructure Hardware Profiles Features and
+Requirements" :cite:p:`refmodel`.
 Additionally, for OpenStack we need to set the following boot parameters:
 
 .. table:: Boot parameters
@@ -159,7 +159,7 @@ Storage nodes
    Boot disks          RAID 1
    =================== ======
 
--  HW specifications: please see :ref:`ref_model:chapters/chapter03:storage`
+-  HW specifications: please see "Storage" in :cite:p:`refmodel`
 -  How many nodes to meet SLA: Active-Passive is the default and
    recently OpenStack started to support Active-Active
 -  Sizing rules: minimum 2 x 1 TB; recommended 2 x 10 TB
@@ -171,17 +171,19 @@ This section specifies the compute node configurations to support the
 Basic and High-Performance profiles; in OpenStack this would be
 accomplished by specifying the configurations when creating "flavors".
 The cloud operator may choose to implement certain profile-extensions
-(:ref:`ref_model:chapters/chapter02:profile extensions (specialisations)`)
+(Profile Extensions (Specialisations) :cite:p:`refmodel`)
 as a set of standard configurations, of a given profile, capturing some
 of the variability through different values or extra specifications.
 
 -  The software and hardware configurations are as specified in the
-   :ref:`ref_model:chapters/chapter05:cloud infrastructure hardware profiles features and requirements.`
+   Cloud Infrastructure Hardware Profiles Features and Requirements
+   in :cite:p:`refmodel`.
 
 -  BIOS requirement
 
    -  The general BIOS requirements are described in the
-      :ref:`ref_model:chapters/chapter05:cloud infrastructure hardware profiles features and requirements.`
+      Cloud Infrastructure Hardware Profiles Features and Requirements
+      :cite:p:`refmodel`.
 
 **Example Profiles and their Extensions**
 
@@ -240,11 +242,11 @@ extensions and some of their capabilities.
 **BIOS Settings**
 
 A number of capabilities need to be enabled in the BIOS (such as NUMA
-and SMT); the Reference Model section on
-:ref:`ref_model:chapters/chapter05:cloud infrastructure software profile description`
-specifies the capabilities required to be configured. Please note that
-capabilities may need to be configured in multiple systems. For
-OpenStack, we also need to set the following boot parameters:
+and SMT); the "Cloud Infrastructure Software Profile Description"
+section in the Reference Model specifies the capabilities
+required to be configured. Please note that capabilities may need to
+be configured in multiple systems. For OpenStack, we also need to set
+the following boot parameters:
 
 .. table:: BIOS requirements
    :widths: auto
@@ -1407,7 +1409,7 @@ Consumable Infrastructure Resources and Services
 Support for Cloud Infrastructure Profiles and flavors
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Reference Model Chapter 4 and 5 provide information about the Cloud
+Chapters 4 and 5 in :cite:p:`refmodel` provide information about the Cloud
 Infrastructure Profiles and their size information. OpenStack flavors
 with their set of properties describe the server capabilities and size
 required to determine the compute host which will run this server. The
@@ -1501,7 +1503,7 @@ set up the flavors as specified in the tables below.
 
    -  To configure profile-extensions, for example, the "Storage
       Intensive High Performance" profile, as defined in
-      :ref:`ref_model:chapters/chapter02:profile extensions (specialisations)`,
+      Profile Extensions (Specialisations) :cite:p:`refmodel`,
       in addition to the above, need to configure the storage IOPS: the
       following two parameters need to be specified in the flavor
       create: -property quota:disk_write_iops_sec=<IOPS#> and -property
@@ -1567,10 +1569,9 @@ Cloud Centre as representative terms for cloud services hosted at
 centralised large data centres, Telco edge locations and for locations
 with capacity somewhere in between the large data centres and edge
 locations, respectively. The mapping of various terms, including the
-Reference Model terminology specified in Table `8-5
-:ref:`ref_model:chapters/chapter08:comparison of deployment topologies and edge terms`
-and Open Glossary of Edge Computing
-:cite:p:`edge_glossary`
+Reference Model terminology specified in the chapter
+"Comparison of Deployment Topologies and Edge Terms"
+and Open Glossary of Edge Computing :cite:p:`edge_glossary`,
 is as follows:
 
 -  Central Cloud Centre: Large Centralised Data Centre, Regional Data
@@ -1585,7 +1586,7 @@ the resource capacity, as in the number of servers, and the capacity of
 these servers in terms of # of cores, RAM, etc. restricting the set of
 services that can be deployed and, thus, creating a dependency between
 other data centres.
-:ref:`ref_model:chapters/chapter08:telco edge cloud`
+"Telco Edge Cloud" chapter in :cite:p:`refmodel`
 specifies the physical and environmental characteristics, infrastructure
 capabilities and deployment scenarios of different locations.
 
@@ -1675,8 +1676,7 @@ such deployment choices.
 Edge Cloud Topology
 ~~~~~~~~~~~~~~~~~~~
 
-The Reference Model Chapter
-:ref:`ref_model:chapters/chapter08:telco edge cloud`
+The Reference Model "Telco Edge Cloud" chapter :cite:p:`refmodel`
 presents the deployment environment characteristics, infrastructure
 characteristics and new values for the Infrastructure Profiles at the Edge.
 
@@ -1692,13 +1692,13 @@ Cloud Centre and the number of copies that should be deployed. These
 references also present the pros and cons of DCP and CCP and designs to
 address some of the challenges of each of the models.
 
-:ref:`ref_model:chapters/chapter08:telco edge cloud: platform services deployment`
+"Telco Edge Cloud: Platform Services Deployment" :cite:p:`refmodel`
 lists the Platform Services that may be placed in the different node types
 (control, compute and storage). Depending upon the capacity and
 resources available only the compute nodes may exist at the Edge thereby
 impacting operations.
 
-:ref:`ref_model:chapters/chapter08:telco edge cloud: infrastructure profiles`
+"Telco Edge Cloud: Infrastructure Profiles" :cite:p:`refmodel`
 lists a number of Infrastructure Profile characteristics and the changes that
 may need to be made for certain Edge clouds depending upon their
 resource capabilities. It should be noted that none of these changes

doc/ref_arch/openstack/chapters/chapter07.rst

@@ -62,9 +62,9 @@ version and then the old servers are undeployed.
 Cloud Infrastructure provisioning and configuration management
 --------------------------------------------------------------
 
-In the Reference Model,
-:ref:`ref_model:chapters/chapter09:configuration and lifecycle management`
-defines the functions of Configuration and Life Cycle Management (LCM).
+In the Reference Model :cite:p:`refmodel`, the "Configuration and
+Lifecycle Management" chapter defines the functions of Configuration
+and Life Cycle Management (LCM).
 To operate and manage a scalable cloud, that minimizes operational
 costs, requires tools that incorporates systems for automated
 provisioning and deployment, and managing configurations that ensures
@@ -240,7 +240,7 @@ workloads so that appropriate actions can be taken. For example,
    resources.
 
 Some of the data is to support the metrics collection specified in the
-:doc:`ref_model:chapters/chapter04`.
+Reference Model :cite:p:`refmodel`.
 
 Logs have multiple operational uses including for: