7.2.0 release documentation

docs/_install_interactiveoverview.md

@@ -8,4 +8,4 @@ The steps in this section describe the *interactive conductor installation* from
 The Conductor installation must be completed before installing a Session Smart Router or routers using the ISO. The same ISO is used for both installations.
 :::
 
-To install a router **after** installing and configuring the Conductor, use the [SSR Installation](intro_installation_bootable_media.mdx). The [Router Installation Using OTP](intro_otp_iso_install.mdx) procedure can be used for whitebox and air-gap, conductor-managed network installations. 
+To install a router **after** installing and configuring the Conductor, use the [SSR Installation](intro_installation_bootable_media.mdx). The [Router Installation Using OTP](intro_otp_iso_install.md) procedure can be used for whitebox and air-gap, conductor-managed network installations. 

docs/about_releases.md

@@ -54,6 +54,7 @@ However, issues resolved in `4.3.12`, which was released on 3/12/2021 are not ad
 
 | Version | Initial GA Version | First Release Shipping Date | Latest GA Version | Support Lifetime | End of Engineering support | End of Support |
 | -- | -- | -- | -- | -- | -- | -- |
+| Release 7.2 | [7.2.0](release_notes_128t_7.2.md#release-720-24r1) | June 30, 2026 |  [7.2.0](release_notes_128t_7.2.md#release-720-24r1) | LTS | December 30, 2028 | June 30, 2029 |
 | Release 7.1 | [7.1.0](release_notes_128t_7.1.md#release-710-50r1) | December 4, 2025 | [7.1.5](release_notes_128t_7.1.md#release-715-7r2) | STS | March 10, 2027 | September 10, 2027 |
 | Release 7.0 | [7.0.1](release_notes_128t_7.0.md#release-701-1r1) | October 14, 2025 | [7.0.1](release_notes_128t_7.0.md#release-701-1r1) | LTS | August 24, 2028 | February 24, 2029 |
 | Release 6.3 | [6.3.0](release_notes_128t_6.3.md#release-630-107r1) | September 30, 2024 | [6.3.7-6-sts](release_notes_128t_6.3.md#release-637-6-sts) | STS | May 6, 2026 | November 6, 2026 |

docs/bcp_att_avpn_configuration.md

@@ -3,8 +3,6 @@ title: AT&T AVPN Configuration
 sidebar_label: AT&T AVPN Configuration
 ---
 
-import Mermaid from '@theme/Mermaid';
-
 This guide is for network engineers and architects using their Session Smart Router to connect to AT&T’s MPLS VPN (AVPN) service. It will cover:
 - Service class definitions for the various COS queues on the AT&T MPLS network
 - Strategies for mapping `service` configuration to the COS queues using `service-policy` elements
@@ -229,37 +227,37 @@ The base class `service-policy` configurations presented here are derived from t
 The SSR uses four traffic engineering queues for prioritizing egress traffic during times of congestion or link contention. The general practice of mapping the `traffic-class` assignments (high, medium, low, best-effort) into the various 6COS queues is shown below.
 
 
-<Mermaid chart={`
-  graph LR
-    voip-audio --> ATT-COS1
-    id1(BFD, BGP) -.-> ATT-control
-    voip-video --> ATT-COS2V
-    video-streaming --> ATT-COS2V
-    voip-signaling --> ATT-COS2
-    data-mission-critical --> ATT-COS2
-    remote-desktop --> ATT-COS2
-    management-interactive --> ATT-COS3
-    management-m2m --> ATT-COS3
-    data-interactive --> ATT-COS3
-    data-best-effort --> ATT-COS4
-    data-scavenger --> ATT-COS5
-    video-streaming-scavenger --> ATT-COS5
-    subgraph best-effort
+```mermaid
+graph LR
+  voip-audio --> ATT-COS1
+  id1(BFD, BGP) -.-> ATT-control
+  voip-video --> ATT-COS2V
+  video-streaming --> ATT-COS2V
+  voip-signaling --> ATT-COS2
+  data-mission-critical --> ATT-COS2
+  remote-desktop --> ATT-COS2
+  management-interactive --> ATT-COS3
+  management-m2m --> ATT-COS3
+  data-interactive --> ATT-COS3
+  data-best-effort --> ATT-COS4
+  data-scavenger --> ATT-COS5
+  video-streaming-scavenger --> ATT-COS5
+  subgraph best-effort
     ATT-COS5
-    end
-    subgraph low
+  end
+  subgraph low
     ATT-COS4
-    end
-    subgraph medium
+  end
+  subgraph medium
     ATT-COS2V
     ATT-COS2
     ATT-COS3
-    end
-    subgraph high
+  end
+  subgraph high
     ATT-COS1
     ATT-control
-    end
-`}/>
+  end
+```
 
 Each AT&T AVPN circuit has a *profile* associated with it (referred to as a "COS Package"), that maps to bandwidth allocations for the various COS queues. These in turn need to be mapped to the four egress traffic engineering queues on the SSR. The COS Package from AT&T is expressed as a set of six numbers (corresponding to the queues), where the first number is the percentage of the circuit bandwidth allocated for COS1, and the remaining five numbers (which sum to 100%) represent the amount of *bandwidth remaining* from the bandwidth not used by COS1.
 

docs/bcp_sdwan_design_guide.md

@@ -89,7 +89,7 @@ There are many considerations with a pod design. In the drawing above, the hando
 
 ### Tenancy Design
 
-*Main article: [Tenancy Design](bcp_tenants.mdx)*
+*Main article: [Tenancy Design](bcp_tenants.md)*
 
 From the discussion with the end customer on segmentation, the definition of tenants should be relatively straight forward. The goal is to create a list of global profiles that can be used for access policies to services. Conceptually, tenancy should not be tied to a location and should be a global construct available whenever we want to classify traffic to a profile when it enters the SSR fabric across the authority (though at times due to business logic defined by the customer, a tenant may reflect a location). At any point in the authority, when traffic ingresses into an SSR, tenancy is applied. Typically this is done by assigning the tenant to the network-interface according to the purpose of the VLAN for which the SSR is the router. For example "POS" for point of sale, "voice" for telephony devices, and "core" for traffic coming from the customer's core network (if no further breakdown of tenancy is required for this traffic). The SSR can also restrict ingress traffic into a tenant further by creating a neighborhood on the network interface. Neighborhoods serve multiple purposes and an additional discussion of neighborhoods will occur in an ensuing section. In the global tenant configuration, this neighborhood may be referenced as a "member" and then CIDR block ranges for source addresses can be defined within this member. In this manner, a shared neighborhood name can be configured on a common LAN network for a site category and the tenant configuration can be updated with the specific list of CIDR ranges that will be used to identify which source IP addresses belong to a particular tenant for traffic coming in on this interface.
 

docs/bcp_tenants.mdx → docs/bcp_tenants.md

@@ -3,8 +3,6 @@ title: Tenancy Design
 sidebar_label: Tenancy Design
 ---
 
-import Flowchart from '../src/components/Flowchart';
-
 The *tenant* is one of the foundational data model elements within the Session Smart Router (SSR), and represents a consumer of network *services*. Tenancy is the logical partitioning of a network’s resources, done in the interest of restricting access to network services to only the users and groups for which they’re intended.
 
 This document provides an overview of tenancy in the SSR, how it is configured, and provides guidance for modeling the segmentation of a network using the SSR's data modeling language.
@@ -41,26 +39,20 @@ As new sessions arrive at an SSR, the router will attempt to classify the source
 
 Should none of these result in a definitive determination on the tenant of the source of this session request, the session is associated with the *global tenant* (see the section on "Special Tenants" for more information on the global tenant). Once the tenant has been identified – either as a specific tenant, or as the global tenant – this acts as a filter into the SSR’s FIB. Only the routes associated with that tenant are available to that user group. While this somewhat resembles the way a legacy router uses VRFs to create separate RIBs and FIBs, the segment by *tenant* is pervasive among all routers within an Authority by design, and is applied ubiquitously among all varieties of networks: public IP space, private, cloud, IPv4, IPv6, etc.
 
-<Flowchart
-  chartCode={`
-    st=>start: Packet Arrives
-      metadata=>condition: Packet has metadata?
-      int=>condition: Interface has a tenant?
-      nh=>condition: Neighborhood-based tenant?
-      tm=>operation: Tenant taken from metadata
-      ti=>operation: Tenant taken from interface
-      th=>operation: Tenant taken from neighborhood
-      global=>operation: Tenant assigned as "global"
-      e=>end: Proceed to FIB lookup
-    st->metadata
-    metadata(no)->int
-    metadata(yes,right)->tm->e
-    int(yes,right)->ti->e
-    int(no)->nh
-    nh(yes,right)->th->e
-    nh(no)->global->e
-  `}
-/>
+```mermaid
+flowchart TD
+    st([Packet Arrives]) --> metadata{Packet has metadata?}
+    metadata -->|no| int{Interface has a tenant?}
+    metadata -->|yes| tm[Tenant taken from metadata]
+    tm --> e([Proceed to FIB lookup])
+    int -->|yes| ti[Tenant taken from interface]
+    ti --> e
+    int -->|no| nh{Neighborhood-based tenant?}
+    nh -->|yes| th[Tenant taken from neighborhood]
+    th --> e
+    nh -->|no| gl["Tenant assigned as &quot;global&quot;"]
+    gl --> e
+```
 
 #### Viewing a Router's Tenancy
 

docs/cc_fips_downloading_iso.md

@@ -11,7 +11,7 @@ Juniper Session Smart Networking provides the following workflows for the compli
 
 - **Package-based ISO:** This ISO offers multiple local installation methods.
   - **One Touch Provisioning (OTP)** is the default and preferred method of Router installation. OTP sets up DHCP on all interfaces and boots a Web Server GUI. After installing the Conductor and configuring routers through the Conductor, the OTP quickstart process will install and configure the router. See the following procedures for OTP installation steps: 
-    - [Router Installation Using OTP](intro_otp_iso_install.mdx)
+    - [Router Installation Using OTP](intro_otp_iso_install.md)
     - [Quickstart from the OTP ISO](intro_install_quickstart_otpiso.md)
   - **Interactive:** For Conductor installations and bespoke deployments where customized platform configuration is necessary, an interactive mode exists. Installation is done using the serial console. An interactive session is started to configure network interfaces, passwords, node name and type, and conductor IP (if applicable) before the SSR software is started.
 

docs/cert_validation_requirements.md

@@ -8,6 +8,7 @@ sidebar_label: Certificate Requirements and Validation
 | Release | Modification                |
 | ------- | --------------------------- |
 | 7.0.0   | Certificate management and validation support added. |
+| 7.2.0   | Subject Alternative Name URI support for peering identity. |
 
 This page describes the certificate properties that the SSR enforces, how `validation-mode` affects behavior, and the differences between config-time and runtime validation.
 
@@ -112,6 +113,7 @@ Client certificates used for peering are validated as leaf (end-entity) certific
 | --- | --- |
 | Signature Algorithm | Must be an [accepted algorithm](#accepted-cryptographic-algorithms). |
 | Public Key | Must be an [accepted key type and size](#key-requirements). |
+| Subject Alternative Name (optional) | Starting in SSR 7.2.0, a `urn:ssr:peering:<alias>` SAN URI can be used to carry SVR peering identity as an alternative to the Common Name. See [Enhanced Security Key Management — API Naming Rules](sec_enhanced_key_mgmt.md#api-naming-rules) for details. |
 
 ### Intermediate CA Certificates