Update design.md

docs/v2.0/design.md

@@ -1,54 +1,40 @@
-# Network Design Assumptions
+# Deployment Scenarios
 
-## Officially supported configuration
+## Standard Inline Deployment
 
-- LibreQoS is placed inline at the edge of your network, usually between the network's border router (NAT, firewall) and the core distribution router / switch.
+LibreQoS is placed inline at the edge of your network, usually between the network's border router (NAT, firewall) and the core distribution router / switch.
 
-![Offical Configuration](https://github.com/user-attachments/assets/e5914a58-3ec6-4eb1-b016-8a57582dd082)
-
-### Primary and Backup Paths
-
-We recommend using dynamic routing protocols such as OSPF to create a high cost and low cost path between the edge router and core distribution router/switch. The low cost path should pass "through" the LibreQoS shaper bridge interfaces to allow LibreQoS to observe and shape traffic. For example, a low cost OSPF path may be set to a value of 1. The high-cost (backup) link would completely bypass LibreQoS, being set to a higher cost (perhaps 100 for OSPF) to ensure that traffic only takes that path when the LibreQoS shaper bridge is not operational.
-
-### NAT/CG-NAT
+#### NAT/CG-NAT
 If you use NAT/CG-NAT, please place LibreQoS inline prior to where NAT is applied, as LibreQoS needs to shape pre-NAT addresses (100.64.0.0/12) not public post-NAT IPs.
 
-### MPLS/VPLS
+#### MPLS/VPLS
 LibreQoS can parse MPLS traffic, however the traffic must follow the standard pattern:
 ```
 (mpls tags)(optional vlan tags)(ip header)
 ```
 If you use MPLS with a different tag pattern, you would ideally want to terminate MPLS traffic at the core distribution router / switch, before it reaches LibreQoS.
 
-## Testbed configuration
-When you are first testing out LibreQoS, we recommend deploying a small-scale testbed to see it in action.
-![image](https://github.com/user-attachments/assets/6174bd29-112d-4b00-bea8-41314983d37a)
+#### Dynamic Routing: Bypass path
+- Primary path (low cost) *through* the server running LibreQoS
+- Backup path (high cost) *bypassing* the server running LibreQoS.
 
-### Network Interface Card
+#### Diagram
+![Offical Configuration](https://github.com/user-attachments/assets/e5914a58-3ec6-4eb1-b016-8a57582dd082)
 
-```{note}
-You must have one of these:
-- single NIC with two interfaces,
-- two NICs with single interface,
-- 2x VLANs interface (using one or two NICs).
-```
+### Option 1: Using Dynamic Routing (Strongly Recommended)
 
-LibreQoS requires NICs to have 2 or more RX/TX queues and XDP support. While many cards theoretically meet these requirements, less commonly used cards tend to have unreported driver bugs which impede XDP functionality and make them unusable for our purposes. At this time we recommend the Intel x520, Intel x710, and Nvidia (ConnectX-5 or newer) NICs. We cannot guarantee compatibility with other cards.
+We recommend using dynamic routing protocols such as OSPF to create a high cost and low cost path between the edge router and core distribution router/switch. The low cost path should pass "through" the LibreQoS shaper bridge interfaces to allow LibreQoS to observe and shape traffic. For example, a low cost OSPF path may be set to a value of 1. The high-cost (backup) link would completely bypass LibreQoS, being set to a higher cost (perhaps 100 for OSPF) to ensure that traffic only takes that path when the LibreQoS shaper bridge is not operational.
 
-## Alternate configuration
+### Option 2: Using Spanning Tree Protocol (Not Recommended)
 
-This alternate configuration uses Spanning Tree Protocol (STP) to modify the data path in the event the LibreQoS device is offline for maintenance or another problem.
+You can also use the Spanning Tree Protocol with path costs if OSPF or another dynamic routing protocol is not an option.
 
 ```{note}
 Most of the same considerations apply to the alternate configuration as they do to the officially supported configuation
 ```
 
-- LibreQoS is placed inline at the edge of your network, usually between the network's border router (NAT, firewall) and the core distribution router / switch.
-- If you use NAT/CG-NAT, place LibreQoS inline prior to where NAT is applied, as LibreQoS needs to shape pre-NAT addresses (100.64.0.0/12) not public post-NAT IPs.
-- For networks using MPLS: LibreQoS can parse MPLS traffic, but the traffic must follow the standard pattern (mpls tags)(optional vlan tags)(ip header). If you use MPLS with a different pattern, you would ideally want to terminate MPLS traffic at the core distribution router / switch, before it reaches LibreQoS.
-- Spanning Tree primary link (low cost) through the server running LibreQoS
-- Spanning Tree backup link (high cost, maybe 80 for example)
-
 Keep in mind that if you use different bandwidth links, for example, 10 Gbps through LibreQoS, and 1 Gbps between core switch and edge router, you may need to be more intentional with your STP costs.
 
-![image](https://github.com/user-attachments/assets/39247655-3bcf-4a0c-8cfb-1ed1a96d3c2d)
+## Testbed Deployment (Optional)
+When you are first testing out LibreQoS, you can deploy a small-scale testbed to see it in action on a test network.
+![image](https://github.com/user-attachments/assets/6174bd29-112d-4b00-bea8-41314983d37a)