:EP: 34
:Title: MEF E-LINE CSPF integration
:Authors:
    - Vinicius Arcanjo <vindasil AT fiu DOT edu>
    - Italo Valcy <idasilva AT fiu DOT edu>
    - Jeronimo Bezerra <jbezerra AT fiu DOT edu>
    - Rogerio Motitsuki <rogerio.motitsuki AT gmail DOT com>
    - Antonio Francisco <ajoaoff AT gmail DOT com>
:Created: 2022-09-26
:Kytos-Version: 2022.3
:Status: Finished

***********************************
EP033 - MEF E-LINE CSPF integration
***********************************

Abstract
========

This blueprint proposes how ``mef_eline`` will integrate with ``pathfinder`` to request CSPF paths.

Motivation
==========

Production networks typically have multiple paths in the core of the network, often times, it can be desirable to have additional constraints (the constraints and variables and ``pathfinder`` exposes) when finding a new path to account for certain business or traffic-engineering requirements.

Rationale
=========

In this iteration, the major goal is to integrate ``mef_eline`` with ``pathfinder`` and its existing filtering capabilities. ``mef_eline`` relies on ``pathfinder`` to find paths for dynamic primary paths and failover paths. This proposed implementation will allow the constraints to be set individually for both primary and failover to allow it to evolve in a way where constraint requirements can be different to target a strategic set of network paths. The failover path plays a critical role in providing fast convergence, the failover path will still provide the same type of protection maximizing link disjointness but it'll compute it on top of any failover path constraints that might have been set. In the future, more granular control for how the failover path computes its disjointness might be available depending on production use cases. On ``mef_eline`` UI, users might not need to specify optional constraints both cases, we can have a strategic UX/UI, we can start with a case where if any optional constraint is given then parametrize to both dynamic primary and secondary, and gradually allowing users to have more control when ever needed.

Specification
=============

- When an EVC is created or updated, ``primary_constraints`` and ``secondary_constraints`` optional request attributes can be set. ``primary_constraints`` will be used when finding a dynamic primary path and ``secondary_constraints`` when finding a failover path. 
- Optional constraints ``spf_attribute``, ``mandatory_metrics``, ``flexible_metrics``, ``minimum_flexible_hits``, ``minimum_flexible_hits``, ``spf_max_path_cost``, ``desired_links``, and ``undesired_links`` will be parametrized. More information about each type and value can be found `on pathfinder API specification <https://kytos-ng.github.io/api/pathfinder.html#tag/Paths/paths/~1api~1kytos~1pathfinder~1v2~1/post>`_ (source and destination will be derived from the EVC, any other available parameter can be set).


Use Case Example
----------------

This ring network topology represents a minimal network with multiple paths where an EVC will be created from H1 to H2. The dynamic primary path should be at least 100Gbps and ``blue`` ownership, and the failover path should be at least 40Gbps and ``red`` ownership.


.. code:: console

                                 100G, "blue"
               +------------------------------------------+
               |                 link a                   |
               |                                          |
               |                                          |
           +---+----+           +--------+           +----+---+
           |        | 40G,"red" |        | 40G,"red" |        |
           |  SW1   +-----------+  SW2   +-----------+  SW3   |
  H1-------+        |  link b   |        |  link c   |        +-----H2
           |        |           |        |           |        |
           +--------+           +--------+           +--------+

                                Ring Topology

EVC request payload from H1 to H2 with a dynamic paths and constraints:

.. code:: javascript

  {
      "name": "epl",
      "dynamic_backup_path": true,
      "uni_a": {
          "interface_id": "H1"
      },
      "uni_z": {
         "interface_id": "H2"
      },
      "primary_constraints": {
        "spf_attribute": "hop",
        "mandatory_metrics": {
          "bandwidth": 100,
          "ownership": "blue"
        }
      },
      "secondary_constraints": {
        "spf_attribute": "hop",
        "mandatory_metrics": {
          "bandwidth": 40,
          "ownership": "red"
        }
      }
  }


Two requests will be sent to ``pathfinder`` when the time comes to deploy either the primary or failover path with the respective constraints. For the failover, the disjointness algorithm will be computed on the resulting constraint paths.

- Dynamic primary path request body:

.. code:: javascript

  {
    "source": "H1",
    "destination": "H2",
    "spf_attribute": "hop",
    "mandatory_metrics": {
      "bandwidth": 100,
      "ownership": "blue"
    }
  }

The expected path result should be ``["link a"]``.

- Failover path request body:

.. code:: javascript

  {
    "source": "H1",
    "destination": "H2",
    "spf_attribute": "hop",
    "mandatory_metrics": {
      "bandwidth": 40,
      "ownership": "red"
    }
  }

The expected path result should be ``["link b", "link c"]``.


Rejected Ideas
==============

N/A yet
