updated fabric

Author: sushantjrao

articles/operator-nexus/concepts-access-control-lists.md

@@ -57,7 +57,7 @@ The action property of an ACL statement can have one of the following types:
 
 Additionally to add an additional layer of control plane protection for enhancing network security, users can also configure and modify control plane traffic policies on supported devices via APIs. 
 
-•	A Traffic Policy (TP) solution for securing the fabric device Control Plane (packets destined to or originating from the fabric device) of the supported devices in AON.
+•	A Traffic Policy (TP) solution for securing the Fabric device Control Plane (packets destined to or originating from the Fabric device) of the supported devices in AON.
 
 •	The device control plane (which includes Policing/Rate Limiting) can be implemented as Traffic Policies based on source/destination IP, source/destination ports, and protocols.
 •	API supports create, update, and delete the TP entries/rules/Policing/Rate Limiting.
@@ -66,7 +66,7 @@ To implement the functionality for Control Plane ACL - Traffic Policy:
 
 •	For existing deployments, users must create a CPTP ACL resource, associate it with the Network Fabric (NF), and perform a patch operation.
 
-•	For new deployments, users should create the CPTP ACL resource either during fabric creation or after the fabric has been provisioned, followed by patching it to the NF resource. Since the CPTP ACL resource is not created by default, users must manually create it before attaching it to the NF.
+•	For new deployments, users should create the CPTP ACL resource either during Fabric creation or after the Fabric has been provisioned, followed by patching it to the NF resource. Since the CPTP ACL resource is not created by default, users must manually create it before attaching it to the NF.
 
 ## Next steps:
 

articles/operator-nexus/concepts-isolation-domain.md

@@ -19,13 +19,13 @@ An Isolation Domain resource enables the creation of layer-2 and layer-3 network
 
 -   **Layer-3 isolation domain with Internal Networks** - provides workloads the ability to connect across a layer 3 (IP) network.
 
--   **Layer-3 isolation domain with External Network** - provides workloads the ability to connect across a layer 3 network, and provides connectivity to the operator's network outside of the Operator Nexus network fabric.
+-   **Layer-3 isolation domain with External Network** - provides workloads the ability to connect across a layer 3 network, and provides connectivity to the operator's network outside of the Operator Nexus Network Fabric.
 
 An isolation domain offers:
 
 -   Unified network capabilities with full integration with your compute resources, enabling connectivity between your Operator Nexus platform workloads.
 
--   Northbound connectivity with customer routers using BGP peering sessions between the Operator Nexus network fabric and the operator's external network.
+-   Northbound connectivity with customer routers using BGP peering sessions between the Operator Nexus Network Fabric and the operator's external network.
 
 -   Southbound connectivity with telco workloads using internal networks.
 
@@ -47,16 +47,16 @@ The L2VRF feature in Nexus enhances the flexibility and scalability of network c
 
 - **Extended VLAN Support:** The Layer 2 Isolation Domain (ISD) ARM resource now supports a new read-write property called extendedVlan, which defaults to false. When this property is set, the CEs are configured to trunk through the VLAN ID of the L2 ISD to the PE.
 
-- **Dynamic Configuration:** The extendedVlan property can be dynamically toggled, and changes apply at the point of the next fabric commit.
+- **Dynamic Configuration:** The extendedVlan property can be dynamically toggled, and changes apply at the point of the next Fabric commit.
 
 - **Traffic Agnosticism:** Nexus is agnostic to the traffic running over this network and does not run any hosts or services on it. Address management, security, and services (DNS, DHCP, NTP, etc.) are user responsibilities.
 
 ## Layer 3 Isolation Domains
 
-A layer 3 isolation domain provides workloads with the ability to exchange layer-3 routing information through the Operator Nexus network fabric and with external networks.
+A layer 3 isolation domain provides workloads with the ability to exchange layer-3 routing information through the Operator Nexus Network Fabric and with external networks.
 
 Layer-3 isolation domains can provide two types of network:
 
--   **Internal Network** - a Layer 3 Isolation Domain Internal Network enables east-west layer 3 communication between workloads on the Operator Nexus Network fabric. An internal network is a complete solution for layer-3 inter and intra-rack communication for compute workloads. Each workload can connect to multiple internal networks.
+-   **Internal Network** - a Layer 3 Isolation Domain Internal Network enables east-west layer 3 communication between workloads on the Operator Nexus Network Fabric. An internal network is a complete solution for layer-3 inter and intra-rack communication for compute workloads. Each workload can connect to multiple internal networks.
 
--   **External Network** - a Layer 3 Isolation Domain External Network enables workloads to communicate with external services via the operator network. An external network creates a communication channel between Operator Nexus workloads and services hosted outside of the Operator Nexus network fabric. Each Layer 3 isolation domain supports one external network.
+-   **External Network** - a Layer 3 Isolation Domain External Network enables workloads to communicate with external services via the operator network. An external network creates a communication channel between Operator Nexus workloads and services hosted outside of the Operator Nexus Network Fabric. Each Layer 3 isolation domain supports one external network.

articles/operator-nexus/howto-append-custom-suffix-to-interface-descriptions.md

@@ -61,7 +61,7 @@ az networkfabric interface update --additional-description "example-description"
 
 ### 3. Commit the configuration
 
-After updating the description, apply the changes to the fabric:
+After updating the description, apply the changes to the Fabric:
 
 ```Azure CLI
 az networkfabric fabric commit-configuration --resource-group "example-rg" --resource-name "example-fabric"
@@ -108,7 +108,7 @@ az networkfabric interface update --additional-description "example-description"
 
 ### 3. Commit the configuration
 
-After removing the suffix, apply the changes to the fabric:
+After removing the suffix, apply the changes to the Fabric:
 
 ```Azure CLI
 az networkfabric fabric commit-configuration --resource-group "example-rg" --resource-name "example-fabric"
@@ -138,4 +138,4 @@ This feature is available for the following interface types:
 - **NPB Device**  
 
 > [!Note]  
-> **Existing deployments** will retain their **current descriptions** until fabric instances are **migrated to Release 8.0**. After migration, users must update descriptions via the **API**.
+> **Existing deployments** will retain their **current descriptions** until Fabric instances are **migrated to Release 8.0**. After migration, users must update descriptions via the **API**.

articles/operator-nexus/howto-configure-bring-your-own-storage-network-fabric.md

@@ -96,9 +96,9 @@ Use the `--storage-account-configuration` parameter to define the storage locati
 }
 ```
 
-## Create a new fabric instance
+## Create a new Fabric instance
 
-Use the following command to create a new fabric instance with BYO storage:
+Use the following command to create a new Fabric instance with BYO storage:
 
 ```azurecli
 az networkfabric fabric create --resource-name <fabricname> \
@@ -108,9 +108,9 @@ az networkfabric fabric create --resource-name <fabricname> \
     --mi-user-assigned "/subscriptions/<uamisubscriptionid>/resourceGroups/<uamiresourcegroupname>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<uaminame>"
 ```
 
-## Update an existing fabric instance
+## Update an existing Fabric instance
 
-For existing deployments, update the fabric with the required parameters:
+For existing deployments, update the Fabric with the required parameters:
 
 ```azurecli
 az networkfabric fabric update --resource-name <fabricname> \

articles/operator-nexus/howto-reboot-network-device.md

@@ -72,7 +72,7 @@ az networkfabric device reboot --network-device-name <DeviceName> --resource-gro
 
 #### Considerations  
 
-- The **fabric** is still placed in **maintenance mode**, but the **device itself is not**.
+- The **Fabric** is still placed in **maintenance mode**, but the **device itself is not**.
 
 - **Blocked operations during the reboot:**
 
@@ -107,14 +107,14 @@ For devices running **Arista EOS**, the reboot process is triggered via the **gN
 
 ### Key difference in ungraceful reboot 
 
-- In an **ungraceful reboot**, the **device itself is not placed in maintenance mode**, but the **fabric still enters maintenance mode**.  
+- In an **ungraceful reboot**, the **device itself is not placed in maintenance mode**, but the **Fabric still enters maintenance mode**.  
 
 ## Summary of key differences  
 
 | **Feature**  | **Graceful Reboot Without ZTP** | **Ungraceful Reboot Without ZTP** |  
 |-------------|--------------------------------|----------------------------------|  
 | **Puts device in maintenance mode?** | ✅ Yes | ❌ No |  
-| **Puts fabric in maintenance mode?** | ✅ Yes | ✅ Yes |  
+| **Puts Fabric in maintenance mode?** | ✅ Yes | ✅ Yes |  
 | **Uses last known good configuration?** | ✅ Yes | ✅ Yes |  
 | **Blocks configuration updates, upgrades, and replacement flows?** | ✅ Yes | ✅ Yes |  
 | **Persists runRW configuration?** | ✅ Yes | ✅ Yes |

articles/operator-nexus/howto-set-up-break-glass-access-using-in-band-management.md

@@ -11,7 +11,7 @@ ms.custom: template-how-to
 
 # Break-Glass access using In-Band management
 
-In the Nexus Network Fabric (NNF), there is an out-of-band management network where most fabric devices are connected to management switches via management ports (Ma1). The only exceptions are the Terminal Server and Aggregation Management Switches.
+In the Nexus Network Fabric (NNF), there is an out-of-band management network where most Fabric devices are connected to management switches via management ports (Ma1). The only exceptions are the Terminal Server and Aggregation Management Switches.
 To address the potential single point of failure posed by the management switch, Microsoft team has provided the Redundant In-band Management Break Glass Access feature. 
 
 > [!Note]
@@ -189,4 +189,4 @@ ipv6 prefix-list trusted_sources_v6
 ```
 
 > [!Note]
-> For Greenfield deployments, provide a list of trusted IP prefixes or use default resources created by the system. <br> For Brownfield deployments, ensure configurations are in place during upgrades and use PATCH operations to update the network fabric.
+> For new deployments, provide a list of trusted IP prefixes or use default resources created by the system. <br> For existing deployments, ensure configurations are in place during upgrades and use PATCH operations to update the network Fabric.