docu flex algo intent and adjust intent overview docu page

docs/intents/flex-algo/flex-algo-overview.md

@@ -0,0 +1,230 @@
+# Flex Algo Intent
+
+The `flex algo` intent allows users to calculate a path on a specific subgraph of the network topology, enabling the exclusion of certain links or nodes. This intent is particularly useful for applications requiring additional constraints, such as enforcing encryption along the path or incorporating geo-based information into the calculation.
+
+When only the `flex algo` intent is provided, the HawkEye controller determines the optimal path based on the IGP cost between the two hosts. However, users can also define additional intents to be included in the calculation, allowing for the use of other metrics such as packet loss, latency, and jitter. The concept of constraints is also supported, providing further flexibility in path selection.
+
+## Network Topology
+
+The network topology below illustrates the pre-defined Flex Algo 128, highlighted in blue. All path requests specifying Flex Algo 128 will be calculated on this blue subgraph.
+
+
+![Flex Algo 128](../../images/hawkv6-network-flex-algo-128-with-details.drawio.svg) 
+
+## Example Scenarios
+
+The following scenarios illustrate how Flex Algo intents can optimize the path between two hosts:
+
+1. **Scenario 1**: Path between HOST-A and HOST-B using Flex Algo 128 and the IGP metric.
+2. **Scenario 2**: Path between HOST-A and HOST-C using Flex Algo 128 with a combination of low latency and low packet loss.
+3. **Scenario 3**: Path between HOST-A and HOST-C using Flex Algo 128 and a Service Function Chain (SFC) with low packet loss.
+
+### Scenario 1: Flex Algo 128 with IGP Metric
+
+In this scenario, HOST-A (acting as the client) requests a path to HOST-B (acting as the server) using Flex Algo 128. The HawkEye controller calculates the optimal path based on the IGP cost between the two hosts.
+
+
+#### HawkWing Configuration
+```yaml
+---
+client_ipv6_address: 2001:db8:a::10
+hawkeye:
+  enabled: true
+  address: 2001:db8:e5::e
+  port: 10000
+services:
+  webserver-b:
+    ipv6_addresses:
+      - 2001:db8:b::10
+    applications:
+      - port: 80
+        intents:
+          - intent: flex-algo
+            flex_algo_number: 128
+```
+
+#### API Request
+The `flex-algo128 igp metric` request is saved `flex-algo` folder. The JSON request format is as follows:
+```
+{
+    "ipv6_destination_address": "2001:db8:b::10",
+    "ipv6_source_address": "2001:db8:a::10",
+    "intents": [
+        {
+            "type": "INTENT_TYPE_FLEX_ALGO",
+            "values": [
+        {
+            "type": "VALUE_TYPE_FLEX_ALGO_NR",
+            "number_value": 128
+        }
+            ]
+        }
+    ]
+}
+```
+#### Result
+
+The following SID list is generated to ensure the optimal path with the lowest IGP metric using Flex Algo 128 between the two hosts:
+
+- `fc00:0:1:128:1::`
+- `fc00:0:3:128:1::`
+- `fc00:0:7:128:1::`
+- `fc00:0:8:128:1::`
+- `fc00:0:b:128:1::`
+
+The packets are routed through the following devices:
+HOST-A -> SITE-A -> XR-1 -> XR-3 -> XR-7 -> XR-8 -> SITE-B -> HOST-B
+
+
+![Flex Algo 128 Path](../../images/hawkv6-flex-algo-128-intent.drawio.svg)
+
+
+### Scenario 2: Flex Algo 128 with Low Latency and Low Packet Loss
+
+In this scenario, Host-A (acting as the client) requests a path to Host-B (acting as the server) using Flex Algo 128. The HawkEye controller calculates the optimal path by prioritizing both low latency and low packet loss intents to ensure an efficient and reliable connection between the two hosts.
+
+#### HawkWing Configuration
+```yaml
+---
+client_ipv6_address: 2001:db8:a::10
+hawkeye:
+  enabled: true
+  address: 2001:db8:e5::e
+  port: 10000
+services:
+  webserver-b:
+    ipv6_addresses:
+      - 2001:db8:b::10
+    applications:
+      - port: 80
+        intents:
+          - intent: flex-algo
+            flex_algo_number: 128
+          - intent: low-latency
+          - intent: low-packet-loss
+```
+
+#### API Request
+The `flex-algo 128 with low latency and low packet loss` request is saved `flex-algo` folder. The JSON request format is as follows:
+```
+{
+    "ipv6_source_address": "2001:db8:a::10",
+    "ipv6_destination_address": "2001:db8:b::10",
+    "intents": [
+        {
+            "type": "INTENT_TYPE_FLEX_ALGO",
+            "values": [
+        {
+            "type": "VALUE_TYPE_FLEX_ALGO_NR",
+            "number_value": 128
+        }
+            ]
+        },
+        {
+            "type": "INTENT_TYPE_LOW_LATENCY"
+        },
+        {
+            "type": "INTENT_TYPE_LOW_PACKET_LOSS"
+        },
+    ]
+}
+``` 
+
+#### Result
+
+The following SID List is generated to ensure the optimal path with the lowest latency and packet loss using Flex Algo 128 between the two hosts:
+- `fc00:0:1:128:1::`
+- `fc00:0:3:128:1::`
+- `fc00:0:7:128:1::`
+- `fc00:0:8:128:1::`
+- `fc00:0:b:128:1::`
+
+The packets traverse the devices in this order:
+HOST-A -> SITE-A -> XR-1 -> XR-3 -> XR-7 -> XR-8 -> SITE-B -> HOST-B
+
+The path remains unchanged from the previous scenario because, within this subgraph, only one viable alternative exists. The alternative route through SITE-C would introduce higher latency and packet loss, resulting in a higher overall cost.
+
+![Flex Algo 128 Low Latency Low Loss Path](../../images/hawkv6-flex-algo-128-low-latency-low-loss-intent.drawio.svg)
+
+
+### 
+### Scenario 3: Flex Algo 128 with SFC and Low Packet Loss
+In this scenario, Host-A (acting as the client) requests a path to Host-C (acting as the server) using Flex Algo 128. The HawkEye controller calculates the optimal route based on the low packet loss intent, incorporating a Service Function Chain (SFC) that includes both a firewall and an IDS, while adhering to the Flex Algo 128 constraints. The available service nodes in this scenario are the SERA-2 firewall and the SNORT-2 IDS.
+
+
+#### HawkWing Configuration
+```yaml
+---
+client_ipv6_address: 2001:db8:a::10
+hawkeye:
+  enabled: true
+  address: 2001:db8:e5::e
+  port: 10000
+services:
+  webserver-b:
+    ipv6_addresses:
+      - 2001:db8:c::10
+    applications:
+      - port: 80
+        intents:
+          - intent: sfc
+            functions:
+              - fw
+              - ids
+          - intent: flex-algo
+            flex_algo_number: 128
+          - intent: low-packet-loss
+```
+
+#### API Request
+The `flex-algo 128 sfc with firwall and ids low packet loss` request is saved `flex-algo` folder. The JSON request format is as follows:
+```
+{
+    "ipv6_source_address": "2001:db8:a::10",
+    "ipv6_destination_address": "2001:db8:c::10",
+    "intents": [
+        {
+            "type": "INTENT_TYPE_SFC",
+            "values": [
+                {
+                    "type": "VALUE_TYPE_SFC",
+                    "string_value": "fw"
+                },
+                {
+                    "type": "VALUE_TYPE_SFC",
+                    "string_value": "ids"
+                }
+            ]
+        },
+        {
+            "type": "INTENT_TYPE_FLEX_ALGO",
+            "values": [
+                {
+                    "type": "VALUE_TYPE_FLEX_ALGO_NR",
+                    "number_value": 128
+                }
+            ]
+        },
+        {
+            "type": "INTENT_TYPE_LOW_PACKET_LOSS"
+        }
+    ]
+}
+```
+
+#### Result
+The following SID List is generated to ensure the optimal path between the two hosts:
+
+- `fc00:0:1:128:1::`
+- `fc00:0:3:128:1::`
+- `fc00:0:3f::`
+- `fc00:0:7:128:1::`
+- `fc00:0:7f::`
+- `fc00:0:c:128:1::`
+
+The packets traverse the devices in this order:
+HOST-A -> SITE-A -> XR-1 -> XR-3 -> SERA-2 -> XR-7 -> SNORT-2 -> SITE-C -> HOST-C
+
+Since the only available Service Function Chain (SFC) on the Flex Algo 128 subgraph involves the SERA-2 firewall and SNORT-2 IDS, the path is determined by this service sequence. 
+
+![Flex Algo 128 Low Latency Low Loss SFC Path](../../images/hawkv6-flex-algo-128-sfc-intent.drawio.svg)

docs/intents/overview.md

@@ -1,64 +1,41 @@
 # Intents Overview
-This section provides a comprehensive list of all available intents within the platform. Each intent serves as a unique identifier for a specific action that users can initiate. The platform uses these intents to interpret user requests and trigger the corresponding actions.
 
-For each intent, you will find an example that includes the relevant HawkWing configuration and the associated API request. The `/api` folder contains the [Kreya API Files](https://kreya.app/) it can be simpliy imported.
- Each example has been tested in the provided test network environment, offering you a practical reference for implementing these intents in your own configurations.
+This section provides a detailed overview of all available intents within the platform. Each intent serves as a unique identifier for a specific action that can be initiated, enabling the platform to interpret and execute user requests accordingly.
 
-## Intents
+For each intent, an example is provided that includes the relevant HawkWing configuration and the corresponding API request. The examples are organized in the `/api` folder, where [Kreya API Files](https://kreya.app/) can be easily imported for practical use. Each example has been thoroughly tested within the provided test network environment, offering practical references for implementing these intents in various configurations.
 
-### Single Intents
-Here is a list of single intents that can be used to define a specific path between two hosts.
-
-#### Low Latency
-More information about the low latency intent can be found [here](single-intent/low-latency.md).
-
-#### Low Jitter
-More information about the low latency intent can be found [here](single-intent/low-jitter.md).
-
-#### Low Packet Loss
-More information about the low packet loss intent can be found [here](single-intent/low-packet-loss.md).
-
-
-#### High Bandwidth
+## Intents Categories
 
-More information about the high bandwidth intent can be found [here](single-intent/high-bandwidth.md).
+The intents are categorized into four main groups: **Single Intents**, **Combined Intents**, **Service Function Chaining (SFC)**, and **Flexible Algorithm (Flex Algo)**. Each category includes detailed information and examples to help implement the intents effectively.
 
-#### Low Bandwidth
-More information about the low bandwidth intent can be found [here](single-intent/low-bandwidth.md).
-
-
-#### Low Utilization
-More information about the low utilization intent can be found [here](single-intent/low-utilization.md).
-
-### Combinations
-Here is a list of intents that can be combined to define a specific path between two hosts.
-
-#### Two Intents
-More information about the combininig two intents can be found [here](combined-intents/two-intents.md).
-
-#### Three Intents
-More information about the combininig three intents can be found [here](combined-intents/three-intents.md).
+### Single Intents
 
-#### Constrained Intents
-More information about the constrained intents can be found [here](combined-intents/constrained-intents.md).
+Single intents are used to define a specific path between two hosts based on a single network metric. Below are the available single intents:
 
+- **Low Latency**: [Learn more](single-intent/low-latency.md)
+- **Low Jitter**: [Learn more](single-intent/low-jitter.md)
+- **Low Packet Loss**: [Learn more](single-intent/low-packet-loss.md)
+- **High Bandwidth**: [Learn more](single-intent/high-bandwidth.md)
+- **Low Bandwidth**: [Learn more](single-intent/low-bandwidth.md)
+- **Low Utilization**: [Learn more](single-intent/low-utilization.md)
 
-### Service Function Chaining 
-Here is a list of intents that can be used to define a specific path between two hosts with Service Function Chaining.
+### Combined Intents
 
-#### SFC with IGP Metric
-More information about the SFC with IGP metrics can be found [here](sfc/sfc-igp-metric.md).
+Combined intents allow optimization of paths between hosts using multiple metrics. Below are the available combined intents:
 
-### SFC with other Metrics
-More information about the SFC with other metrics can be found [here](sfc/sfc-other-metrics.md).
+- **Two Intents**: [Learn more](combined-intents/two-intents.md)
+- **Three Intents**: [Learn more](combined-intents/three-intents.md)
+- **Constrained Intents**: [Learn more](combined-intents/constrained-intents.md)
 
+### Service Function Chaining (SFC)
 
-### Flexible Algorithm
-#### Flex Algo with IGP Metric
-More information about the single flex algo with IGP metrics can be found [here](flex-algo/single-flex-algo.md).
+SFC intents are used to define paths between two hosts that include specific service functions. Below are the available SFC intents:
 
+- **SFC with IGP Metric**: [Learn more](sfc/sfc-igp-metric.md)
+- **SFC with Other Metrics**: [Learn more](sfc/sfc-other-metrics.md)
 
-#### Flex Algo with other Metrics
+### Flexible Algorithm (Flex Algo)
 
+Flex Algo intents allow calculation of paths on specific subgraphs of the network topology, enabling the exclusion of certain links or nodes. Below are the available Flex Algo intents:
 
-#### Flex Algo with SFC
+- **Flex Algo**: [Learn more](flex-algo/flex-algo-overview.md)