El enfoque fue hablar sobre SDN's. La primera impresión al hablar sobre este tema es que estan muy decepcionados, especialmente Wainer. Han tratado de hacer funcionar en una red un sdn controller y no lo estan logrando (actualmente estan usando ONOS como controller), al parecer siempre fueron estudiantes quienes se han focalizado principalmente en resolver esta tarea. Esto último define un factor que me parecio clave por como lo hablaba Eukeni, el trabajo que implica enseñar a usar las SDN's a cada nuevo estudiante que pasa por aqui (contra).

Otra cosa importante es que si bien estan experimentando con SDN's, no estan encontrando escenarios claros en los que puedan definir múltiples casos de uso en donde este paradigma les podría servir (contra). Eukeni mencionaba que el está conciente de que las SDN ayudan mucho en redes dinámicas, sin embargo el experimento en el que estamos trabajando no cumple con ser dinámico (es todo redundante, y si algo se cae se detiene el experimento). El principal uso, y básicamente por lo que todavía no han decidido abandonar completamente las SDN's, son los intent languages(pro). Entienden que está buenisimo poder definir intenciones sobre la red, y es algo que quieren. El problema con estos es que han tratado de programar una especie de NIC (https://wiki.opendaylight.org/view/Project_Proposals:Network_Intent_Composition) en ONOS, y resulta que las intenciones escritas en un lenguaje se tornan en reglas de forwarding que crecen de manera exponencialmente rápida en función de los nodos de la red.

Entonces, a partir de unir en la red HTL el trafico de control con el trafico de datos, los requerimientos que tienen sobre esta nueva red son:

• Quieren poder garantizar QoS
• Load Balancing entre links de la red
• Redundancia

Ellos quieren poder simular la red HTL (NO LA DE PHASE I) juntando el trafico de datos de control y trafico de datos, para ver que valores necesitarían de la red para que la latencia sea baja, no haya droppeo de paquetes, etc (algo al estilo de infiniband). No es una obligación que el simulador sea de una red de tipo SDNs (en realidad no les importa esto, pero tenerlo sumaria obviamente). Los datos que se obtendrían de está simulación pueden ser útiles en una etapa posterior para la creación de intent languages que usen dichos párametros (onda ejemplo de NEMO

Por otro lado hay una presentación de un poster dentro de 3 semanas que trata sobre SDN's que tiene que mostrar Eukeni. En este poster, la idea es presentar los avances que han tenido con SDN's y tratar de explicar porque estaría bueno usarlo. Me voy a meter a ayudar a ver si puedo conseguir algo en estas pocas semanas (la idea no es dedicarle 100 %, ya que trabajan con ONOS de lo cual no estoy muy canchero, pero por lo menos me va a servir para entender mejos los requerimientos que necesitan y aprender a usar la red). Este sería mi primer objetivo a corto plazo.

Estos son los objetivos a alcanzar para la presentación del poster:

• Network discovery
• We should be able to feed the controller with some source of information
• The JSON files that we will generate somehow.
• Leaf-spine topology
• OF rules should be created by intents
• ONOS does it already
• Ideally the number of OF rules should scale with 2N (N being the number of hosts)
• It is an important feature for large scale networks, for Phase I network is not so important so we can leave it for the end.
• We may need to rewrite our own intent.
• We are writing our own intent to solve Load balancing. This might be included.
• Load-balancing:
• We need to understand how we/ONOS can measure the traffic and ask ONOS to rebalance the load on the links
• Currently writing a new intent to balance the intents based on link loads.
• Fault-tolerance:
• How the network reacts when a link fails
• I understand that the intents take care of this already. We need to measure how fast.
• How the network reacts when a switch fails
• Same as above
• QOS:
• Ability to define 4 traffic classes (based on IP subnet for example). This is trivial.
• Traffic prioritization: by applying different scheduler policies (WRR and strict priority). I do not know if this is doable with OF. In the worst case it will be hard configured on the switch.
• Rate limiting: it is doable with OF. We need to see how ONOS does it.
• How it is applied: per intent/port/flow.…
• bug in open floodlight library, where the meter information is lost. (impacts intents, works for manually installed flows)
• Hybrid mode
• We need that one working on a real device, at least so we can write about its benefits (parallel deployment and 100% of uptime)
• Other:
• Need to correctly explain the strategy to deal with the ARP (done)
• Need to correctly explain the strategy to deal with the destination MACs (done)
• How to solve the device management issue. Not done
• How to monitor (maybe irrelevant since SNMP can work independently of OF)

Como conclusión de la reunión:

• Crear una simulación de la red que me permita estudiar los párametros de QoS en la red HLT (NO LA RED DE PHASE I) que se esta necesitando para la red
• Estudiar con SDN's como se podría resolver el problema de balanceo de carga entre links (la idea es que si tengo
  A ------------LINK 1-------------- B
  ------------LINK 2--------------
  

  Entonces el controller debería poder balancear la carga entre los links. Hoy en dia no se esta pudiendo hacer).

• Buscar mas casos de uso en donde se podría usar las SDN (si es que los hay)

-- AndresLaurito - 2016-08-11