Introducción a Segment Routing

Introducción a Segment Routing


Segment routing es uno de los chicos nuevos del barrio en el área de enrutamiento, y encaja perfectamente tanto en el paradigma de las redes autónomas, como en el enfoque en SDN con control centralizado orientado a aplicaciones.


Segment Routing reutiliza fuertemente conceptos de otras grandes tecnologías - Multi Protocol Label Switching (MPLS), y Source Routing. Por lo tanto, es ventajoso revisitar sus propiedades más importantes.


MPLS - Revisión rápida


Este artículo asume el entendimiento básico, tanto de los mecanismos internos de MPLS, como del proceso de reenvío. Para una introducción a MPLS de una manera ligera y manejable, se les invita a leer un artículo escrito anteriormente: Introducción a MPLS


Como un abreboca, resumamos algunas de las características claves de MPLS:


  • Tecnología de transporte capaz de llevar un rango amplio (si no cualquier) de protocolos
  • No posee su propio formato de datagrama, sus shim labels siempre son insertadas entre capas 2 y 3 del protocolo existente
  • Su transporte está basado en operaciones con labels localmente significativas y sus valores
  • Las operaciones de sus labels son PUSH, SWAP y POP
  • Se apoya principalmente en Label Distribution Protocol (LDP) para anunciar y distribuir label bindings (aunque otros protocolos fueron extendidos luego para el suportar anuncio de labels)
  • Los Labels están atados típicamente a prefijos IP de destino o circuitos virtuales - en general, a caminos hacia un endpoint específico y una operación a ser realizada luego de remover el label
  • El rango disponible de labels es <0 - 1,048,575>
  • El rango reservado de labels es <0 - 15>


La responsabilidad de crear y anunciar label mappings para prefijos en la tabla de enrutamiento de un router esta en las manos de LDP. Precisamente, LDP crea y anuncia label bindings para los prefijos en la tabla de enrutamiento aprendidos de todas las fuentes de información de enrutamiento, excepto BGP. Las rutas aprendidas de BGP están eximidas de operaciones con LDP porque BGP tiene su propio mecanismo interno para anunciar label mappings a la vez que prefijos. Por lo tanto, la tabla de enrutamiento debe poseer información para que LDP tenga algo en qué trabajar. Típicamente, protocolos links-state como OSPF y IS-IS son usados para este propósito, no solo para popular la tabla de enrutamiento, sino también para anunciar información de la topología y construir una base de datos de la misma, permitiendo a cada nodo en la red tener una vista completa y consistente de la topología. Los protocolos de enrutamiento distance-vector tales como EIGRP o BGP pueden ser usados, pero, algunas de las aplicaciones avanzadas de MPLS requieren que los routers tengan conocimiento detallado de la topología, por lo tanto, los protocolos link-state son preferidos generalmente.


Cada router crea y anuncia label bindings basándose en sus propias reglas, y como cada label solo tiene algún significado particular para el router que la anunció (el mismo valor de label puede tener un significado completamente diferente para otro router), los valores de los labels a lo largo del mismo camino hacia un destino particular son, generalmente, diferentes en cada salto.


MPLS tiene una propiedad realmente única: sin importar cuál lógica ha sido usada para colocar los labels entre routers consecutivos para algún camino dado, el mecanismo de reenvío para los paquetes etiquetados (con label) no cambia. Esto le permite a MPLS traer consigo diversos mecanismos al control plane que son responsables de instalar los labels, y lograr instalación muy específica y selección de ruta/camino sin alterar las operaciones del data plane. Esta flexibilidad pavimentó el camino para uno de las más importantes -y avanzadas- aplicaciones de MPLS: MPLS Traffic Engineering (MPLS-TE). MPLS-TE es un grupo de características y tecnologías que permiten la influencia de ciertas rutas en la red que no serían empleadas usualmente por los protocolos de enrutamiento, ya que no corresponden con el criterio del camino más corto, pero las cuales poseen propiedades específicas, como ancho de banda disponible. Esencialmente, MPLS-TE permite transportar paquetes a través de rutas que satisfacen requerimientos adicionales, más específicos que la distancia más corta. Hacer esto ayuda a utilizar la capacidad general de la red más eficientemente, y permite proveer SLA específicos a flujos de datos particulares.


MPLS-TE en sí mismo está compuesto de bloques múltiples. Primero, comprende un grupo de extensiones de ingeniería de tráfico para IGPs de link-state. Su propósito es, entre otros detalles, llevar información sobre el ancho de banda total y reservable en cada enlace entre routers en una red. Segundo, MPLS-TE reusa el protocolo RSVP de la arquitectura de Integrated Services (IntServ). En IntServ, el propósito de RSVP era de proveer señalización exhaustiva,  a través de la cual una aplicación corriendo en los clientes finales podría decirle a la red que requerimientos tenía en el la ruta de transporte para un flujo en particular (ancho de banda, queueing). La red podría, instalar tal ruta, o comunicarle a la aplicación que la ruta requerida no estaba disponible. En MPLS-TE, RSVP corre solo entre routers MPLS, no hacia los clientes finales, y tiene responsabilidades ligeramente diferentes: realiza el anuncio y conteo del ancho de banda utilizado por túneles TE en los enlaces individuales, y anuncia los labels MPLS para esos túneles TE. Los IGPs de link-state y RSVP trabajan juntos: El IGP es responsable de buscar el camino más corto que satisfaga el requerimiento de ancho de banda  de un túnel en particular, luego, entrega la secuencia exacta de routers y enlaces a RSVP, el cual realiza el conteo del ancho de banda usado y restante a lo largo de este camino, y anuncia el label para el mismo.

Caminos que han sido calculados por medio de ingeniería de tráfico en MPLS-TE son llamados túneles TEm, o simplemente túneles. Un túnel TE siempre sería configurado en el router donde el túnel inicia (headend router), y la configuración típicamente contendrá el destino del túnel, el ancho de banda requerido, y una lista de opciones para el camino a tomar, refiriendo hacia el protocolo de enrutamiento para calcular el camino correcto, o a una lista explícita de next-hops abarcando el camino del túnel. OSPF o IS-IS en conjunto con RSVP tendrían entonces que instalar el túnel incluyendo los labels MPLS, o informar al headend router que el camino hacia el destino configurado, con el ancho de banda solicitado, no existe. Los túneles TE en MPLS son siempre unidireccionales desde el headend router hasta el tailend router, es decir, entre ambos extremos del túnel. Un camino calculado haciendo uso de ingeniería de tráfico entre dos endpoints de un túnel determinado requeriría instalar dos túneles.


MPLS-TE es una de las aplicaciones más importantes de MPLS, pero existen preocupaciones con respecto a su escalabilidad. Uno de los retos evidentes es su configuración y/o su complejidad operacional: cada túnel con propiedades únicas (destino, ancho de banda solicitado que debe ser garantizado, y otros) debe ser configurado en el headend router explícitamente. Con decenas, tal vez cientos de endpoints de túneles, también considerando el hecho de que pueden existir túneles múltiples con diferentes requerimientos entre los mismos endpoints, la cantidad de configuracion aumenta considerablemente. Otra preocupación es la presencia de RSVP. En los tiempos de IntServ, el signalling de RSVP y el control plane state resultante acerca de todos los flujos se posiciona como una carga (o sobrecarga) en la escalabilidad. En MPLS-TE, la situación es mucho mejor, ya que RSVP solo lleva información acerca de los túneles TE, no sobre los flujos individuales, pero RSVP aún actúa como un componente añadido con su propio grupo de mensajes para ser intercambiados periódicamente, y un state para ser almacenado. Finalmente, otro aspecto de MPLS-TE son las responsabilidades adicionales de los link-state IGP -OSPF o IS-IS. Los mismos han sido extendidos con una característica adicional llamada Constrained Shortest Path First (CSPF), la cual es un nombre elegante para el cálculo del camino más corto que también toma en cuenta el ancho de banda disponible, para asegurar que el camino más corto calculado pueda llevar un túnel con un ancho de banda particular. Aunque esta característica es muy simple en su naturaleza -ignorar todos los enlaces cuyo ancho de banda disponible es menor que el solicitado por el túnel y solo calcula el camino más corto sobre los enlaces que queden- necesita ser invocado desde el headend router para cada túnel. Como los administradores de redes son siempre cautelosos acerca de los SPF runs adicionales, las ejecuciones de CSPF causan algunas preocupaciones.


En resumen, MPLS-TE impone una cantidad considerable de state sobre el ancho de banda máximo, usado, y disponible para reservar en los enlaces de la red, y sobre los túneles TE, que los routers tienen que intercambiar, mantener y actualizar. Aun cuando la capacidad de implementar Ingeniería de tráfico (TE por sus siglas en inglés) es muy deseada, el alto costo del control plane no es tan atractivo.


Las redes basadas en packet switching ofrecen una cualidad única: en lugar de transportar paquetes sin información agregada y almacenar todo el state necesario para su reenvío y su manejo específico en todos los routers a lo largo del camino, podemos codificar el state -o las instrucciones- en alguna parte del mismo paquete. Las instrucciones serían insertadas en el paquete por un router al ingresar a la red, y los otros routers simplemente las seguirían. Hasta cierto punto, esto es lo que MPLS hace: ya que los routers dentro de una red MPLS toman decisiones de reenvío basados en el label superior únicamente, no necesitan entender algo debajo de ese label. Esto es exactamente sobre de lo que las MPLS VPNs se tratan. Aun con esta lógica, MPLS-TE representa un gasto considerable en cuanto a operaciones de control plane hasta que instala una secuencia de labels en los routers que indican el camino particular, paso por paso, que un túnel TE particular tomará. Sería posible codificar el camino completo de un túnel TE en un paquete con su respectivo label, y de ser así, cómo se lograría de la forma más eficiente?


Esta pregunta fue respondida -usando los medios técnicamente disponibles en estos tiempos- hace unos 35 años, cuando una tecnología capaz de ingenieria de trafico llamada Source Routing hizo su aparición en escena. Veamos entonces al actor clave, ya que Source Routing -reinventado- es lo que compone el núcleo de Segment Routing.


IP Source Routing


La especificación de IPv4 fue publicada como RFC 791 en 1981. Este documento especifica el formato de los paquetes IPv4, la arquitectura de direccionamiento, y las operaciones de hosts y routers cuando se originan, enrutan, reenvían y reciben paquetes. El modo básico de enrutamiento de paquetes IPv4 fue basado en el paradigma de enrutamiento hacia el destino: Solo la dirección de destino era usada para seleccionar una ruta para un paquete dado; el remitente u otras propiedades del paquete no influencian la selección del camino. Sin embargo, la especificación IPv4 también trajo consigo dos modos de enrutamiento (en el campo de opciones del paquete) donde el remitente tendría más control acerca del camino del paquete: Loose Source and Record Route (LSRR), y Strict Source and Record Route (SRRR)


Cual era el caso de uso para ellos? Ellos fueron ideados para permitir al remitente especificar el camino que un paquete debería tomar - en otras palabras, que saltos necesitaba dar el paquete en el camino a su destino. Por lo tanto, quien originase el tráfico dictaba, parcial o completamente, el camino para esos paquetes.


Realicemos una comparación rápida.


En el caso de IP routing corriente, individualmente para cada paquete, cada router determinaría el siguiente salto idóneo para el paquete basándose única y específicamente en la dirección de destino encontrada en el paquete. La Figura 1 muestra el ejemplo clásico de enrutamiento basado en destino a lo largo del camino más corto:

Figura 1: Enrutamiento basado en destino a lo largo del camino más corto


En Source Routing, por otra parte, el remitente de un paquete puede establecer o prescribir un camino arbitrario para el paquete, el cual es completamente independiente del típico camino más corto hacia el destino. Un camino posible es mostrado en la Figura 2.

Figura 2: Un camino arbitrario definido por medio de Source Routing


Como se muestra arriba, el camino puede ser completamente diferente, y el mismo depende del remitente de los paquetes para decidir cuál debería ser el camino particular.


Hay dos variaciones de Source Routing en IPv4: Loose Source and Record Route (LSRR) y Strict Source and Record Route (SRRR). Ambas variantes están basadas en almacenar una lista de saltos (o paradas) en el campo de opciones del encabezado IP; esta lista es también conocida como “route data” y puede mantener un máximo de 9 direcciones.


Loose Source and Record Route (LSRR) funciona de una forma similar a un GPS: toma el rumbo hacia una ciudad, y define un par de paradas por las cuales quieres pasar. El GPS calculará una ruta que consiste en los caminos más cortos entre las paradas de manera consecutiva, sin requerir que se especifique todas y cada una de las carreteras/autopistas a lo largo del camino. Loose Source routing funciona de la misma forma. El adjetivo Loose significa que las paradas consecutivas -los siguientes saltos- no necesitan estar directamente conectados entre ellas. Depende del router recibiendo el paquete decidir qué camino tomar para llegar a la siguiente parada - naturalmente, será el más corto hacia la misma.


Strict Source and Record Route (SSRR) trabaja de forma parecida, pero impone una restricción adicional: los siguientes saltos consecutivos en el campo route data deben representar una secuencia de routers directamente conectados. Si el router manejando un paquete descubre que el siguiente salto, definido explícitamente, no está directamente conectado, descarta el paquete. Literalmente, cuando SSRR “dicta” el camino, el paquete debe seguir el mismo, que se encuentra descrito por la información route data dentro del campo de opciones del paquete IP.


El propósito de Source Routing y sus versiones era proveer una forma de ingeniería de tráfico basado en host, y extender las herramientas disponibles de troubleshooting proveyendo una forma de descubrir y explorar la red al agregar una herramienta que podría permitir al administrador rastrear y determinar con precisión fallas en un camino específico hacia un destino determinado donde caminos múltiples están disponibles. La Figura 3 muestra un grupo de caminos posibles hacia el mismo destino, todos podrían ser usados -o analizados para detectar/solucionar problemas- gracias a Source Routing. Un hecho importante para tomar en cuenta es que los routers mostrados abajo no almacenan state sobre esos caminos explícitos -el camino o ruta a seguir se encuentra almacenado en el paquete mismo.


Figura 3: Caminos independientes múltiples definidos por medio de Source Routing


Teniendo una herramienta poderosa como esta, capaz de evitar patrones de reenvio y enrutamiento esperados en una red determinada, no era solo atractivo para administradores, sino también para individuales tratando de lograr objetivos maliciosos. Por ejemplo, Source Routing podría haber sido usado para enviar paquetes hacia una red privada que no estaba anunciada en protocolos de enrutamiento, mientras que el atacante supiese que routers cruzar antes de llegar hasta el que tendría la red directamente conectada. Source Routing demostró ser una preocupación significativa en cuanto a seguridad se refiere y trajo consigo un riesgo considerable al que ninguna red debería ser expuesta. Como un gran poder conlleva una gran responsabilidad, IETF publicó un documento recomendando deshabilitar las capacidades de Source Routing en los routers para evitar cualquier tipo de exposición a tal riesgo. Eventualmente fue considerado obsoleto y los equipo de hoy en día no están habilitados para manejar Source Routing de fábrica.


Segment Routing


Reiteramos lo que hemos recorrido hasta ahora. Se discutió sobre MPLS-TE y se resaltó su utilidad y su amplio despliegue como aplicación de MPLS, pero a su vez, presenta condiciones adversas relacionadas a su escalabilidad y administrabilidad, ambos con respecto a control y management plane. También hemos discutido sobre IP Source Routing, el cual puede ser visto como una técnica rudimentaria de ingeniería de tráfico en la cual la red misma no lleva carga alguna asociada al control plane. Porque el camino específico está codificado en el encabezado de cada paquete, pero, a su vez posee implicaciones de seguridad porque le otorga mucho poder a los usuarios finales enviando paquetes IP.


Pero, ¿qué tal si la responsabilidad de codificar el camino explícito en los paquetes fuese otorgada a un ingress router en lugar del host que lo envía? Los problemas de seguridad ya no serían una preocupación. Y si existiese una forma de codificar esta información de camino explícito en paquetes con labels para que una red MPLS pueda procesarlos sin necesidad de almacenar ningún tipo de state en todos los routers a lo largo del camino deseado, ello resolvería los problemas con la escalabilidad de MPLS-TE. Estas son las ideas clave de Segment Routing, las cuales combinan lo mejor de MPLS y Source Routing.


Codificar un camino explícito en un paquete puede ser visto como colocar una secuencia de instrucciones en el mismo. Tomándolo con pinzas, seria casi como “gira a la derecha, luego ve recto, luego gira a la izquierda, luego derecha de nuevo, y luego derecho por los próximos 10 kilómetros”. Segment Routing hace uso de esta idea: Su camino explícito es un grupo de instrucciones colocadas en el paquete, con los routers ejecutando las mismas mientras lo reenvían. Cada instrucción en Segment Routing es llamada segmento, tiene su propio número llamado Segment ID (SID), y como aprenderemos luego, hay múltiples tipos de segmentos. Para representar estas instrucciones en un paquete, Segment Routing necesita usar una codificación apropiada -y para redes MPLS, la codificación natural es es nada más que un label stack- con cada label representando un segmento particular. Los valores de los labels MPLS llevarían el Segment ID de segmentos individuales.


Desde una perspectiva puramente basada en MPLS, Segment Routing se construye sobre el paradigma de reenvío básico de MPLS y no cambia como los paquetes con labels son reenviados, lo cual es parecido a otras aplicaciones de MPLS. Con respecto a las operaciones de control plane, hay dos cambios significativos a las políticas de control plane que merecen ser mencionados:

  • Para ciertos tipos de segmento, los labels tiene valores preferiblemente idénticos en todos los routers en el SR domain y tienen valores de significado global
  • Label bindings de los segmentos son anunciados por OSPF o IS-IS, LDP no es usado


Para resumir: En Segment Routing, el camino que un paquete sigue es representado por un stack de labels que es colocado sobre el paquete por un edge router. Cada label representa un segmento -una instrucción particular que determina como el paquete será reenviado.


Habiendo dicho esto, hemos entendido que los mismos son instrucciones, pero ahora debemos determinar cómo los routers identifican estos segmentos. Definamos las clases de segmentos que podemos encontrar.


En Segment Routing, hay dos clases de segmentos:

  • Segmento Global
  • Segmento Local


Un segmento global es un valor de ID que posee relevancia dentro del SR domain enteramente. Es decir, que cada nodo en el SR domain sabe sobre este valor y asigna la misma acción a la instrucción asociada en su LFIB. El rango reservado de labels usado para este propósito es <16000 - 23999>, es llamado Segment Routing Global Block (SRGB) y es un rango específico de fabricante (Cisco), por lo tanto, otros fabricantes podrían usar un rango diferente.


Un segmento local, por otro lado, es un valor de ID que posee significado local, y solo el nodo que lo originó (el router anunciándolo) puede ejecutar la instrucción asociada. Como este rango es relevante sólo para ese nodo en particular, estos valores no están dentro del rango SRGB sino en el rango configurado localmente.


Segment Routing reconoce varios tipos de segmento particulares que pertenecen a las clases global o local. Veamos algunos de ellos:


IGP Prefix Segment: Un segmento de significado global el cual es distribuido por los IGPs (IS-IS/OSPF) y cuyo camino es calculado como el más corto hacia un prefijo específico. Esto también le permite operar con ECMP (Equal Cost MultiPath - por sus siglas en Inglés). El valor SID de un prefijo de IGP es configurado por el administrador por interfaz, y es su responsabilidad asegurar que este valor es único en todo el SR domain. Típicamente, el SID sería configurado en interfaces loopback para identificar nodos en la red. Un prefijo de IGP es muy similar a un salto en loose source routing. Esto es mostrado en la Figura 4:



Figura 4: IGP Prefix Segment


IGP Adjacency Segment: Un segmento distribuido por los IGPs (IS-IS/OSPF), el cual describe un enlace en particular, o mejor dicho, una adyacencia IGP entre dos routers. En contraposición a los IGP Prefix Segments, el SID para un Adjacency Segment dado sería asignado por el router mismo, y no requiere intervención alguna por parte del administrador. La instrucción relacionada con este segmento puede ser descrita como “Retira el label y reenvía el paquete al IGP adjacency”. Un segmento de IGP Adjacency es muy similar a un salto en strict source routing, como se muestra en la Figura 5:

Figura 5: IGP Adjacency Segment


Colocar más labels representando segmentos del mismo tipo en un paquete, provee esencialmente, la misma funcionalidad que IP Source Routing posee: Segmentos múltiples de IGP Prefix no son más que Loose Source Routing; segmentos multiple de IGP Adjacency no son más que Strict Source Routing - pero basados en etiquetado MPLS, y, por supuesto, provistos con suficiente reserva de MTU, sin el límite establecido  de Source Routing de 9 saltos explícitos.


Lo que podría no ser obvio es que los labels para cada tipo de segmento pueden ser combinados libremente y colocados en un paquete! Esta combinación es una colección de todo lo que Source Routing era capaz de lograr, y provee espacio amplio para escenarios más complejos de Source Routing, incluyendo caminos de backup y similares a desvíos con fast-reroute donde el tráfico puede ser manipulado mientras va a través de la red y asi poder para maniobrar alrededor de una falla. Un escenario simple es mostrado en la Figura 6:


Figura 6: Combinando Prefix y Adjacency segments


BGP Prefix Segment: Similar al segmento IGP Prefix y manteniendo un valor global, el segmento BGP Prefix representa el camino más corto a un prefijo BGP específico y, por supuesto, es capaz de operar con ECMP. En contraposición al segmento de IGP Prefix, el cual es anunciado por un IGP, este segmento es anunciado por BGP.

Figura 7: BGP Segment


Ya que los Prefix Segments (IGP Prefix y BGP Prefix) tienen un valor y significado global, era necesario considerar que routers MPLS podrían reservar el mismo rango de labels para el despliegue de SR, y podría no ser posible que todos los routers serían capaces de usar el mismo label para el mismo segmento. Hay varias razones para eso: Fabricantes diferentes podrían asignar rangos diferentes por defecto; el despliegue gradual de SR en una red MPLS operativa podría encontrarse con el problema obvio de que el rango de labels esté parcialmente utilizado, o que los rangos están configurados de manera diferente en los routers (no uniforme). Por lo tanto, los Prefix Segments presentan otro nivel de oblicuidad: cada router anuncia su propio rango reservado de labels para Prefix Segments en sus paquetes link-state, y este rango es llamado Segment Routing Global Block (SRGB). Los Prefix segment IDs son anunciados como offsets, o índices, desde el principio del rango de labels, en lugar de valores absolutos. Típicamente, el rango SRGB comienza en 16.000 y esto es lo que llamamos el SRGB por defecto.


¿Cómo esto ayuda? Si se observa la Figura 4 nuevamente, el router más a la derecha es mostrado anunciando el prefix segment para el prefijo 5.5.5.5/32 como 16005. En realidad, el router anunció que su propio SRGB comienza en 16000, y que el índice para ese prefijo 5.5.5.5/32 es 5 (16.005 = 16000 +5). Si todos los routers en el SR domain hacen uso del mismo rango SRGB, ellos siempre llegaran al mismo label de 16.005 cuando se reenvíen paquetes a lo largo del camino hacia 5.5.5.5/32. Sin embargo, si el router la parte superior, al medio de la figura, usase un SRGB que comience en 20000, su propio SID para este prefijo sería 20.005 (20.000 + 5). Cada vecino de este router sabría esto, ya que el SRGB de cada router es anunciado en sus paquetes link-state. Entonces, cuando un vecino reenviase paquetes hacia 5.5.5.5/32 a traves del router del medio, sabiendo que el índice de este prefijo es 5 y que el router usa un SRGB que comienza en 20.000, el mismo usaría 20.0005 en lugar de 16.005. Nuevamente, con IDs globales, los routers que los originan anuncian su índice en lugar de su valor absoluto; el valor real para ser usado en el label es calculado como el índice más el SRGB base del siguiente salto.


Resumiendo: Segment Routing es capaz de lograr exactamente lo mismo que MPLS por sí mismo puede, y brinda consigo un nuevo paradigma de codificar el state del reenvío en el mismo paquete por medio del label stack, abriendo una nueva área de aplicaciones posibles. Desde la perspectiva del control plane, Segment Routing se apoya en extensiones realizadas a los protocolos de enrutamiento link-state para anunciar los ID de cada segmento, y para proveer conocimiento detallado sobre la topología de la red, la cual es requerida para lograr operaciones relacionadas con source routing. Cada segmento representa una instrucción de reenvío que es descartada una vez que la tarea es complida, y, ya que los segmentos considerados en cada salto son los que se encuentran en la parte superior del label stack, los labels son descartados una vez que sus tareas son realizadas y el reenvio es logrado, este proceso es repetido hasta que el paquete llega a su destino. Reducir la complejidad operacional al mismo tiempo que se simplifica el proceso de reenvío le confiere a Segment Routing una posición positiva entre los ISPs, considerado como una tecnología atractiva para su implementación en ambientes complejos, donde la simplificación puede marcar la diferencia en operaciones del dia a dia y lograr satisfacer los acuerdos de servicio difíciles contratados por clientes exigentes.


Este artículo fue escrito con la intención de proveer una introducción ligera en el tópico, ahondando fuertemente en los orígenes de Segment Routing en lugar de sus características avanzadas, y no cubre los tópicos avanzados o despliegues con Path Computation Element (donde Segment Routing demuestra su capacidad de estar listo para SDNs) en conjunción con BGP-LS, o características relacionadas al data plane como Topology Independent LFA y muchas otras. Esas vendrán después - ¡manténganse sintonizados!


¡Cualquier feedback, comentario, preguntas y correcciones son bienvenidas!


Versión en Inglés: Introduction to Segment Routing