Copyright

Enrutamiento de segmentos Parte II - Ingeniería de tráfico

por Clarence Filsfils, Kris Michielsen, François Clad, Daniel Voyer

Copyright© 2019 Cisco Systems, Inc. y/o sus filiales. Todos los derechos reservados.

Reservados todos los derechos. Ninguna parte de este libro puede ser reproducida, distribuida o transmitida de
ninguna forma o por ningún medio, electrónico o mecánico, incluyendo fotocopia, grabación o por cualquier
sistema de almacenamiento y recuperación de información, sin permiso escrito del editor o del autor, excepto
para la inclusión de breves citas en una reseña.

Edición Kindle v1.1, mayo de 2019

Advertencia y descargo de responsabilidad
Se ha hecho todo lo posible para que este libro sea lo más completo y preciso , pero no implica ninguna
garantía ni adecuación.

LA INFORMACIÓN CONTENIDA EN EL PRESENTE DOCUMENTO FACILITA "TAL CUAL", SIN

NINGÚN TIPO DE GARANTÍA O DECLARACIÓN, EXPRESA, IMPLÍCITA O LEGAL, INCLUIDAS,
ENTRE OTRAS, LAS GARANTÍAS DE NO INFRACCIÓN, COMERCIABILIDAD O IDONEIDAD PARA UN
FIN DETERMINADO.
El editor y los autores no tendrán ninguna obligación ni responsabilidad ante ninguna persona o entidad
respecto a cualquier pérdida o daño derivado de la información contenida en este libro.

Los puntos de vista y opiniones expresados en este libro pertenecen a los autores o a la persona que se cita.
Reconocimiento de marcas
Cisco y el logotipo de Cisco son marcas comerciales o marcas registradas de Cisco y/o sus filiales en el
[Link]. y otros países. Para ver una lista de las marcas comerciales de Cisco, visite esta URL:
[Link]/go/trademarks. Las marcas comerciales de terceros mencionadas pertenecen a sus
respectivos propietarios. El uso de la palabra socio no implica una relación de asociación entre Cisco y
cualquier otra empresa. (1110R)

Todos los términos mencionados en este libro que se sabe que son marcas comerciales o marcas de servicio se
han escrito con las mayúsculas correspondientes. Los autores no pueden garantizar la exactitud de esta
información. El uso de un en este libro no debe considerarse que afecte a la validez de ninguna marca
comercial o de servicio.
Prefacio
Este libro es la segunda parte de la serie sobre enrutamiento por segmentos (SR).

A medida que aumenta el número de proveedores de servicios y empresas que utilizan una única
infraestructura de red para dar soporte a un número cada vez mayor de servicios, la capacidad de adaptar el
transporte a las necesidades de las aplicaciones es de vital importancia.

En este , los operadores de redes llevan años explorando técnicas de ingeniería de tráfico, pero es evidente que
se han topado con muchos problemas de escalabilidad que les impiden tener un control exhaustivo y detallado de
los innumerables servicios que ofrecen.

La Ingeniería de Tráfico de Enrutamiento por Segmentos (SR-TE) ha cambiado las reglas del juego y se ha
convertido en la solución indiscutible para ofrecer capacidades de Ingeniería de Tráfico a escala.
Audiencia
Hemos intentado que este libro sea accesible a un público amplio y aborde temas para principiantes,
intermedios y avanzados. Esperamos que sea de utilidad para cualquiera que intente diseñar, dar soporte o
simplemente comprender SR-TE desde una perspectiva práctica. Esto incluye a diseñadores, ingenieros,
administradores y operadores de redes, tanto en entornos de proveedores de servicios como de empresas, así
como a otros profesionales o estudiantes que deseen adquirir conocimientos sobre SR-TE.

Hemos asumido que los lectores están familiarizados con las redes de datos en general, y con los conceptos de
IP, enrutamiento IP y MPLS, en particular. Hay muchos buenos libros disponibles sobre estos temas.

También hemos asumido que los lectores conocen los fundamentos del Enrutamiento por Segmentos. La Parte I
de esta serie de libros SR (disponible en [Link]) es un gran recurso para aprender los fundamentos SR.
Descargo de responsabilidad
Este libro sólo refleja la opinión de los autores y no la de la empresa para la que trabajan. Cada afirmación hecha
en este libro es una conclusión extraída de la investigación personal de los autores y de pruebas de laboratorio.

Considera también lo siguiente:

Algunos ejemplos se han construido con imágenes prototipo. Es posible que en el momento de la
publicación, algunas funciones y comandos aún no estén disponibles de forma general. Cisco Systems no se
compromete a liberar ninguna de funcionalidades descritas en este libro. Para algunas funcionalidades esto se
indica en el texto, pero no para todas. El positivo es que este libro ofrece un anticipo del estado de la técnica
y te da la oportunidad de hacerte una idea de lo que puede estar por venir.

Es posible que algunos de los comandos utilizados en este libro se modifiquen o queden obsoletos en el .
No se garantiza la exactitud de la sintaxis.

Con ilustrativos, los autores se tomaron la libertad de editar algunos de los de salida de comandos, por
ejemplo, eliminando partes del texto. Por esta razón, los ejemplos de este libro no tienen una exactitud
garantizada.
Revisores
Muchas personas han contribuido a este libro y se les reconoce en el capítulo de Introducción. Para que un libro
sea preciso, claro y agradable de leer, se necesitan muchos ojos, además de los de sus autores.

En este punto queremos dar las gracias especialmente a las personas que han revisado este libro en sus distintas
etapas hacia la finalización. Sin ellos, este libro no habría alcanzado el nivel que tiene ahora. Un sincero
"¡Gracias!" a todos.

Por orden alfabético:

Mike DiVincenzo, Alberto Donzelli, Darren Dukes, Muhammad Durrani, Rakesh Gandhi, Arkadiy Gulko, Al
Kiramoto, Przemyslaw Krol, Sakthi Malli, Paul Mattes, Hardik Patel, Rob Piasecki, Carlos Pignataro, Robert
Raszuk, Joel E. Roberts, JC Rode, Aisha Sanes, Grant Socal, Simon Spraggs, YuanChao Su, Ketan Talaulikar,
Mike Valentine, Bhupendra Yadav, Frank Zhao y Qing Zhong.
Convenciones textuales
Este libro tiene múltiples flujos:

Flujo general: Es el flujo regular de contenidos que seguiría un lector deseoso de aprender RS. Contiene
hechos, no opiniones y es de naturaleza objetiva.

Resaltados: Los recuadros resaltados destacan elementos y temas importantes para el lector. Se presentan en
un cuadro "destacado".

DESTACAR

Este es un ejemplo de lo más destacado.

Opiniones: Este contenido expresa opiniones, opciones y compensaciones. Este contenido no es necesario
para entender la RS, pero aporta algo más de información al lector interesado y se presenta en forma de
citas. También hemos invitado a colegas del sector que han participado muy activamente en el proyecto de
RS a compartir sus opiniones sobre la RS en general o sobre algunos aspectos concretos. El nombre de la
persona que da esa opinión se indica en cada cuadro de cita.

"Esta es una opinión de ejemplo.

"
- Juan Nadie

Recordatorios: Los recordatorios explican brevemente aspectos tecnológicos (en su mayoría ajenos a la
RS) que pueden ayudar a comprender el flujo general. Se presentan en un recuadro "recordatorio".

RECORDATORIO

Este es un ejemplo de recordatorio

Ilustraciones y ejemplos Convenciones
Las ilustraciones y ejemplos de este libro siguen las siguientes convenciones:

Router-id de NodoX es 1.1.1.X. Otros loopbacks tienen la dirección 1.1.n.X, siendo n un índice.

La dirección IPv4 de una interfaz en NodoX conectada a NodoY es 99.X.Y.X/24, con X< Y. Por ejemplo, un
enlace que conecta el Nodo2 al Nodo3 tiene una dirección de red [Link]/24; la dirección de interfaz en el
Nodo2 es [Link] y en el Nodo3 es [Link].

Los Prefix-SID son etiquetas en el rango de 16000 a 23999. Este es el Segment Routing Global Block
(SRGB) por defecto en los dispositivos Cisco.

Los SID locales explícitos son etiquetas en el rango [15000-15999]. Este es el Segment Routing Local
Block (SRLB) por defecto en los dispositivos Cisco.

Los SID de adyacencia dinámica son etiquetas en el rango [24000-24999] y tienen el formato 240XY para
una adyacencia en X que va a Y.

Los Binding-SID dinámicos son etiquetas en el rango [40000-40999].

Los EPE Peering-SID dinámicos de BGP son etiquetas en el rango [50000-50999].

Las etiquetas dinámicas asignadas por otras aplicaciones MPLS (no SR) como LDP, RSVP-TE, BGP-LU, etc.,
están en el rango [90000-99999].

Las listas SID se escriben como <S1, S2, S(3)>, ordenadas de la primera a la última, es decir, de arriba abajo
para la pila de etiquetas MPLS SR.
Enrutamiento por segmentos, Parte II
Índice
Copyright

Prefacio

1 Introducción

1.1 Introducción subjetiva de la Parte I

1.2 Algunos términos

1.3 Objetivos de diseño

1.3.1 Una solución optimizada para IP

1.3.2 Una solución sencilla

1.3.3 Una solución escalable

1.3.4 Una solución modular

1.3.5 Una solución innovadora

1.4 Garantía de nivel de servicio (SLA)

1.5 Matriz de tráfico

1.6 Planificación de la capacidad

1.7 Dependencia centralizada

1.7.1 Caminos disjuntos

1.7.2 Entre dominios

1.7.3 Corredor de ancho de banda

1.7.4 Optimización multicapa

1.8 Una TE Intent como SID o lista de SID

1.9 Política de RS

1.10 SID vinculante

1.11 ¿Cuántos SID y funcionará?

1.12 Automatización basada en rutas de servicio coloreadas

 1.13 El proceso SR-TE

1.13.1 Un proceso, múltiples funciones

1.13.2 Componentes

1.13.3 Base de datos SR-TE

1.13.4 Algoritmos nativos SR

1.13.5 Interacción con otros procesos y API externas

1.13.6 Nueva interfaz de línea de comandos (CLI)

1.14 Programación de servicios

1.15 Equipo de operadores principales

1.16 Equipo SR-TE Cisco

1.17 Normalización

1.18 Flujo de este libro

1.19 Referencias
Sección I - Fundación 2
Política de RS

2.1 Introducción

2.1.1 Una ruta candidata explícita de una política SR

2.1.2 Validación y selección de rutas

2.1.3 Una ruta candidata dinámica de bajo retardo

2.1.4 Una ruta candidata dinámica que evita enlaces específicos

2.1.5 Codificación de una ruta en una lista de segmentos

2.2 Modelo de política de RS

2.2.1 Lista de segmentos

2.2.2 Trayectorias de los candidatos

2.3 Segmento de encuadernación

2.4 Configuración de la política SR

 2.5 Resumen

2.6 Referencias

3 Trayectoria explícita del candidato

3.1 Introducción

3.2 Etiquetas SR-MPLS

3.3 Descriptores de segmento

3.4 Validación de rutas

3.5 Consideraciones prácticas

3.6 Ruta candidata iniciada por el controlador

3.7 Migración TDM

3.8 Trayectorias disjuntas en dos planos mediante Anycast-SID

3.9 Resumen

3.10 Referencias

4 Trayectoria dinámica del candidato

4.1 Introducción

4.1.1 Expresión del objetivo y las restricciones de la ruta dinámica

4.1.2 Calcular ruta= Resolver problema de optimización

4.1.3 Algoritmos SR nativos frente a algoritmos basados en circuitos

4.2 Computación distribuida

4.2.1 La cabecera calcula la ruta de bajo retardo

4.2.2 La cabecera calcula rutas restringidas

[Link] Colores de los enlaces de afinidad

[Link] Restricción de afinidad

4.2.3 Otros casos de uso y limitaciones

[Link] Rutas disjuntas limitadas a una única cabecera

[Link] La ruta entre dominios requiere información multidominio

 4.3 Cálculo centralizado

4.3.1 SR PCE

[Link] SR PCE Redundancia

4.3.2 SR PCE calcula rutas disjuntas

[Link] Grupo disjunto

[Link] Solicitud de ruta, respuesta e informe

[Link] Delegación de ruta

4.3.3 SR PCE calcula rutas entre dominios de extremo a extremo

[Link] Capacidad multidominio de SR PCE

[Link] SR PCE calcula la ruta entre dominios

[Link] SR PCE Actualiza la ruta entre dominios

4.4 Resumen

4.5 Referencias

5 Dirección automática

5.1 Introducción

5.2 Colorear una ruta BGP

5.2.1 Comunidad ampliada de color BGP

5.2.2 Colorear rutas BGP en el PE de salida

5.2.3 Conflicto con el uso de otros colores

5.3 Dirección automática de un prefijo VPN

5.4 Gestión de múltiples prefijos con diferentes ANS

5.5 Dirección automatizada para EVPN

5.6 Otras rutas de servicio

5.7 Desactivar AS

5.8 Aplicabilidad

5.9 Resumen
 5.10 Referencias

6 Siguiente salto a petición

6.1 Colorear

6.2 Instanciación de rutas candidatas a la carta

6.3 Integración perfecta en la solución SR-TE

6.4 Desmontando la ruta de un candidato a ODN

6.5 Ilustración: ODN intrazona

6.6 Ilustración: ODN entre dominios

6.7 ODN Sólo para colores autorizados

6.8 Resumen

6.9 Referencias

7 Algoritmo flexible

7.1 Algoritmos Prefijo-SID

7.2 Definición del algoritmo

7.2.1 Coherencia

7.2.2 Definición Publicidad

7.3 Cálculo de trayectorias

7.4 Ruta de copia de seguridad TI-LFA

7.5 Integración con SR-TE

7.5.1 ODN/AS

7.5.2 Rutas entre dominios

7.6 Caso práctico de las rutas disjuntas de doble plano

7.7 Caso práctico de Flex-Algo Anycast-SID

7.8 Resumen

7.9 Referencias

8 Resistencia de la red
 8.1 Detección local de fallos

8.2 Inundación IGP intradominio

8.3 Inundación BGP-LS entre dominios

8.4 Validación de una ruta explícita

8.4.1 Segmentos expresados como descriptores de segmento

8.4.2 Segmentos expresados como valores SID

8.5 Recálculo de una ruta dinámica por una cabecera

8.6 Recálculo de una ruta dinámica mediante un PCE SR

8.7 Convergencia IGP a lo largo de un prefijo-SID constitutivo

8.7.1 Recordatorio IGP

8.7.2 Trayectoria explícita del candidato

8.7.3 Rutas dinámicas de los candidatos

8.8 Anycast-SIDs

8.9 Protección TI-LFA

8.9.1 Prefijo constituyente-SID

8.9.2 Constituyente Adj-SID

8.9.3 TI-LFA aplicado a Flex-Algo SID

8.10 Política de RS sin protección

8.11 Otros mecanismos

8.11.1 SR IGP Evitación de microbucle

8.11.2 Detección de caducidad de la política SR

8.11.3 Protección TI-LFA para una SID intermedia de una política SR

8.12 Concurrencia

8.13 Resumen

8.14 Referencias

Sección II - Información complementaria

9 Vinculación-SID y SRLB

9.1 Definición

9.2 Asignación explícita

9.3 Simplificación y ampliación

9.4 Opacidad de la red e independencia del servicio

9.5 Dirección hacia un túnel RSVP-TE remoto

9.6 Resumen

9.7 Referencias

10 Más detalles sobre la dirección automática

10.1 Rutas de servicio con varios colores

10.2 Colorear rutas de servicio en PE de entrada

10.3 Dirección automatizada y rutas múltiples BGP

10.4 Dirección sólo en color

10.5 Resumen

10.6 Referencias

11 Autopista y dirección basada en políticas

11.1 Autoroute

11.2 Pseudowire Ruta preferida

11.3 Ruta estática

11.4 Resumen

11.5 Referencias

12 Base de datos SR-TE

12.1 Visión general

12.2 Cabecera

12.3 SR PCE

12.3.1 BGP-LS
 12.3.2 PCEP

12.4 Consolidación de una topología multidominio

12.4.1 Límite de dominio en un nodo

12.4.2 Límite de dominio en un enlace

12.5 Resumen

12.6 Referencias

13 SR PCE

13.1 Proceso SR-TE

13.2 Despliegue

13.2.1 Configuración SR PCE

13.2.2 Configuración de la cabecera

13.2.3 Recomendaciones

13.3 Cálculo centralizado de rutas

13.3.1 Trayectoria iniciada por la cabecera

13.3.2 Trayectoria iniciada por el PCE

13.4 Trayectoria basada en aplicaciones

13.5 Alta disponibilidad

13.5.1 La cabecera informa a todos los PCE

13.5.2 Detección de fallos

13.5.3 La cabecera vuelve a delegar las rutas a un PCE alternativo en caso de fallo

[Link] Caminos iniciados por la cabecera

[Link] Vías basadas en aplicaciones

13.5.4 Sesión PCEP de sincronización de estados Inter-PCE

[Link] Ilustración de State-Sync

[Link] Cerebro partido

13.6 BGP SR-TE

 13.7 Resumen

13.8 Referencias

14 SR BGP Egress Peer Ingeniería

14.1 Introducción

14.2 SR BGP Ingeniería de pares de salida (EPE)

14.2.1 Propiedades SR EPE

14.3 Tipos de segmentos

14.4 Configuración

14.5 Distribución de la información EPE en BGP-LS

14.5.1 TLV de SID de peering BGP

14.5.2 Sesión BGP de un solo salto

14.5.3 Sesión BGP multisalto

14.6 Casos prácticos

14.6.1 Política SR mediante Peering-SID

14.6.2 SR EPE para rutas de política SR entre dominios

14.7 Resumen

14.8 Referencias

15 Supervisión del rendimiento - Retraso de enlace

15.1 Marco de medición del rendimiento

15.2 Componentes del retardo de enlace

15.3 Medición del retardo del enlace

15.3.1 Formato de la sonda

15.3.2 Metodología

15.3.3 Configuración

15.3.4 Verificación

15.4 Retraso Publicidad

 15.4.1 Métrica de retardo en IGP y BGP-LS

15.4.2 Configuración

15.4.3 Informes detallados de retrasos en telemetría

15.5 Uso del retardo de enlace en SR-TE

15.6 Resumen

15.7 Referencias

16 Operaciones SR-TE

16.1 Reparto ponderado de la carga dentro de la ruta política SR

16.2 Caída por política de SR no válida

16.3 Operaciones SR-MPLS

16.3.1 Primer segmento

16.3.2 PHP y Explicit-Null

16.3.3 MPLS TTL y Traffic-Class

16.4 SRGB no homogéneo

16.5 Candidatos con la misma preferencia

16.6 Resumen

16.7 Referencias
Sección III - Tutoriales
17 BGP-LS

17.1 Escenario de despliegue de BGP-LS

17.2 Modelo de topología BGP-LS

17.3 Anuncio BGP-LS

17.3.1 BGP-LS NLRI

[Link] Campo Protocol-ID

[Link] Campo Identificador

17.3.2 Nodo NLRI

 17.3.3 Enlace NLRI

17.3.4 Prefijo NLRI

17.3.5 TE Política NLRI

17.3.6 Atributo Link-State

17.4 SR BGP Egress Peer Ingeniería

17.4.1 PeerNode SID Anuncio BGP-LS

17.4.2 PeerAdj SID Anuncio BGP-LS

17.4.3 PeerSet SID Anuncio BGP-LS

17.5 Configuración

17.6 Topología ISIS

17.6.1 Nodo NLRI

17.6.2 Enlace NLRI

17.6.3 Prefijo NLRI

17.7 Topología OSPF

17.7.1 Nodo NLRI

17.7.2 Enlace NLRI

17.7.3 Prefijo NLRI

17.8 Referencias

18 PCEP

18.1 Introducción

18.1.1 Breve historia del PCEP

18.2 Configuración y mantenimiento de la sesión PCEP

18.2.1 Sincronización del estado de la política SR

18.3 Configuración y mantenimiento de la ruta de la política SR

18.3.1 Ruta de política SR iniciada por PCC

18.3.2 Ruta de la política SR iniciada por el PCE

 18.3.3 El PCE actualiza la vía política SR

18.4 Mensajes PCEP

18.4.1 Mensaje abierto del PCEP

18.4.2 Mensaje de cierre del PCEP

18.4.3 Mensaje PCEP Keepalive

18.4.4 Mensaje de solicitud PCEP

18.4.5 Mensaje de respuesta del PCEP

18.4.6 Mensaje del informe del PCEP

18.4.7 Mensaje de actualización del PCEP

18.4.8 Mensaje de inicio de PCEP

18.4.9 Objeto de asociación de disociación

18.5 Referencias

19 BGP SR-TE

19.1 SR Política Dirección-Familia

19.1.1 Política de RS NLRI

19.1.2 Atributo de encapsulación del túnel

19.2 Política SR Operaciones BGP

19.2.1 Selección de la mejor ruta BGP

19.2.2 Utilización del campo distintivo NLRI

19.2.3 Nodo de cabecera de destino

19.3 Ilustraciones

19.3.1 Ilustración Distintivo NLRI

[Link] Mismo Distintivo, mismo NLRI

[Link] Distintivos distintos, NLRI distintos

19.4 Referencias

20 Telemetría
 20.1 Configuración de telemetría

20.1.1 Qué datos transmitir

20.1.2 Dónde enviarlo y cómo

20.1.3 Cuándo enviarla

20.2 Recopiladores y análisis

20.3 Referencias

Sección IV - Apéndices

A. Introducción del libro SR Parte I

A.1 Objetivos del Libro

A.2 ¿Por qué empezamos SR?

A.3 Influencias de SDN y OpenFlow

A.4 100% de cobertura para IPFRR y ruta de reparación óptima

A.5 Otras prestaciones

A.6 Equipo

A.7 Simplificar las cosas

A.8 Normalización y consenso entre varios proveedores

A.9 Etiqueta mundial

A.10 MPLS SR

A.11 SRv6

A.12 Beneficios para la industria

A.13 Referencias

B. Confirmación de la intuición del libro SR Parte I

B.1 Chubasquero y botas en un día soleado

B.2 ECMP-Concienciación y diversidad

Hitos
Índice Inicio del
contenido
1 Introducción
Este capítulo está escrito por Clarence Filsfils de subjetiva.

Describe las intuiciones, los objetivos de diseño y los casos de uso previstos que condujeron a la definición de
la solución SR-TE. Comparte la experiencia de diseño adquirida durante el despliegue de esta solución.
1.1 Introducción subjetiva de la Parte I
El Apéndice A proporciona una copia no modificada de la introducción subjetiva de la Parte I de esta
serie de libros SR tal y como se escribió en 2016. En ella se describen las intuiciones y los objetivos de
diseño de la solución global Segment Routing.

Específicamente para este libro y el tema de la Ingeniería de Tráfico, la introducción de Parte I describe:

Problemas de escalabilidad y complejidad del concepto de malla completa RSVP-TE

Diferencia entre la solución de ingeniería de tráfico SR y el modelo de circuito RSVP-TE

La diferencia entre la solución SR Traffic Engineering y OpenFlow

El Apéndice B se ha redactado en abril de 2019. En él se ofrecen algunos datos públicos que se dieron a
conocer después de la publicación de la Parte I y que confirman sus intuiciones y análisis.
1.2 Algunos términos
SR-TE hace referencia a la solución Segment Routing Traffic Engineering.

Esta solución traduce la intención del operador (retardo, disyunción, ancho de banda) en "políticas de SR",
programa estas políticas de SR en la red y dirige el tráfico hacia la política de SR adecuada.

Una Política SR es fundamentalmente una lista de segmentos. En su forma más simple, se trata de una
secuencia de waypoints IP expresados como segmentos SR-MPLS (o SRv6), también denominados Segment
IDs o SIDs. Una lista de segmentos, o lista SID, se representa como <S1, S2, ...>, donde S1 es el primer
segmento a visitar.

Una intención SR-TE, definida como un objetivo de optimización y un conjunto de restricciones, se traduce en
una lista de segmentos b un motor de cálculo. El motor de cálculo puede ser un enrutador o un elemento de
cálculo de ruta (PCE, denominado SR PCE en contexto de un despliegue SR). El primer caso da lugar a una
solución distribuida, mientras que el segundo da lugar a una solución centralizada. Una solución híbrida
combina la computación en el enrutador y en el SR PCE.

La lista SID que implementa una intención SR-TE se denomina Lista SID de la solución.
1.3 Objetivos de diseño
Estos son los objetivos que hemos seguido para el proyecto SR-TE.

1.3.1 Una solución optimizada para IP

Antes de SR-TE, IP siempre se había diseñado con circuitos subyacentes punto a punto no ECMP orientados
a la conexión: Frame-Relay, ATM y, posteriormente, RSVP-TE MPLS LSP. Un objetivo claro del proyecto
SR es aprovechar IP y sus propiedades (como ECMP) para diseñar el tráfico IP.

SR expresa una ruta explícita como una lista ordenada de rutas más cortas ECMP a puntos intermedios IP.
Utiliza puntos de paso IP para construir una solución de ingeniería IP. Como los waypoints están basados en
IP, se benefician de las propiedades de IP (como ECMP). Esto proporciona una solución optimizada para IP.

Al estar diseñada para IP, la solución SR-TE es directamente aplicable a cualquier instanciación de SR: SR-
MPLS (plano de datos MPLS) o SRv6 (plano de datos IPv6). En este libro, proporcionamos todos los
conceptos e ilustraciones para SR-MPLS. Sin embargo, puede estar seguro de que todos los conceptos
también se aplican directamente a SRv6. La Parte III de esta serie de libros SR está dedicada a SRv6 y
proporcionará las de SRv6-TE.

1.3.2 Solución sencilla

Muy pocos operadores tenían acceso a la tecnología TE basada en circuitos debido a su elevado coste de
explotación y a su complejidad. Un objetivo claro del proyecto SR es ampliar drásticamente la aplicabilidad
de , utilizable por cualquier operador IP.

En el corazón de los servicios de red se encuentran las rutas de servicio basadas en BGP. ¿Cómo podemos
automatizar la solución SR-TE en torno a estas rutas de servicio? Simplemente etiquetamos las rutas BGP con
un color que expresa su intención de SLA. Configuramos algunas plantillas que definen el SLA asociado a
cada color y dejamos que BGP y SR-TE resuelvan por sí mismos. Si un encaminador no tiene suficiente
información para calcular una ruta por sí mismo, solicita ayuda automáticamente a un SR PCE.

El retraso es un requisito fundamental de los SLA. ¿Cómo podemos automatizar el cálculo de los SLA
comerciales expresados en retardo (retardo mínimo o coste mínimo con un límite en el retardo)?
Automatizamos la medición y señalización de los retrasos en enlaces unidireccionales, y definimos reglas que
preservan la estabilidad del sistema de encaminamiento.
Estas primeras preguntas en nuestro viaje SR-TE impulsaron nuestra investigación y nuestra ingeniería. La
eficacia de la solución ha quedado demostrada por un amplio despliegue.

La sencillez ha sido siempre nuestra prioridad en todo el proyecto SR. En el contexto de la solución SR-TE,
esto se tradujo en:

Supervisión integrada del rendimiento por enlace y por política

OAM integrado

Contadores y telemetría integrados, que eliminan la necesidad de Netflow/IPFIX para obtener la matriz de
demanda

Automatización de la política de RS (denominada ODN)

Automatización de la dirección del servicio BGP en una política SR (denominada AS)

1.3.3 Solución escalable

Se elimina la inescalabilidad y complejidad de RSVP-TE. es decir:

k× N2 estados en el tejido (malla completa entre N nodos de borde, k túneles para cada par de nodos para
hackear la falta de ECMP nativo en un circuito RSVP)

competiciones de carreras al cambiar la topología de la red

la noción de túnel

En su lugar, SR-TE ofrece una solución sin estado que admite la dirección del tráfico y el empuje de la pila de
etiquetas sin degradación del rendimiento. También incluye algoritmos SR-native eficientes que reducen la
complejidad computacional, al tiempo que minimizan la longitud de la lista SID de la solución y maximizan la
diversidad ECMP.

1.3.4 Solución AModular

El análisis abstracto nos ayuda a aislar cada en sus bloques de construcción fundamentales. Programamos
nuestro trabajo de ingeniería de forma que los bloques de construcción se desarrollen de forma independiente y
con las API que permiten su combinación. Flex-Algo, ODN, AS, SR PCE, algoritmos SR nativos, TI-LFA son
varios de ellos.
ejemplos de esta descomposición de la solución global en bloques de construcción independientes. TI-LFA
puede utilizarse con o sin Flex-Algo. ODN puede utilizarse con o sin SR PCE y AS. Flex-Algo combinarse con
ODN y AS, o utilizarse de forma independiente.

Otro aspecto de esta modularidad es el soporte de diversos modelos de despliegue.

Centralizada ("vertical"): un controlador SDN toma todas las decisiones de forma centralizada y programa la
red en consecuencia. Los routers reciben sus listas SID de explícita.

Distribuido: el enrutador traduce dinámicamente una intención de SLA en una lista de SID. El
enrutador utiliza algoritmos nativos SR para calcular la lista SID de la solución a partir de la
información de la base de datos SR-TE.

Híbrido ("horizontal"): al instalar una ruta de servicio BGP coloreada, un enrutador detecta la necesidad de
una política SR y solicita a un PCE SR que calcule la lista SID que implementa el SLA requerido para ese
servicio. El enrutador dirige automáticamente el tráfico de servicio en la política SR instanciada
dinámicamente.

A menudo nos referimos a los modelos primero y último como "vertical" y horizontal".

El modelo "vertical" tiene un "sistema dios" que lo supervisa todo, decide y programa. La red es
relativamente pasiva y toda la inteligencia está en el sistema SDN central.

El modelo de inteligencia "horizontal" es la suma de muchos componentes que interactúan. Los reflectores de
rutas BGP distribuyen las rutas BGP coloreadas. Los reflejadores de rutas BGP-LS s(1) distribuyen la
información topológica de los distintos dominios. Los PCEs SR escuchan el sistema redundante de reflejo de
rutas BGP-LS para actualizar su DB SR-TE. Los PEs escuchan a los reflejadores de rutas BGP para conocer los
destinos de servicio BGP, endpoints y colores SLA. Los PEs escuchan los anuncios SR PCE para saber quiénes
son y dónde están. Al recibir una ruta BGP coloreada al siguiente salto N con el color C de SLA, bajo demanda
(dinámicamente), el PE solicita a uno de SR PCE descubiertos una solución de política SR para el punto final N
con el color C. El SR PCE se hace responsable de esta política SR (la solicitud es de estado) y actualiza el PE si
la lista SID de la solución cambia. Cualquiera de los componentes puede escalarse horizontalmente. Si hay más
PEs o más rutas BGP, entonces pueden añadir reflectores de rutas adicionales. Si hay más dominios, se pueden
añadir reflejadores de rutas BGP-LS adicionales. Si hay más PEs o más políticas SR dentro de una región,
entonces pueden añadir PCEs SR adicionales en esa región.
El modelo horizontal también se denomina "híbrido" porque es una combinación de la inteligencia centralizada
de la "SDN vertical" (de hecho, tenemos SR PCE que ayudan a realizar cálculos "centrales" entre dominios) con
la inteligencia distribuida (el reflejo de rutas BGP en color, el reflejo de rutas BGP-LS, la disponibilidad de
muchos SR PCE concurrentes).

En el momento de escribir este , los dos modelos tienen un amplio despliegue. El primero se adapta mejor al
contexto WEB/OTT, mientras que el segundo encaja mejor en el mercado SP/Enterprise. Sabíamos los
distintos operadores tendrían preferencias diferentes y que cada solución tendría sus pros y sus contras. En
lugar de decantarnos arbitrariamente por una única opción, decidimos ser agnósticos. Diseñamos la solución
global con un conjunto de componentes comunes.

Dado que las implantaciones de SR-TE pueden seguir varios modelos, la solución también admite distintos
protocolos de plano de control.

Del controlador a la red: PCEP, BGP SR-TE y Protocolo de Configuración de Red (NETCONF) y la
flexibilidad para adaptarse a otras tecnologías API/de señalización según la evolución del sector.

De red al controlador: Telemetría, BGP-LS, PCEP y NETCONF.

Una nota específica sobre BGP-LS, la familia de direcciones BGP Link-state. A menudo se considera que
BGP-LS se limita a permitir que un conjunto de enrutadores IGP en un área IGP transporten la LS-DB IGP a
través de un canal BGP a los controladores. En nuestra arquitectura SR-TE, BGP-LS tiene un papel mucho
más amplio: proporciona un canal entre cada router independiente y los controladores para reportar cualquier
información local al router, su topología inmediata de una manera que es independiente de la presencia o no
de un IGP (por ejemplo, aplicabilidad a Centros de Datos basados en BGP), el estado de sus Políticas SR (por
ejemplo, aplicabilidad más allá de la topología inmediata del router), las capacidades del nodo (por ejemplo,
cuántos segmentos puede empujar/insertar) , distribución de medidas de rendimiento (por ejemplo, retardo),
etc.

Por ejemplo, cuando se construye una Política SR interdominio desde un dominio Metro1 a un dominio Metro2
a través del dominio core, el SR PCE quiere aprovechar cualquier Política SR de tránsito disponible en el core.
Para ello, el SR PCE necesita conocer todas las SR disponibles en el dominio core. Esto es sencillo gracias a
una sesión BGP-LS desde cualquier cabecera de política SR a uno de los reflectores de ruta BGP-LS
(RRs). Cualquier SR PCE peering a uno de los RRs BGP-LS obtendrá todas las Políticas SR instanciadas en el
dominio SR.

1.3.5 Una solución innovadora

Un ingrediente clave que se recordó continuamente al equipo de SR es pensar con originalidad

Un concepto de TE "in-the-box" es pensar que es necesario un túnel, que es necesaria una malla completa, que
los túneles tienen que estar preconfigurados, que la dirección se hace con autoroute y que un túnel no es
ECMP... Se lleva haciendo así 20 años, debe ser el punto de partida

No. Estos conceptos no deben asumirse "ciegamente".

1.4 Garantía de nivel de servicio (SLA)
El objetivo de cualquier tecnología de ingeniería de tráfico es permitir garantías de nivel de servicio (SLA). Un
SLA se define como una combinación de requisitos en términos de retardo de extremo a extremo, pérdida,
ancho de banda y disyunción. Algunos de estos requisitos están parcial o totalmente controlados por el
encaminamiento, mientras que otros también se ven afectados por factores externos la utilización de la red.

El retardo de extremo a extremo está compuesto por el retardo de propagación y retardo de programación y(2). El
retardo de propagación se calcula dividiendo la longitud de la fibra por la velocidad de la luz en el medio. Es
independiente de la utilización de la red y está totalmente controlado por el encaminamiento: minimizar el retardo
de propagación acumulado entre dos nodos de la red equivale a encontrar un camino entre estos nodos con la
mínima longitud de fibra acumulada. Por otro lado, el retardo de programación representa la longitud de la cola
dividida por la velocidad del puerto. Este componente del retardo de propagación se ve afectado por la
utilización del enlace, así como por la estrategia de programación. Un operador que desee minimizar el retardo
de programación se asegurará de que los enlaces de red tengan capacidad suficiente y de que el tráfico sensible
al retardo se dirija a una cola específica.

La pérdida de paquetes también comprende un componente independiente de la congestión y otro

dependiente de ella. La primera está causada por un defecto del cable o de la conexión, mientras que la
segunda es el resultado de la acumulación de colas más allá de su límite. La pérdida independiente de la
congestión puede ser monitorizada por cada router en base a cada enlace y notificada como parte de su
actualización de topología (por ejemplo, atributos TE extendidos ISIS/OSPF). Cualquier enrutador o PCE
que tenga acceso a esta información puede calcular una ruta a través de la red que garantice que la pérdida
independiente de la congestión se mantiene por debajo de un determinado umbral. El cálculo de esta ruta es
un problema de encaminamiento.

Del mismo modo, los caminos disjuntos -que sí comparten tipos específicos de recursos como enlaces, nodos
o Grupos de Enlaces de Riesgo Compartido (SRLGs)- se calculan basándose en el conocimiento de la
topología y sus SRLGs. Se trata de un problema de encaminamiento.

Lo mismo ocurre con la inclusión o exclusión de determinados tipos de recursos a lo largo de una ruta. Por
ejemplo, un subconjunto de enlaces de una topología puede admitir cifrado MACSec (IEEE 802.1AE). La
intención de "utilizar únicamente enlaces protegidos por MACSec" se traduce en una restricción para excluir de
ruta todos los enlaces no protegidos por MACSec, lo que vuelve a ser un problema de encaminamiento.
En este libro, nos centramos en los problemas de encaminamiento. Estos toman como entrada una base de
datos de topología aumentada que puede contener la topología de red de múltiples dominios, datos de medición
de retrasos y pérdidas, así como información de políticas como afinidades SRLG y TE.
1.5 Matriz de tráfico
Una demanda (de tráfico) D(X, Y) es la cantidad de tráfico que entra en la red por el nodo de borde de entrada
X y sale de la red por el nodo de borde de salida Y.

La matriz de demanda (también llamada matriz de tráfico) contiene todas las demandas que atraviesan la red.
Tiene tantas filas como nodos de entrada y tantas columnas como nodos de salida. La demanda D(X, Y) es la
celda de la matriz situada en la fila X y la columna Y.

Está claro que simplificar el proceso de recogida de la matriz de demanda es un objetivo clave del proyecto SR-
TE.

Las dos soluciones utilizadas hasta ahora eran muy complejas y no eran escalables. Se necesitaban expertos
para configurarlas y utilizarlas.

La primera solución consistió en ejecutar una malla completa de túneles RSVP-TE desde cualquier borde a
cualquier borde, dirigiendo todo el tráfico en estos túneles y recogiendo los contadores de tráfico del túnel.
Todos estos túneles estaban configurados con un ancho de banda cero y seguían el camino más corto del IGP.
Por lo tanto, toda la red estaba gobernada por un problema de escalado N2 sólo para conseguir incrementar
algunos contadores. Esto una solución muy ineficiente y, de hecho, un hack.

La segunda solución consiste en ejecutar NetFlow/IPFIX en cada interfaz externa de todos los nodos de borde
de la red y transmitir la información de flujo a los controladores para la deducción de la matriz de demanda. A
diferencia de la solución de malla completa del túnel RSVP-TE, no se trata de un pirateo. El tráfico no se
modifica y sigue siendo dirigido por el IGP. La información de tráfico obtenida a través de la solución
NetFlow/IPFIX puede ser útil para muchas soluciones distintas de la planificación de la capacidad, por
ejemplo, para el análisis de la seguridad. El problema práctico: no todas las interfaces externas de todos los
nodos de borde soportan NetFlow/IPFIX y los colectores y procesadores NetFlow/IPFIX requieren cierta
inversión y soporte dedicados. En conclusión, si la solución NetFlow/IPFIX no está motivada por otras
razones, parece demasiado compleja y cara sólo para derivar la matriz de demanda.

Como parte del proyecto SR, diseñamos una solución automatizada para derivar la matriz de demanda en
cualquier despliegue de Segment Routing.

Desde una perspectiva de alto nivel, la idea es relativamente simple. Cualquier enrutador SR X marca sus
interfaces como internas o externas. Para cualquier paquete recibido en una interfaz externa, si X enruta el
paquete hacia un
BGP destino B/b a través de un nodo de borde de salida Y, entonces X incrementa D(X, Y). A intervalos
regulares (por ejemplo, 15 minutos) X almacena estos contadores D(X, *) en una tabla histórica local.
Periódicamente, un controlador puede recuperar estas tablas históricas de todos los encaminadores y deducir
fácilmente la evolución de la matriz de demanda a lo largo del tiempo.

Esta información puede recopilarse a través de Telemetría (véase el capítulo 20, "Telemetría") o NETCONF.
1.6 Planificación de la capacidad
La planificación de la capacidad es el arte continuo de prever la carga de tráfico, también en condiciones de
fallo, con el fin de hacer evolucionar la topología de la red, su capacidad y su encaminamiento para cumplir
un acuerdo de nivel de servicio (SLA) definido.

La entrada al proceso consiste en descubrir lo siguiente:

la topología y la capacidad bruta de los enlaces

el retardo de propagación medido de los enlaces (medición del rendimiento)

los grupos de enlace de riesgo compartido (SRLG)

la matriz de demanda

Los SRLG representan los fallos concurrentes probables que hay que tener en cuenta. La matriz de demanda
representa el tráfico que atraviesa la red, esencialmente el tráfico que va de cada nodo de entrada a cada nodo de
salida.

Una solución de planificación de la capacidad muy conocida es Cisco WAN Automation Engine (WAE) Planning
[Cisco WAE].

Históricamente, la solución de planificación de la capacidad era un proceso fuera de línea. Por ejemplo, cada
trimestre se simula la demanda de tráfico prevista a 6 ó 12 meses para todos los posibles fallos de la red (enlace,
nodo y SRLG). La capacidad adicional se solicita en consecuencia para garantizar que no se produce ninguna
congestión dentro del crecimiento previsto de la matriz de tráfico y los fallos de red esperados. A menudo, el
proceso es mucho más sencillo y se basa en reglas empíricas como "mejorar un enlace en cuanto alguna medida
de tráfico máximo promediado supere un determinado umbral".

Con un proceso semiautomatizado, la solución de planificación de la capacidad pasa a estar "en línea": recoge
continuamente todas las entradas descritas anteriormente y comprueba si se mantiene el SLA objetivo. Si se
supera un umbral, la solución de planificación de la capacidad emite una alerta al operador y puede proponer
una solución táctica de ingeniería del tráfico. El operador sigue interviniendo para evaluar la situación validar
la solución propuesta. La solución a largo plazo sigue siendo añadir capacidad para gestionar el crecimiento
de la red, pero el operador dispone ahora de una solución para gestionar un aumento inesperado del tráfico o
un fallo inesperado de la red.
Con el proceso automatizado, las políticas tácticas de gestión del tráfico se programan en la red automáticamente
cuando es necesario, necesidad de validación por parte del operador.
1.7 Dependencia centralizada
Se necesita un punto de vista de cálculo "central" para los siguientes casos: caminos disjuntos, interdominio,
intermediación de ancho de banda y optimización multicapa.

En este libro, nos centramos en el cálculo central realizado por el SR PCE.

1.7.1 Caminos disjuntos

Se necesita un punto de vista común (central) para calcular rutas disjuntas a partir de nodos origen/cabecera
separados.

Por ejemplo, el pseudohilo 1 (PW1) de A a C en la Figura 1-1 debe ser disjunto del PW2 (de B a D). Los nodos
A y B no pueden calcular individualmente una ruta que cumpla este requisito, ya desconocen el
comportamiento del otro nodo.

Figura 1-1: Trayectorias disjuntas

La solución consiste en que estos dos nodos (A y B) se pongan en contacto con el mismo SR PCE y le pidan
que calcule ambos caminos disjuntos y comunique la solución a cada cabecera respectiva.

El SR PCE calcula los caminos P1 y P2, respectivamente de A a C y de B a D, y se asegura de que P1 sea

disjunto de P2. A continuación, proporciona estos caminos respectivamente a A y B. El SR PCE stateful
realiza un seguimiento de este SLA de diversidad de caminos y vuelve a calcular los caminos P1 y P2 en caso
de cambio de topología.

1.7.2 Entre dominios

Se requiere un punto de vista centralizado (que abarque todos los dominios) cuando la política SR va de una
cabecera a un punto final que se encuentran en dos dominios aislados (por ejemplo, sin redistribución entre
dominios, sin BGP RFC3107).

Se requiere un punto de vista centralizado (que abarque todos los dominios y con información SLA en la DB
SR-TE) cuando la política SR va de una cabecera a un punto final que están en dos dominios aislados y se
requiere un SLA específico (por ejemplo, retardo mínimo, evitar enlaces azules). En este caso, la conectividad
best-effort entre dominios (redistribución, BGP RFC3107) no es de ayuda. Se requiere un cálculo de ruta
centralizado para encontrar una lista SID que implemente una ruta entre dominios que satisfaga el requisito
SLA.

Se podría decir que esto es teóricamente incorrecto. De hecho, es cierto que la cabecera del primer dominio
puede acceder a los reflectores de rutas BGP-LS y, por lo tanto, obtener la topología completa entre dominios
con la información sobre retrasos. Sin embargo, en la práctica no hemos visto este modelo de despliegue. El
diseño típico es mantener las cabeceras calculando ellas mismas para su dominio y pidiendo a sus SR PCEs
cualquier cálculo entre dominios.

1.7.3 Corredor de ancho de banda

Se requiere un controlador centralizado cuando el SLA depende de evitar la congestión y el proceso de
planificación de la capacidad offline no garantiza que siempre haya suficiente ancho de banda disponible.

En tal caso, los routers individuales no pueden coordinar, de eficiente y escalable, la asignación de su tráfico
respectivo para evitar la congestión. Se necesita un intermediario de ancho de banda central para coordinar la
asignación de ancho de banda. Se requiere una técnica de optimización centralizada para optimizar la
asignación del ancho de banda.
MPLS RSVP-TE utiliza una técnica de señalización salto a salto para establecer el estado por circuito en la red y
reservar ancho de banda. Aunque esta técnica de control de admisión evita la congestión, crea problemas de
escala (k × N2).

Como ya se ha mencionado, un objetivo de diseño de SR-TE es eliminar los circuitos no IP y su problema de

escalado de estado. En lugar de colocar el estado en la red para implementar un mecanismo de control de
admisión distribuido, SR-TE utiliza un controlador centralizado que actúa como corredor de ancho de banda.
El agente de ancho de banda centralizado recibe las solicitudes de ancho de banda de los routers
individuales, realiza seguimiento del ancho de banda disponible en la red y enruta las solicitudes en
consecuencia.

Los detalles internos de la solución del corredor de ancho de banda son específicos de cada aplicación y rara
vez se hacen públicos.

Algunos ejemplos de controladores SR conscientes del ancho de banda son [Cisco WAE], [Google
Espresso], [Facebook EdgeFabric], y [Alibaba NetO], y [Microsoft SWAN].

1.7.4 Optimización multicapa

Se requiere un punto de control centralizado cuando se consideran topologías combinadas L1-L3. Casos como
el Link Augmentation o el bypass de nodos L3 son algunos ejemplos.
1.8 ATE Intent como SID o lista de SID
En la primera presentación pública que hicimos sobre SR (octubre de 2012), describimos dos formas
fundamentales de expresar una intención de TE con enrutamiento de segmentos: con un único SID de
Flex-Algo o con varios SID.

Empecemos con los SID múltiples, ya que probablemente sea lo más intuitivo.

Si la ruta más corta de Tokio a Bruselas pasa por [Link]. (por ejemplo, menor coste de los bits transportados),
la ruta de bajo retardo puede expresarse probablemente con la política SR< toMoscow, toBrussels> como se
muestra en
Figura 1-2, toMoscow es el primer segmento y representa el camino más corto de Tokio a Moscú.
toBrussels es el segundo segmento y representa la ruta más corta de Moscú a Bruselas.

Figura 1-2: Ruta de bajo retardo Tok yo - Bruselas - utilizando SIDs de ruta más corta IGP

El motor de cálculo (un router o un SR PCE) recoge la topología y sus segmentos y expresa la intención (la
Política SR) como una lista SID. El punto principal a recordar aquí es que cada segmento prefijo expresa un
camino más corto según la métrica IGP básica.

Existe otra forma de abordar el problema: definir segmentos adicionales que tengan propiedades TE
específicas (es decir, segmentos de prefijo que no sigan el camino más corto IGP).

Supongamos lo siguiente:
 cada encaminador supervisa el retardo de propagación de cada uno de sus enlaces

el retardo de propagación de cada enlace es inundado por el IGP

cada nodo IGP se configura con un segundo SID que se inunda con el atributo "delay

cada nodo IGP calcula el camino más corto de un SID de "retardo" con el retardo de propagación por enlace

"toBrussels(Delay)" indica el SID "delay" para Bruselas

Entonces, es fácil deducir que la política SR de bajo retraso de Tokio a Bruselas puede expresarse con un único
SID "toBrussels(Delay)".

Un SID de este tipo se denomina SID "IGP Flex-Algo" (véase el capítulo 7, "Algoritmo flexible") y se basa en
lo siguiente:

IGP porque el IGP calcula el camino más corto relacionado (por ejemplo, el retraso mínimo) e inunda la
información relacionada dentro del dominio IGP.

Algo para Algoritmo porque asociamos una intención específica de TE al SID, expresada como un objetivo
de optimización (un algoritmo). Cada objetivo se identifica con un número Algo.

Flex porque cualquier operador es libre de definir la intención de cada Flex-Algo que instancie

El operador 1 puede definir Algo128 para minimizar la métrica TE y excluir la afinidad roja

El operador 2 puede definir Algo128 para minimizar la métrica de retraso y excluir la afinidad azul

La misma intención (política de la RE) puede expresarse como< aMoscú, aBruselas> o

<aBruselas(Retraso)>. Véase la figura 1-3.
 Figura 1-3: Trayecto de bajo retardo Tok yo - Bruselas - utilizando SID de bajo retardo

Una intención también puede expresarse como una lista SID de SID Flex-Algo. Supongamos que Moscú y
Tokio se encuentran en el dominio asiático, mientras que Bruselas y se encuentran en el dominio europeo.
Una ruta interdominio de bajo retardo de Tokio a Bruselas podría expresarse como <aMoscú(Retardo),
aBruselas(Retardo)>. Pero puede que en dominio asiático, el camino más corto IGP de Tokio a Moscú sea
también el camino de bajo retardo, mientras que en el dominio europeo el camino más corto IGP de Moscú a
Bruselas no esté en el camino de bajo retardo. En ese , la política de SR de extremo a extremo podría
expresarse como
<aMoscú, aBruselas(Retraso)>. Véase la figura 1-4.
 Figura 1-4: Trayecto de bajo retardo Tok yo - Bruselas - combinando diferentes SID de algoritmo

Así es, la solución SR-TE consiste en combinar cualquier SID para expresar la intención. Si es posible hacerlo
con un solo SID, se hará. Si se necesitan varios SID, también está bien. Si se necesitan varios SID de distinta
naturaleza, también está bien.

La solución funciona como los ladrillos multicolor y multiforma de los juguetes de construcción LEGO® .
Los SID IGP son los ladrillos amarillos. Los ladrillos amarillos implementan un camino más corto de coste
mínimo-IGP. Los SID IGP de Flex- Algo1 son los ladrillos de color rojo. Los ladrillos rojos implementan un
camino más corto de retardo mínimo.
Los SID IGP de Flex-Algo2 son ladrillos de verde. Los ladrillos verdes implementan un camino más corto
de coste mínimo IGP restringido al plano verde de la red. Los ladrillos azules implementan un camino más
corto de coste mínimo IGP restringido al plano azul de la red. Dependiendo de la intención, la solución
utiliza diferentes bloques. Además, la solución puede combinar bloques de diferentes colores (por ejemplo,
como parte de una política entre dominios). Esta es la riqueza inherente de la solución y esto es exactamente
lo habíamos propuesto en la primera presentación de SR en Cisco NAG en octubre de 2012.

No hay que pensar que IGP Flex-Algo se opone a SR-TE. Es una parte inherente de la solución SR-TE.
Históricamente, se introdujo en la primera presentación de SR en octubre de 2012.
1.9 Política de RS
En SR-TE no existe el concepto de túnel. En su lugar, introducimos el concepto de Política SR. Una

Política SR realiza una intención TE mediante una lista SID de solución.

Los SIDs que forman parte de la lista SID pueden ser de cualquier tipo: SID IGP, SID IGP Flex-Algo, SID

BGP, ... Una política SR se identifica por los tres atributos siguientes:

cabecera: donde se instancia la política

endpoint: dónde termina la política: una dirección IPv4/v6

color 3: representa una intención y es un nuevo concepto fundamental para automatizar SR-

TE En una cabecera, una Política SR se identifica por la tupla (color, endpoint).

La cabecera de una política SR vincula un SID vinculante a la política.

La cabecera de una política SR válida instala la política SR en el plano de reenvío como una reescritura MPLS:

(etiqueta entrante= Binding SID→ POP and PUSH Solution SID list)
1.10 SID vinculante
El SID vinculante (BSID) es fundamental para el enrutamiento por segmentos. Proporciona escalabilidad,
opacidad de red e independencia de servicio.

Figura 1-5: DC Inter-Connect con SLA y sin BGP entre dominios

Ilustremos estos beneficios con el diagrama de la Figura 1-5 donde DCI1 tiene una política SR de bajo retardo
"Pol1" a DCI3 con lista SID <Prefix-SID(D), Adj-SID(D-a-E), Prefix-SID(DCI3)> y con un Binding SID
BSID(Pol1).

En este contexto, una política SR multidominio de bajo retardo de S a Z se expresa simplemente como <Prefijo-
SID(DCI1), BSID(Pol1), Prefijo-SID(Z)>.

Sin la ventaja de la política SR de núcleo intermedio, S tendría que dirigir su flujo de bajo retardo a la
política SR con la lista SID< Prefix-SID(DCI1), Prefix-SID(D), Adj-SID(D-to-E), Prefix- SID(DCI3),
Prefix-SID(Z)>.

El uso de un BSID (y la Política SR de tránsito) disminuye el número de segmentos impuestos por la fuente.

Un BSID actúa como un punto de anclaje estable que aísla un dominio de la agitación de otro dominio.

En caso de cambios de topología en el núcleo de la red, la ruta de bajo retardo de DCI1 a DCI3 puede cambiar.
Mientras que la ruta de una política intermedia cambia, su BSID no cambia. Por lo tanto, la política utilizada
por la fuente no cambia y la fuente está protegida de los cambios en otro dominio.
Un BSID proporciona opacidad e independencia entre dominios. La autoridad administrativa del dominio
central puede querer ejercer un control total sobre los trayectos a través de este dominio para poder realizar una
planificación de la capacidad e introducir TE para los SLA que proporciona a los dominios hoja. El uso de un
BSID permite mantener el servicio opaco. S no conoce los detalles de cómo el central proporciona el servicio
de bajo retardo. S no es consciente de la necesidad de la autoridad central de cambiar temporalmente la ruta
intermedia.
1.11 ¿Cuántos SID y funcionará?
Supongamos que un router S sólo puede empujar 5 etiquetas y un intento de TE requiere una lista SID de 7
etiquetas <S1, S2, S3, S4, S5, S6, S7> donde estas etiquetas son SIDs de prefijos IGP a los respectivos nodos
1, 2, 3, 4, 5, 6 y 7.

¿Estamos atascados? No, por dos razones: SID vinculante y SID Flex-Algo.

La primera solución es clara, ya que aprovecha las propiedades del SID de enlace (Figura 1-6 (a)).

Figura 1-6: Soluciones para gestionar el límite de imposición de etiquetas

La lista SID en el nodo de cabecera pasa a ser <S1, S2, S3, S4, B> donde B es el SID vinculante de una
política <S5, S6, S7> en el nodo 4. La lista SID en el nodo de cabecera cumple la restricción de 5 etiquetas
de ese nodo.

Aunque un SID vinculante y una política en el nodo 4 añaden estado al núcleo para una política en el borde, el
estado no es por política de borde. Por lo tanto, un único SID vinculante B para la política <S5, S6, S7> puede
ser reutilizado por muchas políticas de nodo de borde.
La segunda solución es igualmente sencilla: instanciar la intención en los nodos de la red como algoritmo IGP
Flex-Algo adicional (digamos AlgoK) y asignar un segundo SID S7' al nodo 7 donde S7' es
asociado con AlgoK (Figura 1-6 (b)). Claramente, la lista SID se convierte ahora en <S7'> y sólo requiere
una etiqueta para empujar ☺.

Estos dos conceptos garantizan que una intención pueda expresarse como una Política SR que cumpla con
las capacidades de la cabecera (por ejemplo, max push ≤ 5 etiquetas).

Al detallar la solución SR-TE, explicamos cómo se descubren las características de los nodos (cuántas
etiquetas pueden empujar) y cómo los algoritmos de optimización tienen en cuenta esta restricción.

último, es importante recordar que la mayoría de los ASIC de reenvío modernos pueden empujar al menos 5
etiquetas y que la mayoría de los casos de uso requieren menos de 5 etiquetas (basado en un extenso análisis
de varios casos de uso relacionados con TE en topologías ISP). Por lo tanto, este problema no suele ser una
limitación real en la práctica.
1.12 Automatización basada en rutas de servicio coloreadas
Una intuición clave en la base de la simplicidad y automatización de nuestra solución SR-TE ha sido situar
las rutas BGP en el centro de nuestra solución. Esa idea surgió durante un viaje en taxi en Roma con Alex
Preusche y Alberto Donzelli.

Las rutas BGP proporcionan accesibilidad a los servicios: Internet, L3VPN, PW, L2VPN.

Permitimos al operador marcar las rutas BGP con colores. Por lo tanto, cualquier ruta BGP tiene un siguiente
salto y un color.

El siguiente salto indica adónde tenemos que ir.

El color es un atributo de color extendido expresado como valores de 32 bits. El color indica cómo debe ir el
siguiente salto. Define una intención de TE SLA.

Un operador asigna a cada color la intención TE SLA que desee. Un ejemplo probable es:

Sin color: "best-effort"

Rojo: "bajo retardo"

Supongamos que el operador marca una ruta BGP 9/8 vía [Link] con color rojo mientras que la ruta BGP 8/8
vía
[Link] se deja sin colorear.

Al recibir la ruta 8/8, el Nodo 1 instala 8/8 vía 16005 (prefijo-SID de [Link]) en la FIB. Este es el
comportamiento clásico. El tráfico a 8/8 toma la ruta IGP a [Link] que la ruta de mejor esfuerzo (menor coste).

Al recibir la ruta 9/8, el Nodo 1 detecta que la ruta tiene un color rojo que coincide con una plantilla local TE
SLA roja. Como tal, el proceso BGP solicita al proceso TE la Política SR local con (color
= red; punto final= [Link]). Si esta política de SR aún no existe, proceso TE la instanciará bajo demanda. Ya
sea preexistente o instanciada bajo demanda, el proceso TE devuelve finalmente una política SR al proceso
BGP. El proceso BGP instala entonces 9/8 en la política SR devuelta. El tráfico a 9/9 toma la política SR roja a
[Link] que proporciona la ruta de bajo retardo al nodo 5.
La instalación de una ruta BGP en una política SR se denomina direccionamiento automatizado (AS). Se trata
de una simplificación fundamental, pues ya no es necesario recurrir a complejas construcciones de enrutamiento
basadas en políticas.

La instanciación dinámica de una Política SR basada en una plantilla de color y un punto final se denomina On-
Demand Next-hop (ODN). Se trata de una simplificación fundamental, ya que no es necesario preconfigurar
ninguna política de SR. En su lugar, todos los nodos de borde se configuran con las mismas plantillas.
1.13 El proceso SR-TE
La solución SR-TE está implementada en los sistemas operativos de los routers Cisco (Cisco IOS XR, Cisco
IOS XE, Cisco NX-OS) como un proceso completamente nuevo (es decir, diferente e independiente de MPLS
RSVP- TE).

En este libro, explicamos en detalle la implementación SR-TE de IOS XR. Hemos garantizado la
coherencia entre las implementaciones de los tres sistemas operativos y, por tanto, los conceptos se pueden
aplicar fácilmente a las plataformas IOS XE y NX-OS.

1.13.1 Un proceso, múltiples funciones

El proceso SR-TE admite múltiples funciones:

Dentro de la cabecera: SR-TE cerebro del router (como decisor local).

Base de datos de topología limitada a su dominio local

Posiblemente contenga una base de datos topológica multidominio, pero aún no se ha visto en la práctica.

Fuera de la cabecera: SR PCE (ayuda a los routers para la disyunción de rutas o políticas entre dominios)

Esta capacidad multirol es muy similar al proceso BGP en el SO del router:

BGP cerebro del router (recibe ruta e instalar las mejores rutas en RIB)

BGP Route Reflector (ayuda a los routers a recopilar todas las rutas)

En el caso de BGP, un router fronterizo se conecta a un reflector de rutas (RR) para obtener todas sus rutas
BGP. El router fronterizo y el reflector de rutas ejecutan el mismo sistema operativo y utilizan el mismo
proceso BGP. El router fronterizo utiliza el proceso BGP como cabecera local, para la selección de rutas BGP y
la instalación de entradas de reenvío. El reflector de rutas utiliza el proceso BGP sólo para agregar rutas y
refleja mejores.

Esto es muy similar para SR-TE.

En el caso SR-TE, un router fronterizo (cabecera en lenguaje SR-TE) ejecuta el proceso SR-TE para
gestionar sus políticas, calcula la lista SID cuando puede, solicita ayuda a un PCE SR cuando no puede, y
finalmente instala las entradas de reenvío para las rutas activas de sus políticas.
El SR PCE ejecuta el mismo proceso SR-TE pero en modo PCE. En este caso, el proceso SR-TE suele
recopilar más información topológica de múltiples dominios (por ejemplo, para el cálculo de rutas entre
dominios) y proporciona servicios centralizados de cálculo de rutas para múltiples cabeceras.

La posibilidad de utilizar una única arquitectura e implementación coherentes para múltiples funciones o
casos de uso es una gran ventaja.

Sin embargo, inicialmente puede parecer confuso. Por ejemplo, hagámonos la siguiente pregunta: ¿tiene el
router la topología multidominio? Hay tres respuestas posibles:

No. El router sólo tiene información del dominio local y pide ayuda al SR PCE para las políticas entre
dominios.

Sí. El router es un PCE SR y para cumplir este papel agrega la información de múltiples dominios.

Sí. El router es una cabecera, pero el operador ha decidido proporcionar información multidominio
directamente a esta cabecera de forma que calcule las políticas interdominio por sí misma (sin ayuda de
SR PCE).

La arquitectura e implementación de SR Process permite estos tres casos de uso.

En este librote guiamos a través de los distintos casos de uso y te ofrecemos pistas subjetivas y experiencia
para identificar qué casos de uso son los más comunes. Por ejemplo, aunque la última respuesta es posible
desde el punto de vista de la arquitectura y es probable que acabe implantándose, por ahora este diseño no ha
planteado en los debates sobre su implantación.

Otra pregunta probable puede ser: "¿Es el SR PCE una instancia virtualizada en un servidor?". Dos respuestas
son posibles:

Sí. Un SR PCE no necesita instalar ninguna política en su plano de datos. Sólo tiene un papel en el plano
de control. Por lo tanto, puede ser más escalable y rentable ejecutarlo como una instancia virtual.

No. puede habilitar un rol SR PCE en un router físico de la red. El router ya está presente, ya tiene el
proceso SR-TE, el operador aprovecharlo como un rol SR PCE adicional.
De nuevo, esto es muy similar al rol RR de BGP: puede ser virtualizado en un servidor o habilitado en un router
físico.

1.13.2 Componentes
A alto nivel, el proceso SR-TE comprende los siguientes componentes:

Base de datos SR-TE

Base de datos de política local:

Múltiples rutas candidatas por política recibidas a través de múltiples canales (BGP, PCEP, NETCONF,
CLI)

Proceso de validación

Proceso de selección

Asociación SID vinculante (BSID)

Cálculo dinámico de rutas: los algoritmos nativos de SR

Instanciación de políticas a la carta (ODN)

Instalación de políticas en FIB

Dirección automática (AS)

Informes políticos

BGP-LS

Telemetría

NETCONF/YANG

1.13.3 Base de datos SR-TE

Un componente clave del proceso SR-TE es la base de datos SR-TE (SR-TE DB).
El proceso SR-TE recopila información topológica de ISIS/OSPF y BGP-LS y almacena esta información en la
base de datos SR-TE (SR-TE DB).

Hemos diseñado la base de datos SR-TE para que multidominio.

Esto significa que el proceso SR-TE debe ser capaz de consolidar en la BD SR-TE la información topológica de
múltiples dominios, descartando al mismo tiempo la información redundante.

La DB SR-TE también está diseñada para contener algo más que la información topológica, incluye lo
siguiente:

Segmentos (Prefix-SIDs, Adj-SIDs, Peering SIDs)

Atributos de enlace TE (como métrica TE, métrica de retardo, SRLG, color de enlace de afinidad)

Políticas remotas (para aprovechar una política en un dominio central como política de tránsito una política
interdominio de extremo a extremo entre dos dominios de acceso diferentes, un PCE SR DEBE conocer
todas las políticas instaladas en la red que son elegibles para su uso como política de tránsito).

1.13.4 Algoritmos nativos SR

Se trata de un tema muy importante.

Los algoritmos para traducir una intención (por ejemplo, bajo retardo) en una lista SID no tienen nada que
ver con los algoritmos de circuito utilizados por ATM/FR PNNI o MPLS RSVP-TE.

Los algoritmos nativos SR tienen en cuenta las propiedades de cada segmento disponible en la red, como el
algoritmo de segmentos o la diversidad ECMP, y calculan las rutas como secuencias de segmentos en lugar de
enlaces de reenvío.

Los algoritmos nativos SR se implementan en el proceso SR-TE y, por tanto, se aprovechan en modo cabecera
o SR PCE.

1.13.5 Interacción con otros procesos y API externas

El proceso SR-TE tiene numerosas interacciones con otros procesos del SO del router y con entidades
externas a través de APIs.
Estas interacciones se clasifican como una función de cabecera de router ("cabecera") o una función SR PCE
("SR PCE"). Estas indicaciones son indicativas/subjetivas, ya que son posibles muchos otros casos de uso.

Figura 1-7: Interacción de SR-TE con otros procesos y API externas

ISIS/OSPF

La cabecera descubre la topología de estado de enlace del dominio local

BGP-LS

SR PCE descubre información de topología de estado de enlace de dominio local/remoto

SR PCE descubre políticas SR en dominios locales/remotos

La cabecera informa de sus políticas de RS programadas localmente y de su estado

La cabecera descubre la topología de estado de enlace del dominio local (por ejemplo, SR BGP-only DC)

PCEP

La cabecera solicita un cálculo de ruta al PCE SR

 A la inversa, SR PCE recibe una solicitud de cálculo de trayecto

La cabecera aprende una ruta del SR PCE

Por el contrario, SR PCE señala un camino a la cabecera

La cabecera informa de sus políticas locales de RS al PCE de RS

BGP-TE

La cabecera aprende una ruta del SR PCE

Por el contrario, SR PCE señala un camino a la cabecera

NETCONF

La cabecera aprende una ruta del SR PCE

Por el contrario, SR PCE señala un camino a la cabecera

SR PCE descubre SR Políticas de la cabecera

A la inversa, las señales de la cabecera SR Políticas al SR PCE

FIB

La cabecera instala una política en el plano de datos

Ruta de servicio BGP y equivalente (Layer-2 Pseudowire) para fines de dirección automatizada

El proceso BGP de la cabecera al proceso SR-TE una política SR (Endpoint, color)

El proceso SR-TE de la cabecera comunica las políticas SR-TE locales válidas al proceso BGP

API Northbound para orquestación y visibilidad de alto nivel (SR PCE)

Aplicaciones Cisco WAE, Packet Design LLC, etc.

Volveremos sobre estas diferentes interacciones y APIs a lo largo de este libro y las ilustraremos con ejemplos.

1.13.6 Nueva interfaz de línea de comandos (CLI)

La CLI de SR-TE en IOS XR 6.2.1 y superior se ha diseñado para ser intuitiva y minimalista. Difiere

fundamentalmente de la clásica CLI RSVP-TE de MPLS en IOS XR.

1.14 Programación de servicios
Aunque detallaremos la noción de programación de redes" y, por tanto, de "programación de servicios" en la
Parte III de esta serie de libros sobre SR, es importante entender que la solución Service Function Chaining
(SFC) está totalmente integrada dentro de la solución SR-TE.

La solución para aplicar una política topológica de control del tráfico sin estado a través de una red es la
misma que la solución para aplicar un programa de servicios sin estado.

Llamamos "Función de Red (NF)" a una aplicación/función proporcionada por un dispositivo hardware o una
Máquina Virtual (VM) o Contenedor. Una NF puede residir en cualquier lugar dentro del dominio SR. Puede
estar cerca del acceso o centralizada dentro de un DC.

Utilizamos el término "programa de servicios" en lugar del clásico "cadena de servicios" porque la solución
SR-TE integrada para TE y SFC ofrece más que una simple cadena secuencial.

La solución SR permite la misma expresión que un lenguaje de programación moderno: admite bifurcaciones
flexibles basadas en condiciones ricas. Un ejemplo de aplicación que aprovecha las capacidades únicas de SR es
el cortafuegos SERA de Linux basado en iptables [SERA]. Este cortafuegos de código abierto puede filtrar
paquetes basándose en su información SR adjunta y realizar acciones específicas de SR, como saltarse uno o
varios de los segmentos restantes. Esto también se ha demostrado con la aplicación de código abierto SNORT.

Aparte de la riqueza de solución de "programa de servicio" SR-TE, también contamos con la ventaja de escala y
simplicidad de SR: el estado se encuentra únicamente en el borde de la red y no se necesita ningún otro
protocolo para admitir soluciones basadas en la virtualización de funciones de red (NFV) (la solución SR-TE
simplemente se reutiliza).

Esto es muy diferente de otras soluciones como Network Service Header (NSH) que instala estado por toda
la red (menos escalable) y crea una nueva encapsulación, lo que resulta en más protocolos, más sobrecarga y
más complejidad.
1.15 Equipo de operadores principales
La solución SR-TE se ha visto influida en gran medida por operadores líderes de todo mundo.

Martin Horneffer, de Deutsche Telecom, es un veterano del sector TE. En 2005, destacó los inconvenientes de
escalabilidad y complejidad de MPLS RSVP-TE y propuso una solución alternativa basada en la planificación
de la capacidad y el ajuste de métricas IGP [IGP Tuning]. Le gusta recordar a la comunidad que el requisito
previo absoluto para un proceso TE es la recopilación fiable y escalable de la información de entrada: los
SRLG ópticos, las métricas de rendimiento por enlace (retardo y pérdida) y la matriz de demanda. Martin ha
influido significativamente en el diseño de SR-TE, centrándose en la automatización y simplificación de la
recopilación de datos y en la relación entre TE y Capacity Planning.

Paul Mattes, de Microsoft, es un veterano de la industria IP y SDN. Su dilatada experiencia en el desarrollo de

código BGP le proporciona una visión clara de la complejidad y la escala de las redes. Su temprana
participación en uno de los principales casos de uso de SDN [SWAN] le dio una idea de cómo SR podría
preservar el beneficio de programación de red introducido por open-flow mientras escalaba significativamente
su operación aprovechando los protocolos de enrutamiento distribuido y sus segmentos de prefijo relacionados.
Paul ha influido significativamente en el diseño de SR-TE, especialmente en cualquier caso de uso que implique
un controlador SR-TE centralizado con aplicaciones de capa superior.

Alex Bogdanov, Steven Lin, Rob Shakir y más tarde Przemyslaw Krol de Google, se han unido al trabajo
iniciado con Paul, han validado los beneficios de BGP SR-TE y han ayudado a refinar muchos detalles mientras
trabajábamos en sus casos de uso. Han influido significativamente en la solución de interfuncionamiento RSVP-
TE/SR-TE bandwidth Broker.

Niels Hanke, de Vodafone Alemania, ha sido un operador líder clave uno de los primeros despliegues de SR-
MPLS. Junto con Anton Karneliuk de Vodafone Alemania, diseñamos la primera entrega mundial de un servicio
de latencia de tres niveles gracias a SR-TE, ODN/AS e IGP SR Flex- Algo. Anton se unió a mí en el evento
Cisco Live!™ 2019 para compartir algo de información sobre este nuevo despliegue. El vídeo está disponible en
nuestro sitio [Link].

Mike Valentine, de un importante cliente de servicios financieros, fue el primero en darse cuenta de la
aplicabilidad de SR en su sector, tanto para simplificar drásticamente la operación como para proporcionar
SLA automatizados de extremo a extremo.
Políticas de SR. Sus contundentes comentarios me ayudaron mucho a convencer a Siva de que "mordiera la
bala", olvidara el código del prototipo original y rediseñara el proceso SR-TE (y su CLI) desde cero.

Stéphane Litkowski, del Grupo Orange, fue nuestro primer usuario de SR PCE. Su pasión y los esfuerzos de
desarrollo conjunto con Siva ayudaron a perfeccionar nuestro diseño y acelerar nuestros planes de producción.

Dan Voyer, de Bell Canada, es un veterano del sector IP/MPLS y SDN, y su equipo ha desplegado una
impresionante red SR en varios dominios. Su caso de uso, que combina el encadenamiento de servicios y
SR- TE y lo aplica a servicios externos como SDWAN, fue una influencia clave en el diseño de SR.

Gaurav Dawra, primero en Cisco y después en LinkedIn, amplió el plano de control de BGP y BGP-LS.
Gaurav también proporcionó información clave sobre el caso de uso de SR-TE en CC y entre CC.

Dennis Cai, de Alibaba, ayudó a la comunidad a comprender el despliegue de SR-TE y la arquitectura de SR

Controller en un contexto WEB. Su presentación está disponible en nuestro sitio [Link].

Arkadiy Gulko, de Thomson Reuters, ha colaborado estrechamente con nosotros para perfeccionar la solución
IGP SR Flex-Algo y demostrar su gran aplicabilidad para requisitos de baja latencia o diversidad.

Como en cualquier presentación pública sobre SR, agradecemos al equipo del operador principal toda su
ayuda en la definición y despliegue de esta novedosa solución de SR.
1.16 Equipo SR-TE Cisco
Siva Sivabalan, Tarek Saad y Joseph Chin trabajaron estrechamente para diseñar e implementar la solución
SR-TE en IOS XR desde cero. Siva Sivabalan sigue liderando todo el desarrollo de SR-TE y su energía ha
sido clave para ofrecer la solución SR-TE a nuestros principales operadores.

A medida que el proyecto y el despliegue se ampliaban, se formó el equipo SR-TE más grande con Mike
Koldychev, Johnson Thomas, Arash Khabbazibasmenj, Abdul Rehman, Alex Tokar, Guennoun Mouhcine, David
Toscano, Bhupendra Yadav, Bo Wu, Peter Pieda, Prajeet G.C. y Jeff Williams.

La solución SR-TE ha sido probada por Zhihao Hong, Vibov Bhan, Vijay Iyengar, Braven Hong, Wanmathy
Dolaasthan, Manan Patel, Kalai Sankaralingam, Suguna Ganti, Paul Yu, Sudheer Kalyanashetty, Murthy
Haresamudra, Matthew Starky, Avinash Tadimalla, Yatin Gandhi y Yong Wang.

François Clad desempeñó un papel clave en la definición de los algoritmos nativos SR.

Junaid Israr, Apoorva Karan, Bertrand Duvivier e Ianik Semco han sido los gestores de proyectos y productos
de SR-TE y han desempeñado un papel decisivo en el proceso de desarrollo. Han orquestado el trabajo en todos
los componentes y API para conseguir una solución única, modular y fácil de manejar.

Jose Liste, Kris Michielsen y Alberto Donzelli apoyaron los primeros diseños y despliegues importantes de SR-
TE. Son excelentes fuentes de comprobación de la realidad para mantener al equipo centrado en los requisitos de
despliegue. Su profesionalidad en la gestión de demostraciones y pruebas de concepto ha sido clave para
nuestra comunicación de estas novedosas ideas.

Frederic Trate ha dirigido nuestra comunicación externa y ha sido una gran fuente de ideas para nuestra
estrategia a largo plazo.

Tim LaBerge influyó en el diseño de SR-TE durante su etapa en Microsoft (en colaboración con Paul Mattes)
y como parte del equipo de desarrollo de Cisco WAE.

Peter Psenak dirigió la implementación de SR IGP Flex-Algo.

Ketan Talaulikar dirigió, junto con Krishna Swamy, la arquitectura e implementación de BGP-LS y el diseño
relacionado con BGP-only.

Zafar Ali dirigió la OAM para SR-TE y nuestra actividad general de SR en el IETF.

Rakesh Gandhi dirigió la supervisión del rendimiento SR-TE.

Sagar Soni y Patrick Khordoc prestaron una ayuda clave en la aplicación del control de resultados.

Dhanendra Jain y Krishna Swamy dirigieron el trabajo de BGP para SR-TE y fueron piezas clave para la
implementación de ODN/AS.

David Ward, SVP y Arquitecto Jefe de Ingeniería de Cisco, fue esencial para materializar la oportunidad con
SR y financiar el proyecto en septiembre de 2012.

Ravi Chandra, SVP Core Software Group, resultó esencial para ejecutar nuestro proyecto más allá de su
primera fase. Ravi ha dirigido el software IOS XR, IOS XE y NX-OS en Cisco. Entendió rápidamente la
oportunidad de SR y lo financió como un programa para toda la cartera. Así pudimos abordar realmente todos
los mercados interesados en SR (operadores WEB de hiperescala, SP y Enterprise) y todos los segmentos de red
(DC, metro/agregación, edge, backbone).

Sumeet Arora, SVP de SP Routing, proporcionó un gran apoyo para ejecutar nuestro proyecto en toda la cartera
de enrutamiento de SP: acceso, metro, core, merchant y silicio Cisco.

Venu Venugopal, Vicepresidente, actuó como nuestro patrocinador ejecutivo durante la mayor parte de la fase de
ingeniería de SR-TE. Desempeñó un papel clave orquestando el compromiso y la entrega efectiva de todos los
componentes de la solución. Hicimos un gran viaje juntos para visitar a Paul y Tim en Microsoft hace unos
años. Allí fue donde se inició el componente BGP-TE.
1.17 Normalización
Como explicamos en la Parte I de esta serie de libros sobre SR, estamos comprometidos con la normalización y
hemos publicado en el IETF todos los detalles necesarios para garantizar la interoperabilidad SR-TE (por
ejemplo, extensiones de protocolo).

Además, hemos documentado una descripción bastante detallada de nuestro comportamiento en los nodos
locales para que los operadores puedan solicitar comportamientos similares a otros proveedores.

[draft-ietf-spring-segment-routing-policy] es el principal documento a tener en cuenta. Describe la arquitectura

SR-TE y sus conceptos clave. Presenta las distintas extensiones del protocolo:

draft-filsfils-spring-sr-traffic-counters

borrador-filsfils-spring-sr-policy-considerations

draft-ietf-idr-bgp-ls-segment-routing-ext

draft-ietf-idr-te-lsp-distribution

draft-ietf-idr-bgpls-segment-routing-epe

draft-ietf-lsr-flex-algo

draft-ietf-pce-segment-routing

draft-sivabalan-pce-binding-label-sid

draft-ietf-pce-association-diversity

draft-ietf-idr-segment-routing-te-policy

RFC8491

RFC8476

draft-ietf-idr-bgp-ls-segment-routing-msd

Consulte la lista completa en [Link]/ietf.

1.18 Flujo de este libro
Este libro se centra en los intentos de SLA que pueden tratarse como un problema de encaminamiento: bajo
retardo, planos disjuntos, inclusión/exclusión de recursos, intra e interdominio.

Relacionamos estas intenciones de SLA con casos de uso y mostramos cómo pueden ser satisfechas por
varias soluciones SR-TE: Política SR-TE con ruta explícita, Política SR-TE con ruta dinámica, SR IGP Flex-
Algo.

Por ejemplo, el servicio dual-plane disjointness puede ser soportado por una ruta explícita aprovechando el SID
anycast por plano, o una ruta dinámica excluyendo una afinidad o por un IGP Flex-Algo habilitado en el plano
elegido.

Los primeros capítulos introducen las nociones de política SR y sus caminos candidatos (estáticos y dinámicos).
A continuación, nos adentramos en el corazón de la solución SR-TE: La política a la carta (ODN) y la dirección
automatizada (AS).

A continuación trataremos el algoritmo SR IGP Flexible, la resistencia de la red y el SID vinculante.

En ese , se habrán cubierto los conceptos clave. El resto del libro es una serie de capítulos que detallan los
temas introducidos anteriormente. Por ejemplo, la noción de base de datos SR-TE se introduce en los
primeros capítulos, ya que es clave para entender cómo los algoritmos SR nativos calculan una lista SID de
soluciones y cómo se valida una ruta candidata explícita. El capítulo 12, "Base de datos SR-TE", retoma este
concepto y lo trata en profundidad.

Hemos optado por este enfoque en dos pasos para facilitar la curva de aprendizaje. Creemos que lo más
importante es entender cuáles son los distintos componentes de la solución SR-TE y cómo interactúan
entre . Una vez comprendido esto, el lector puede centrarse en un componente específico y estudiarlo más
a fondo.
1.19 Referencias
[SR-book-Part-I] "Segment Routing Part I", Clarence Filsfils, Kris Michielsen, Ketan Talaulikar, octubre de
2016, ASIN: B01I58LSUO (Kindle), ISBN-10: 1542369126, ISBN-13: 978-1542369121,
<[Link]
<[Link]

[draft-ietf-spring-segment-routing-policy] "Arquitectura de políticas de enrutamiento por segmentos",

Clarence Filsfils, Siva Sivabalan, Daniel Voyer, Alex Bogdanov, Paul Mattes, draft-ietf-spring-segment-
routing-policy-02 (Trabajo en curso), octubre de 2018.

[draft-ietf-pce-segment-routing] "Extensiones PCEP para el enrutamiento por segmentos", Siva

Sivabalan, Clarence Filsfils, Jeff Tantsura, Wim Henderickx, Jonathan Hardwick, draft-ietf-pce-
segment- routing-16 (Trabajo en curso), marzo de 2019.

[draft-ietf-idr-segment-routing-te-policy] "Publicidad de políticas de enrutamiento por segmentos en BGP",

Stefano Previdi, Clarence Filsfils, Dhanendra Jain, Paul Mattes, Eric C. Rosen, Steven Lin, draft-ietf-idr-
segment-routing-te-policy-05 (Trabajo en curso), noviembre de 2018.

[draft-ietf-idr-bgp-ls-segment-routing-ext] "Extensiones de estado de enlace de BGP para enrutamiento

por segmentos", Stefano Previdi, Ketan Talaulikar, Clarence Filsfils, Hannes Gredler, Mach Chen, draft-
ietf-idr- bgp-ls-segment-routing-ext-12 (Trabajo en curso), marzo de 2019.

[draft-sivabalan-pce-binding-label-sid] "Transporte de etiqueta vinculante/identificación de segmento en

redes basadas en PCE", Siva Sivabalan, Clarence Filsfils, Jeff Tantsura, Jonathan Hardwick, Stefano Previdi,
Cheng Li, draft-sivabalan-pce-binding-label-sid-06 (Trabajo en curso), febrero de 2019.

[draft-ietf-lsr-flex-algo] "Algoritmo flexible de IGP", Peter Psenak, Shraddha Hegde, Clarence Filsfils,
Ketan Talaulikar, Arkadiy Gulko, draft-ietf-lsr-flex-algo-01 (Trabajo en curso), noviembre de 2018.

[RFC8491] "Señalización de la profundidad máxima de SID (MSD) mediante IS-IS", Jeff Tantsura, Uma
Chunduri, Sam Aldrin, Les Ginsberg, RFC8491, noviembre de 2018.

[RFC8476] "Señalización de la profundidad máxima de SID (MSD) mediante OSPF", Jeff Tantsura, Uma
Chunduri, Sam Aldrin, Peter Psenak, RFC8476, diciembre de 2018.
[draft-ietf-idr-bgp-ls-segment-routing-msd] "Señalización de MSD (profundidad máxima de SID) mediante el
estado de enlace del protocolo de pasarela fronteriza", Jeff Tantsura, Uma Chunduri, Gregory Mirsky, Siva
Sivabalan, Nikos Triantafillis, draft-ietf-idr-bgp-ls-segment-routing-msd-04 (Trabajo en curso), febrero de
2019.

[draft-ietf-idr-te-lsp-distribution] "Distribución de políticas y estado de ingeniería de tráfico (TE) mediante

BGP-LS", Stefano Previdi, Ketan Talaulikar, Jie Dong, Mach Chen, Hannes Gredler, Jeff Tantsura, draft-
ietf-idr-te-lsp-distribution-10 (Trabajo en curso), febrero de 2019.

[draft-ietf-pce-association-diversity] "Extensión del protocolo de comunicación de elementos de cálculo de

ruta (PCEP) para la restricción de diversidad de LSP de señalización", Stephane Litkowski, Siva Sivabalan,
Colby Barth, Mahendra Singh Negi, draft-ietf-pce-association-diversity-06 (Trabajo en curso), febrero de
2019.

[draft-ietf-idr-tunnel-encaps] "El atributo de encapsulación de túnel BGP", Eric C. Rosen, Keyur Patel, Gunter
Van de Velde, draft-ietf-idr-tunnel-encaps-11 (Trabajo en curso), febrero de 2019.

[[Link]]< [Link]

[GMPLS-UNI] <[Link]
5/mpls/configuration/guide/b-mpls-cg-asr9000-65x/b-mpls-cg-asr9000-65x_chapter_0111.html>

[Cisco WAE]< [Link]

[Google Espresso] "Taking the Edge off with Espresso: Scale, Reliability and Programmability for Global
Internet Peering.", Kok-Kiong Yap, Murtaza Motiwala, Jeremy Rahe, Steve Padgett, Matthew Holliman,
Gary Baldus, Marcus Hines, Taeeun Kim, Ashok Narayanan, Ankur Jain, Victor Lin, Colin Rice, Brian
Rogan, Arjun Singh, Bert Tanaka, Manish Verma, Puneet Sood, Mukarram Tariq, Matt Tierney, Dzevad
Trumic, Vytautas Valancius, Calvin Ying, Mahesh Kallahalla, Bikash Koley y Amin Vahdat, Actas de la
Conferencia del Grupo de Interés Especial de ACM sobre Comunicación de Datos (SIGCOMM '17), 2017.
<[Link]

[Facebook EdgeFabric] "Engineering Egress with Edge Fabric: Steering Oceans of Content to the World",
Brandon Schlinker, Hyojeong Kim, Timothy Cui, Ethan Katz-Bassett, Harsha V.
 Madhyastha, Italo Cunha, James Quinn, Saif Hasan, Petr Lapukhov y Hongyi Zeng, Proceedings of the
Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17), . 2017.
<[Link]
<[Link]

[Alibaba NetO] "NetO: Alibaba's WAN Orchestrator", Xin Wu, Chao Huang, Ming Tang, Yihong Sang, Wei
Zhou ,Tao Wang, Yuan He, Dennis Cai, Haiyong Wang, and Ming Zhang, SIGCOMM 2017 Industrial
Demos, 2017.< [Link] industrial-
demos/[Link]>

[SERA] "SERA: SEgment Routing Aware Firewall for Service Function Chaining scenarios", Ahmed
Abdelsalam, Stefano Salsano, Francois Clad, Pablo Camarillo y Clarence Filsfils, IFIP Networking, Zúrich,
Suiza, mayo de 2018.
<[Link]

[IGP tuning] "IGP Tuning in an MPLS Network", Martin Horneffer, NANOG 33, febrero de 2005, Las
Vegas.

[SWAN] "Achieving high utilization with software-driven WAN", Chi-Yao Hong, Srikanth Kandula, Ratul
Mahajan, Ming Zhang, Vijay Gill, Mohan Nanduri y Roger Wattenhofer, Actas de la conferencia ACM
SIGCOMM 2013 sobre SIGCOMM (SIGCOMM '13), 2013.
<[Link] <[Link] us/projects/swan>

1. Aunque un despliegue típico utiliza RRs para escalar BGP, se puede utilizar cualquier modelo de
distribución BGP: malla completa, RRs, Confederaciones.↩

2. Históricamente, el retardo de serialización (tamaño del paquete dividido por la tasa de Gbps del
enlace) también era un componente. Ahora es insignificante.↩

3. No confundir con los colores de enlace o colores de afinidad, que se utilizan para marcar enlaces con
el fin de incluirlos o excluirlos de una ruta TE.↩
Sección I - Fundación
Esta sección describe los elementos fundamentales de la Ingeniería de Tráfico SR.
2 Política de RS
Lo que aprenderemos en este capítulo:

Una política de SR en una cabecera se identifica por el punto final y un color

Una política SR tiene una o más rutas candidatas, que a menudo se denominan simplemente "rutas".

Una ruta candidata es, en esencia, una lista SID (una lista de segmentos), o un conjunto de listas SID

Una ruta candidata puede ser dinámica o explícita

Una ruta candidata puede instanciarse a través de CLI/NETCONF o señalarse a través de PCEP o BGP-TE

La ruta válida con la preferencia más alta se selecciona como ruta activa

Las listas SID de la ruta activa se programan en la tabla de reenvío

Las listas SID de una política SR son las listas SID de su ruta activa

Una política SR está vinculada a un Binding-SID

Una política SR válida tiene su Binding-SID instalado en la tabla de reenvío MPLS como una etiqueta local
entrante con la acción "Pop and push the SID list of the SR Policy".

En primer lugar, introducimos el concepto de política de SR mediante un ejemplo; a continuación,

proporcionamos una definición formal y recordamos el concepto clave de segmento de enlace. La última
sección presenta el modelo de configuración.
2.1 Introducción
El enrutamiento por segmentos permite un nodo de cabecera dirigir un flujo de paquetes a lo largo de
cualquier ruta de la red imponiendo una lista ordenada de segmentos a los paquetes flujo. No se crea ningún
estado por flujo en los nodos intermedios, el estado por flujo se lleva dentro de la lista de segmentos del
paquete. Cada segmento de la lista de segmentos identifica una instrucción que el nodo debe ejecutar en el
paquete, siendo la más común una instrucción de reenvío.

Segmentos e identificadores de segmento (SID)

Un segmento es una instrucción que un nodo ejecuta en el paquete entrante que lleva la instrucción en su cabecera. Ejemplos de instrucciones son
reenviar el paquete por el camino más corto hasta su destino, reenviar el paquete a través de una interfaz específica, entregar el paquete a una
aplicación/servicio determinado, etc.

Un identificador de segmento (SID) identifica un segmento. El formato de un SID depende de la implementación. La implementación SR
MPLS utiliza etiquetas MPLS como SIDs. SRv6 utiliza SIDs en el formato de direcciones IPv6 pero no son realmente direcciones IPv6 ya que
su semántica es diferente.

Aunque existe una diferencia semántica entre segmentos y SID, ya que el segundo es el identificador del primero, ambos términos suelen
utilizarse indistintamente y su significado puede deducirse de su contexto. Esto también se aplica a sus derivados, "lista de segmentos" y "lista
de SID".

En la instanciación MPLS de Segment Routing, un SID es una etiqueta MPLS y una lista SID es una pila
MPLS.

En el contexto de la ingeniería de tráfico topológica, la lista SID (la pila de etiquetas MPLS) se compone de
SID de prefijo (camino más corto al nodo relacionado) y SID de adyacencia (uso específico de un enlace).

Una ventaja clave de la solución de enrutamiento por segmentos es que integra la ingeniería de tráfico topológico
y el encadenamiento de servicios en la misma solución. La lista de SID puede ser una combinación de SID de
prefijo, SID de adyacencia y SID de servicio. Los dos primeros ayudan a guiar los paquetes topológicamente a
través de la red, mientras que el último representa servicios distribuidos a través de la red (dispositivo de
hardware, VM o contenedor).

En este libro (Parte II), nos centraremos en la ingeniería de tráfico topológica (más brevemente, ingeniería de
tráfico o SR-TE). La Parte III explicará cómo se aprovecha la misma solución para el encadenamiento de
servicios basado en SR.
El concepto central de nuestra solución SR-TE es la Política SR". La política SR rige las dos acciones
fundamentales de una de ingeniería de tráfico:

Expresar una ruta específica a través de la red

Típicamente diferente camino más corto calculado por el IGP

Dirigir el tráfico hacia la ruta específica

En el resto de esta sección, utilizamos cuatro ilustraciones para presentar algunas características clave de una
política de SR. El primer ejemplo ilustra el concepto de camino explícito. El segundo ejemplo introduce el
concepto de validación y selección de una ruta explícita. El tercer ejemplo introduce el concepto de trayectoria
dinámica con la minimización de una métrica acumulativa. El cuarto ejemplo amplía este último concepto
añadiendo una restricción a la trayectoria dinámica.

La capacidad de diseñar una ruta a través de una red no puede disociarse de la dirección del tráfico hacia esa
ruta. Automated Steering (AS) es la funcionalidad SR-TE que dirige automáticamente las rutas de servicio de
color sobre la Política SR apropiada. Presentamos brevemente la funcionalidad AS en el primer ejemplo,
mientras que el capítulo 5, "Automated Steering" y el capítulo 10, "Further Details on Automated Steering"
cubren el concepto de dirección en detalle.

La política de RS no es un túnel

"Históricamente, el término "túnel" implicaba varios problemas que no queríamos en absoluto que el enrutamiento por segmentos
heredara: 1/ configuración previa en una cabecera hacia un punto final específico con un SLA o ruta específicos; 2/ degradación del
rendimiento en dirección; 3/ limitación de escala debido a la gestión de un túnel como interfaz; 4/ dirección de autoroute como único
mecanismo de dirección.

La mentalidad "think-out-of-the-box" y de simplificación/automatización nos empujó a reconsiderar los conceptos clave en la base de
una solución de SR.

Esto nos permitió identificar las nociones de política de SR, color de una política de SR, política a la carta (ODN) y dirección
automatizada (AS).

Estos conceptos no estaban presentes en el modelo de túnel RSVP-TE y nos permitieron simplificar el funcionamiento de TE. "

- Clarence Filsfils

Las ilustraciones suponen una única red de área IGP (por ejemplo, Figura 2-1).
 Figura 2-1: Topología de red con camino más corto IGP y política SR con camino explícito

La métrica IGP por defecto para los enlaces de esta red es 10. El enlace entre Nodo3 y Nodo4 es un enlace caro
y de baja capacidad, por lo que el operador le ha asignado una métrica de enlace IGP más alta de
100. Además, el enlace entre Nodo8 y Nodo5 tiene una métrica de enlace IGP más alta de 100.

2.1.1 Una ruta candidata explícita de una política SR

Ilustramos el concepto de ruta candidata explícita de una política de SR. Introducimos brevemente el
Automated Steering (AS) de un flujo en una Política SR.

Tenga en cuenta que, aunque el término exacto es "camino candidato", podemos utilizar en su lugar el término
más corto "camino".

Suponemos que el operador quiere que parte del tráfico del Nodo1 al Nodo4 vaya por el camino
1→7→6→8→5→4.

El operador podría expresar este camino como <16008, 24085, 16004>: camino más corto al Nodo8 (Prefijo-
SID del Nodo8), adyacencia del Nodo8 al Nodo5 (Adjacency-SID), camino más corto al Nodo4 (Prefijo-SID
del Nodo4). Según las convenciones de ilustración usadas en este libro, 24085 es la etiqueta Adj-SID del
Nodo8 para su enlace al Nodo5.
Una lista SID de este tipo expresada por el operador se denomina "explícita". El término "explícito" significa
que el operador (potencialmente a través de un controlador externo) calcula la ruta enrutada en origen y la
programa en el router de cabecera. Se indica explícitamente al encaminador de cabecera la ruta enrutada en
origen que debe utilizar. El router de cabecera simplemente recibe una lista SID y la utiliza como tal.

No se asocia ninguna intención a la lista SID: es decir, la cabecera no sabe por qué el operador ha seleccionado
esa lista SID. La cabecera se limita a instanciarla según la configuración explícita.

Esta lista SID explícita (la secuencia de instrucciones para ir del Nodo1 al Nodo4) se configura en una
Política SR en el Nodo1 de cabecera.

Política SR (cabecera Nodo1, color azul, extremo Nodo4)

rutas de los candidatos:

1. explícito: Lista SID <16008, 24085, 16004>

Vemos que la política de SR se identifica mediante una tupla de tres entradas: la cabecera en la que se
instancia la política de SR, el punto final y un color.

Como se explicó en la introducción, el color es una forma de expresar una . En este punto de la ilustración,
piensa en el color como una forma de distinguir múltiples Políticas SR, cada una con su propia intención, desde
la misma cabecera Nodo1 al mismo punto final Nodo4.

Por ejemplo, el Nodo1 podría configurarse con las siguientes dos Políticas SR:

Política SR (cabecera Nodo1, color azul, extremo Nodo4)

rutas de los candidatos:

1. explícito: Lista SID <16008, 24085, 16004>

Política SR (cabecera Nodo1, color naranja, extremo Nodo4)

caminos-candidatos:

1. explícito: Lista SID <16003, 24034>

Es necesario distinguir estas dos Políticas SR porque el Nodo1 puede querer dirigir simultáneamente un flujo
hacia la Política SR azul mientras que otro flujo es dirigido hacia la Política SR naranja.

De hecho, ya se puede intuir que el color no sólo sirve para distinguir las Políticas de SR. Desempeña un papel
clave en la dirección del tráfico, y más concretamente en la dirección automática del tráfico en Política SR
correcta coloreando de forma similar la ruta de servicio (es decir, intuitivamente, el tráfico de color naranja
destinado al Nodo4 irá a través de la Política SR naranja al Nodo4 y el tráfico de color azul destinado al Nodo4
irá a través de la Política SR azul al Nodo4).

Un componente fundamental de la solución SR-TE es la "dirección automática" (AS). Aunque se explica con
detalle más adelante en el libro, aquí ofrecemos una breve introducción.

Figura 2-2: Dos políticas SR de Nodo1 a Nodo4

Automated Steering permite al Nodo1 de la cabecera automatizar el direccionamiento de su tráfico hacia la

Política SR apropiada. En este ejemplo, vemos en la Figura 2-2 que el Nodo4 anuncia dos rutas BGP al
Nodo1: [Link]/24 con color naranja y [Link]/24 con color azul. Basándonos en estos colores
La cabecera Nodo1 dirige automáticamente cualquier tráfico al prefijo naranja [Link]/24 a la Política SR
(naranja, Nodo4) y cualquier tráfico al prefijo azul [Link]/24 a la Política SR (azul, Nodo4).

En resumen, la aplicación de la dirección automatizada en una cabecera permite a la cabecera dirigir

automáticamente una ruta de servicio (por ejemplo, BGP, PW, etc.) a la política SR que coincida con el color
de la ruta de servicio y punto final de la ruta de servicio (es decir, nexthop BGP).

Recuerde que, aunque en este texto nos referimos a los colores como nombres para facilitar la comprensión,
un color es en realidad un número. Por ejemplo, el color azul podría ser el número 10. Para anunciar un color
con un prefijo, BGP añade un atributo de comunidad extendida de color al anuncio (más detalles en el capítulo
5, "Automated Steering").

Reiteremos también una ventaja clave del Enrutamiento por Segmentos. Una vez que el tráfico se dirige a la
política SR configurada en Nodo1, el tráfico sigue la ruta diseñada para el tráfico sin ningún otro estado en la
red.

Por ejemplo, si el tráfico azul al Nodo4 es dirigido en la Política SR (Nodo1, azul, Nodo4), entonces el tráfico
azul irá a través de 1→7→6→8→5→4. Ningún estado está presente en 7, 6, 8, 5 o 4 para este flujo. El único
estado está presente en la cabecera de la política SR. Esta es una ventaja clave en comparación con RSVP-TE
que crea estado por flujo en toda red.

En estos primeros ejemplos, las políticas SR tenían una única ruta candidata explícita por política, con una
ruta candidata explícita que se especifica como una única lista SID explícita.

En las siguientes ilustraciones, ampliamos el concepto de política SR introduciendo múltiples rutas candidatas
por política y, a continuación, la noción de rutas candidatas dinámicas.

2.1.2 Validación y selección de rutas

En el segundo ejemplo, suponemos que el operador quiere que parte del tráfico del Nodo1 al Nodo4 vaya por
uno de los dos posibles caminos candidatos, 1→7→6→8→5→4 y 1→2→3→4. Estos caminos pueden
expresar con las listas SID <16008, 24085, 16004> y <16003, 24034> respectivamente. El operador prefiere
utilizar el primer camino candidato y sólo utilizar el segundo camino candidato si el primero es inutilizable.
Por lo tanto, asigna un valor de preferencia a cada ruta candidata, con una preferencia mayor
que indica un camino más preferido. La primera ruta tiene una preferencia 100 mientras que la segunda tiene
una preferencia 50. Ambas rutas se muestran en la Figura 2-3.

Figura 2-3: Política SR (azul, Nodo4) con dos rutas candidatas

Una ruta candidata es utilizable cuando es válida. Un criterio común de validez de una ruta es la alcanzabilidad
de los SID que la componen. Las reglas de validación se especifican en el capítulo 3, "Ruta explícita".

Cuando ambos caminos candidatos son válidos (es decir, ambos caminos son utilizables), el Nodo de
cabecera1 selecciona el camino de mayor preferencia e instala la lista SID de este camino (<16008, 24085,
16004>) en su tabla de reenvío. En cualquier , el tráfico azul que se dirige a esta política SR sólo se envía por
la ruta seleccionada, cualquier otra ruta candidata está inactiva.

Una ruta candidata se selecciona cuando tiene el valor de preferencia más alto entre todas las rutas candidatas
válidas de la Política SR. La ruta seleccionada también se denomina "ruta activa" de la política SR. En caso de
que varias rutas candidatas válidas tengan la misma preferencia, se evalúan las reglas de desempate descritas en
el capítulo 16, "Operaciones SR-TE", para seleccionar una ruta.

Una cabecera vuelve a ejecutar el procedimiento de selección de ruta activa siempre que conoce una nueva
ruta candidata de una política SR, se elimina la ruta activa, se modifica una ruta candidata existente o cambia
su validez.
En algún momento, se produce un fallo en la red. El enlace entre el Nodo8 y el Nodo5 falla, como se muestra
en la Figura 2-4. En un primer momento, las protecciones Topology Independent Loop-Free Alternate (TI-LFA)
garantizan que los flujos de tráfico que atravesaban este enlace se restablezcan rápidamente (en menos de 50
milisegundos). Capítulo
8, "Resistencia de la Red" describe la protección TI-LFA de las Políticas SR. Consulte la Parte I del libro
SR para obtener más información sobre TI-LFA.

Finalmente, el Nodo cabecera1 se entera a través de la inundación IGP de que el Adj-SID 24085 del enlace
fallido ha dejado de ser válido. Nodo1 evalúa la validez de la lista SID del camino t(1) y la invalida debido a la
presencia del Adj-SID inválido. El Nodo1 invalida la lista de SID y la ruta candidata y vuelve a ejecutar el
proceso de selección de ruta. Nodo1 selecciona la siguiente ruta candidata válida de mayor preferencia, la
ruta con preferencia 50. Nodo1 instala la lista SID de esta ruta - <16003, 24034> - en la tabla de reenvío. A
partir de entonces, el tráfico azul que se dirige a esta política SR se envía por la nueva ruta seleccionada.

Figura 2-4: Política SR (azul, Nodo4) con dos rutas candidatas - la ruta de mayor preferencia no es válida

Después de restaurar el enlace fallido, la ruta candidata con preferencia 100 vuelve a ser válida. El Nodo de
Cabecera1 realizará de nuevo el procedimiento de selección de ruta de la Política SR, seleccionará la ruta
candidata válida con la preferencia más alta y actualizará su tabla de reenvío con la lista SID de esta ruta
<16008, 24085,
16004>. El tráfico azul que se dirige a esta política SR se envía por la ruta 1→7→6→8→5→4, como se
muestra en la Figura 2-3.

2.1.3 Ruta candidata dinámica de bajo retardo

A menudo, el operador prefiere simplemente expresar una intención (por ejemplo, baja-dela y(2) a un punto final
específico o evitar enlaces con afinidad TE color púrpura) y dejar que la cabecera traduzca esta intención en
una lista SID. Esto se denomina ruta candidata "dinámica". La cabecera traduce dinámicamente la intención en
lista SID y, lo que es más importante, responde continuamente a cualquier cambio en la red actualizando la
lista SID según sea necesario para cumplir la intención.

La intención se define formalmente como una minimización de una métrica aditiva (por ejemplo, métrica
IGP, métrica TE o Link-Delay) y un conjunto de restricciones (por ejemplo, evitar/incluir dirección IP,
SRLG, afinidad TE).

Aprovechando el protocolo de encaminamiento link-state (ISIS, OSPF o BGP-LS), cada nodo distribuye su
propia información local, su propia pieza del rompecabezas de la red. Además de la conocida información
topológica (nodos, enlaces, prefijos y sus atributos), el anuncio de estado de enlace puede incluir elementos SR
(SRGB, SIDs, ...) y otros atributos de enlace (retardo, pérdida, SRLGs, afinidad, ...).

El nodo de cabecera recibe toda esta información y la almacena en su base de datos SR-TE local (SR-TE
DB). Esta SR-TE DB contiene una vista topológica completa del área IGP local, incluida la información SR-
TE. La base de datos SR-TE contiene todo lo que el nodo de cabecera necesita para calcular las rutas a través
de la red que cumplen la intención.

La cabecera utiliza algoritmos "SR nativos" para traducir la "intención" de una ruta dinámica en una lista
SID. El término "SR nativo" destaca que el algoritmo se ha optimizado para SR. Maximiza el ECMP y
minimiza la longitud de la lista SID.

Consideremos ahora una Política SR desde el Nodo1 al Nodo4 que expresa la intención de proporcionar un
camino de bajo retardo. Para calcular el camino de bajo retardo, el nodo de cabecera necesita conocer el
retardo de los enlaces de la red. La Figura 2-5 muestra los valores de retardo medidos para cada enlace. El
Nodo cabecera1 recibe estas métricas de retardo de enlace a través del IGP y las añade a su DB SR-TE. El
Nodo1 puede calcular el camino de bajo retardo al Nodo4, que es simplemente el cálculo del camino más
corto utilizando el retardo del enlace como métrica. El camino resultante es 1→2→3→4, con un retardo
acumulado 12+11+7 = 30.
 Figura 2-5: Topología de red con valores de retardo de enlace medidos

Nodo1 codifica el camino en la lista SID <16003, 24034>; 16003 es el camino más corto a Nodo3 y por lo tanto
sigue correctamente 1→2→3 y luego 3→4 se cumple con el SID Adj de Nodo3 a Nodo4 (24034).

Para recapitular, una política SR puede instanciarse con una ruta candidata "dinámica". Una ruta candidata
"dinámica" expresa una intención. La cabecera utiliza su base de datos SR-TE y sus algoritmos nativos SR
(explicados más adelante en el libro) para traducir la intención en una lista SID. Cada vez que la red cambia,
cabecera actualiza la lista de SID en consecuencia.

Suponiendo que el operador utilice el color "verde" para "bajo retraso", la política de SR que acabamos de
analizar resumirse del siguiente modo:

Política SR (Nodo1, verde, Nodo4)

caminos-candidatos:
 1. dinámico: retraso optimizado

→ Lista SID <16003, 24034>

2.1.4 Ruta candidata dinámica que evita enlaces específicos

Supongamos ahora que el operador necesita una Política SR "púrpura" desde el Nodo1 al Nodo4 que minimice
la métrica IGP acumulada desde el Nodo1 al Nodo4 evitando al mismo tiempo los enlaces con afinidad color
rojo.

Los colores de afinidad de los enlaces son un conjunto de propiedades que pueden asignarse a un enlace.

Cada enlace en la red puede tener cero, uno o más colores de afinidad. Estos colores se anuncian en el IGP (y
BGP-LS) con el enlace (adyacencia IGP, en realidad).

Aunque aquí nos referimos a los colores de afinidad como nombres de color, cada color de afinidad es en
realidad un bit en un mapa de bits. Si un enlace tiene un color determinado, se activa el bit del mapa de bits
que corresponde a ese color.

Colores

El término "color" puede referirse a un atributo de dos elementos distintos de una red que no deben confundirse.

El color de afinidad de enlace es un nombre comúnmente utilizado para indicar un Grupo Administrativo del IETF (RFC 3630 y RFC 5305) o
Clase de Recurso (RFC 2702). Los colores de afinidad de enlace son atributos de enlace que se utilizan para expresar alguna noción de "clase".
Los colores de afinidad de enlaces pueden utilizarse en el cálculo de rutas para incluir o excluir enlaces con alguna combinación de colores.

Por otro lado, los colores de las políticas de SR se utilizan para identificar una intención o un SLA. Este color se utiliza para hacer coincidir una
ruta de servicio que requiere un SLA determinado con una política SR que proporciona la ruta que satisface este SLA. El color SLA se adjunta a
un anuncio de ruta de servicio como una comunidad.

Como se muestra en la Figura 2-6, sólo el enlace entre el Nodo7 y el Nodo6 tiene afinidad de color rojo. Nodo6
y Nodo7 distribuyen esta información de color de afinidad dentro de la red en el IGP. El Nodo1 recibe esta
información y la inserta en su DB SR-TE.
 Figura 2-6: Topología de red con afinidad de enlaces

Para calcular el camino, el Nodo1 poda los enlaces que no cumplen la restricción "evitar enlaces rojos" del
modelo de topología en su DB SR-TE y calcula el camino más corto métrico IGP al Nodo4 en la topología
podada. El camino resultante es 1→2→3→6→5→4. Nodo1 codifica este camino en la lista SID óptima
<16003, 16004>. 16003 es el Prefijo-SID del Nodo3, transportando el paquete a través del camino más corto
IGP al Nodo3. 16004 es el Prefijo-SID del Nodo4, transportando el paquete a través del camino más corto IGP
al Nodo4.

Esta política de RS se resume del siguiente modo:

Política SR (Nodo1, morado, Nodo4)

caminos-candidatos:

1. dinámico: minimizar la métrica IGP Y excluir los enlaces rojos

→ Lista SID <16003, 16004>

En la sección 2.2 formalizamos los conceptos de política de RS ilustrados en esta sección.

2.1.5 Codificación de una ruta en una lista de segmentos

Una lista de segmentos expresa un trayecto en una secuencia de segmentos. Cada segmento especifica una parte
del trayecto y, tomado aisladamente, es independiente de la intención del trayecto de extremo a extremo. SR-TE
obtiene una lista de segmentos óptima para codificar el trayecto de extremo a extremo utilizando los segmentos
de que dispone.

Por defecto, los segmentos disponibles son los segmentos regulares de prefijo IGP (siguiendo el camino más
corto IGP) y los segmentos de adyacencia IGP .(3)

En el ejemplo de bajo retardo de la sección 2.1.3, SR-TE codificó la ruta de bajo retardo en una
secuencia de un Prefix-SID y un Adj-SID.

La ilustración de ese ejemplo se repite aquí en la Figura 2-7 para facilitar la consulta.

Figura 2-7: Codificación de la ruta de bajo retardo en una lista de segmentos

La ruta de bajo retardo del Nodo1 al Nodo4 es 1→2→3→4. Cada nodo anuncia un Prefix-SID y un Adj-SID
para cada una de sus adyacencias. Estos son los segmentos que SR-TE tiene disponibles en su caja de
herramientas para codificar la ruta.
Dado que esta ruta no tiene ECMP, SR-TE podría codificar la ruta utilizando la secuencia de Adj-SID de todos
los enlaces que atraviesa la ruta: <24012, 24023, 24034>. Esto no es óptimo, ya que requiere un SID para cada
salto.

SR-TE ve que la porción del camino 1→2→3 puede ser expresada por el Prefijo-SID del Nodo3. De hecho,
el camino más corto IGP de Nodo1 a Nodo3 es 1→2→3.

El camino más corto IGP del Nodo3 al Nodo4 es 3→6→5→4, que no coincide con el camino 3→4 deseado. La
ruta 3→4 puede expresarse mediante el Adj-SID 24034 del Nodo3 para el enlace Nodo4.
2.2 Modelo de política de RS
Una política de SR se identifica unívocamente mediante una tupla formada por los tres elementos siguientes:

Cabecera

Punto final

Color

La cabecera es donde se instancian/implementan las políticas.

El punto final suele ser el destino de la política SR, especificado como una dirección IPv4 o IPv6.

El color es un valor numérico arbitrario de 32 bits que se utiliza para diferenciar varias políticas SR con la
misma cabecera y punto final. El color es clave para la funcionalidad "Automated Steering". El color suele
representar una intención, una forma específica de llegar al punto final (por ejemplo, bajo retardo, bajo coste
con exclusión de SRLG, etc.).

En un nodo de cabecera dado, una política de SR se identifica completamente por la tupla (color, endpoint). En
este libro cuando asumimos que la cabecera es bien conocida, a menudo nos referiremos a una Política SR
como (color, endpoint).

Entre un par determinado (nodo de cabecera, punto final) sólo puede existir una política de SR con un color C
determinado. En otras palabras: cada tupla de política de SR (nodo de cabecera, color, punto final) es única.

Como se ilustra en la Figura 2-8, una Política SR tiene al menos una ruta candidata y una única ruta candidata
activa. La ruta candidata activa es la ruta válida de mejor preferencia. La lista SID de una política es la lista
SID de su camino activo.
 Figura 2-8: Modelo de política de RS

Para simplificar, partimos del supuesto de que cada ruta candidata sólo tiene una lista SID. En realidad, cada
ruta candidata puede tener varias listas SID, cada una con su peso de equilibrio de carga asociado. El tráfico en
esa ruta se reparte entre todas las SID válidas de esa ruta, de acuerdo con su ratio de peso. Esto se explica con
más detalle en el capítulo 16, "Operaciones SR-TE".

2.2.1 Lista de segmentos

Una lista de segmentos (lista SID) es una secuencia de SID que codifica la ruta de un paquete a través de la
red. En la implementación MPLS SR, un SID es un valor de etiqueta y una lista SID es una pila de etiquetas.
Para un paquete dirigido a la política SR, esta pila de etiquetas (lista SID) se impone en la cabecera del
paquete.

Una lista SID se representa como una lista ordenada <S1, S2, ..., S(n)>, donde S1 es el primer SID, que es la
etiqueta superior de la pila de etiquetas SR MPLS, y Sn es el último SID, la etiqueta inferior para SR MPLS.

En la implementación SR-MPLS, hay dos formas de configurar un SID como parte de una lista SID:
especificando directamente su valor de etiqueta MPLS (por ejemplo, 16004) o proporcionando un descriptor de
segmento (por ejemplo, dirección IP [Link]) que el nodo de cabecera traduce al valor de etiqueta
correspondiente. Hay una diferencia importante entre ambas opciones.
Un SID expresado como valor de etiqueta MPLS sólo se comprueba si está en la primera posición de la lista
de SID. Se comprueba (valida) para encontrar la interfaz saliente y el siguiente salto.

Siempre se comprueba la validez de un SID expresado como descriptor de segmento. En efecto, la cabecera
debe traducir ese descriptor de segmento a una etiqueta MPLS (es decir, lo que se impone a los paquetes son
pilas de etiquetas); este acto de traducir el descriptor de segmento a la etiqueta MPLS es la comprobación de
validez. funciona, entonces el SID es válido. Si la traducción falla (la dirección IP del descriptor de segmento
no se ve en la DB SR-TE o la dirección IP se ve pero sin un SID) entonces el SID no es válido. Un SID
vinculado a un prefijo de un nodo fallido o una adyacencia fallida no es válido. Ese SID no está en la DB
SR-TE y la cabecera no puede traducir el descriptor de segmento en un valor de etiqueta MPLS.

Lo más frecuente es se configure una ruta explícita con todos los SID expresados como valores de etiqueta
MPLS. Este sería el caso cuando un controlador externo ha realizado todos los cálculos y está monitorizando
activamente (stateful) la política. En este caso, el controlador está al mando y no quiere que la cabecera adivine
su funcionamiento.

Hay una segunda razón para expresar un SID explícito como un valor de etiqueta MPLS: cuando el SID
pertenece a un dominio remoto. En ese , la cabecera no tiene forma de validar el SID (no dispone de la
topología de estado de enlace del dominio remoto), por lo que se utiliza un valor de etiqueta MPLS para evitar
la comprobación de validez.

"No me canso de repetir que disponer de una conectividad MPLS basada en SR "gratuita" por parte del IGP permite concentrarse
en el verdadero trabajo de ingeniería de tráfico. Por ejemplo, puede crear una ruta explícita para dirigir el tráfico a través de una
región críticamente congestionada y, a continuación, utilizar un nodo SID en la parte inferior de la pila para recorrer el resto del
camino hasta la salida a través de la ruta más corta IGP. Y nunca tendrá que preocuparse de la señalización LSP. "

- Paul Mattes

2.2.2 Trayectorias de los candidatos

Una ruta candidata de una política SR representa una forma específica de transportar el tráfico desde la cabecera
hasta el punto final de la política SR correspondiente.

Una ruta candidata dinámica se expresa como un objetivo de optimización y un conjunto de restricciones.
Utilizando los algoritmos SR nativos y la información de su DB SR-TE local, la cabecera calcula una
solución al problema de optimización m(4), y proporciona la solución (la ruta óptima) como una lista SID. Si
la cabecera
no dispone de la información necesaria en su DB SR-TE para calcular el trayecto, la cabecera puede delegar el
cálculo en un controlador o en un elemento de cálculo de trayecto (PCE). Cada vez que cambia el estado de la
red, la ruta se vuelve a calcular automáticamente. Lee el capítulo 4, "Trayecto Candidato Dinámico" para más
información sobre trayectos dinámicos.

Una ruta candidata explícita se expresa como una lista SID. La lista SID puede proporcionarse a la cabecera
de varias maneras, la más común por configuración o señalada por un controlador. A pesar de su nombre, una
ruta explícita es probablemente el resultado de un cálculo dinámico. La diferencia con la ruta dinámica es que
la cabecera no participa en el cálculo de la lista SID de la ruta explícita; la cabecera sólo recibe el resultado
como una lista SID explícita. Lea el capítulo 3, "Ruta candidata explícita", para obtener más información sobre
las rutas explícitas.
 Figura 2-9: Rutas candidatas dinámicas y explícitas

En lugar de especificar una única ruta candidata para una política de SR, un operador puede querer
especificar múltiples rutas candidatas posibles con un orden de preferencia.

Consulte la Figura 2-3 del ejemplo en la sección 2.1.2, donde el operador especificó dos rutas candidatas para la
Política SR en el Nodo1 al Nodo4. En cualquier , una ruta candidata es seleccionada e instalada en la tabla de
reenvío. Esta es la ruta candidata válida con mayor preferencia. Al invalidarse la ruta seleccionada, la siguiente
ruta válida con mayor preferencia se selecciona como nueva ruta seleccionada.

Cada ruta candidata tiene una preferencia. El valor por defecto es 100. Cuanto mayor sea la preferencia, más
preferida será la ruta.
La ruta candidata activa de una política SR es la ruta válida con mayor preferencia.

Una ruta candidata es válida si se puede utilizar. El proceso de validación de rutas explícitas se detalla en el
capítulo 3, " candidata explícita". En resumen, el primer SID debe resolverse en una interfaz saliente y un
válidossiguiente salto , y la DB SR-TE debe poder resolver todos los demás SID que se expresan como
descriptores de segmento en etiquetas MPLS. Para validar una ruta dinámica, se vuelve a calcular la ruta.

Una cabecera vuelve a ejecutar el procedimiento de selección de la ruta activa siempre que conoce una nueva
ruta candidata de una política de SR, se elimina la ruta activa, se modifica una ruta candidata existente o
cambia su validez. En otras palabras, la ruta activa de una política de SR es, en cualquier momento, la ruta
candidata válida con el valor de preferencia más alto.

Una cabecera puede ser informada sobre rutas candidatas para una Política SR dada por varios medios,
incluyendo configuración local, NETCONF, PCEP o BGP (discutiremos estos diferentes mecanismos a lo largo
del libro). El origen de la ruta candidata no influye en la selección de la ruta activa de la política SR; la ruta
activa de la política SR se selecciona en función de su validez y su preferencia. En una sección posterior se
explicará cómo se selecciona una única ruta activa cuando una política de SR tiene varias rutas candidatas
válidas con la misma preferencia.
 Cada ruta candidata puede aprenderse de una forma diferente

"Una cabecera puede aprender diferentes rutas candidatas de una política SR a través de diferentes medios: algunos a través de la
configuración local, otros a través de PCEP o BGP SR-TE.

La solución SR-TE está diseñada para ser modular y, por lo tanto, el modelo de política SR permite mezclar rutas candidatas de
varias fuentes.

En la práctica, el puede suponer que se utiliza una única fuente en un modelo de despliegue determinado.

En un modelo de plano de control distribuido, la ruta candidata (o más probablemente la plantilla dinámica ODN de la que deriva) es
probablemente aprendida por la cabecera a través de la configuración local (a su vez automatizada por una solución como Cisco NSO).

En un modelo de plano de control centralizado, es probable que la ruta candidata (explícita) la aprenda la cabecera del controlador a
través de BGP SR-TE o PCEP.

En algunos despliegues específicos y menos frecuentes, el operador puede mezclar diferentes fuentes: alguna ruta candidata base se
aprende de la configuración local mientras que algunas rutas candidatas específicas se aprenden vía BGP SR-TE o PCEP. Es
probable que se prefieran estas últimas cuando estén presentes.

Por ello, definimos el concepto de política SR de forma que cada una de sus rutas candidatas pueda aprenderse de una forma diferente:
configuración, NETCONF, PCEP y BGP SR-TE.

En la práctica, le aconsejamos que se centre en el caso de uso más probable: todas las rutas candidatas de una política se aprenden a
través del mismo mecanismo (por ejemplo, la configuración). "

- Clarence Filsfils
2.3 Segmento de encuadernación
El segmento de enlace (BSID) es fundamental para SR-TE.

Un Binding-SID está vinculado a una política de SR. Proporciona la clave de la política de SR vinculada. En
una cabecera determinada, un BSID está vinculado a una única política de SR en cualquier . La función de un
BSID (es decir, la instrucción que representa) es dirigir paquetes etiquetados a su política de SR asociada.

En la implementación MPLS SR, un BSID B ligado a una Política SR P en la cabecera H es una etiqueta local
de
H. Sólo la cabecera H tiene un estado para esta política SR y, por lo tanto, tiene una entrada de reenvío para B.

Cuando un nodo remoto R quiere dirigir paquetes a la política SR P del nodo de cabecera H, el nodo remoto R
empuja una pila de etiquetas con el prefijo SID de H seguido por el BSID de P. El prefijo SID de H puede ser
sustituido por cualquier lista SID que eventualmente llegue a H. Si R está unido a H, entonces R puede
simplemente empujar la etiqueta BSID para dirigir los paquetes a P.

El BSID vinculado a una política SR P puede ser proporcionado explícitamente por el operador o el
controlador, o asignado dinámicamente por la cabecera. Detallaremos el proceso de asignación en un capítulo
posterior.

El BSID es un atributo de una ruta candidata y el BSID de una Política SR es el BSID de la ruta candidata
activa.

El BSID de una política SR podría cambiar al cambiar la ruta activa

"Esto es consecuencia de capacidad de aprender cualquier trayectoria candidata de forma independiente. Como resultado, cada ruta
candidata puede aprenderse con un BSID.

En la práctica, le aconsejamos que se centre en el caso de uso más probable: todas rutas candidatas de una política tienen el mismo
BSID. Por lo tanto, al cambiar la ruta activa, el BSID de la política no cambia. "

- Clarence Filsfils

Cualquier paquete que llegue a la cabecera con un BSID en la parte superior de su pila de etiquetas se dirige a la
política de SR asociada con el BSID. La cabecera retira la etiqueta BSID, coloca la pila de etiquetas (lista SID)
asociada a la política SR en la cabecera del paquete y lo reenvía de acuerdo con la primera etiqueta de la lista
SID.
Para una política SR que tiene una ruta válida, el nodo de cabecera instala la siguiente entrada en su tabla de
reenvío para una política SR con lista SID <S1, S2> y BSID B1:

Etiqueta entrante: B1

Funcionamiento de la etiqueta: Pop, Push< S1, S2>

Salida: información de salida de S1

¿Es el valor de etiqueta de un BSID en el tiempo T un identificador fiable de una Política SR

en cualquier
¿tiempo?

"En teoría, no. Como hemos destacado anteriormente, en un caso extremo, cada ruta candidata puede tener un BSID diferente. Por lo
tanto, al cambiar una ruta válida, el BSID de una política de SR puede cambiar y, por lo tanto, su valor de etiqueta.

En teoría, la única identificación independiente del tiempo de una política de SR es la tupla (cabecera, color, punto final).

Sin embargo, en un despliegue normal, todas las rutas candidatas de la misma política se definen con el mismo BSID y, por lo tanto,
hay un BSID único y por política (sea cual sea la ruta candidata seleccionada) y, por lo tanto, el BSID es en la práctica un buen
identificador para una política. "

- Clarence Filsfils

En la topología de la Figura 2-10, el Nodo1 es la cabecera de una Política SR con la lista SID <16003, 24034>.
Nodo1 asignó un BSID 40104 para esta Política SR.
 Figura 2-10: Binding-SID

Cuando Nodo1 instanciaba la Política SR, instalaba la entrada de reenvío:

Etiqueta entrante (Binding-SID): 40104

Operación de etiqueta saliente: pop, push <16003, 24034>

Interfaz de salida: interfaz de salida de etiqueta 16003: a Nodo2

Un nodo remoto, como el Nodo10 en la Figura 2-10, dirigir un paquete a la Política SR del Nodo1
incluyendo el BSID de la Política SR en la pila de etiquetas del paquete. La Política SR del Nodo1 (verde,
[Link]) es entonces utilizada como Política de Tránsito en la ruta de extremo a extremo desde el Nodo10 al
Nodo4.

En la Figura 2-10 se muestra la pila de etiquetas de un paquete que va del Nodo10 al Nodo4. En el ejemplo,
el Nodo10 impone la pila de etiquetas <16001, 40104> al paquete y lo envía hacia el Nodo9. La etiqueta
16001, el Prefijo-SID del Nodo1, lleva el paquete al Nodo1. BSID 40104 dirige el tráfico hacia la política
SR. La etiqueta 40104 se quita y las etiquetas <16003, 24034> se ponen.

La cabecera de una Política de Tránsito dirige el paquete a esta Política de Tránsito sin . La clasificación del
paquete la realiza un nodo situado a distancia del nodo de la cabecera,
Nodo10 en este ejemplo. El Nodo10 ha decidido dirigir un paquete a esta Política SR específica de extremo a
extremo hacia el Nodo4. El Nodo10 puede clasificar este paquete basándose únicamente en su dirección de
destino, o también podría tener en cuenta otros elementos (dirección de origen, DSCP, ...). El Nodo10 codifica
el resultado de la clasificación como un BSID en la lista de segmentos impuesta al paquete. El Nodo1
simplemente reenvía el de acuerdo con la pila de etiquetas de este paquete.

El BSID se trata con más detalle en el capítulo 9, "Binding-SID y SRLB", y el papel del BSID en el
direccionamiento del tráfico también se trata en el capítulo 10, "Más detalles sobre el direccionamiento
automático".
2.4 Configuración de la política SR
Esta sección muestra las configuraciones de las Políticas SR que se presentaron en los ejemplos de la sección de
introducción de este capítulo.

Una ruta candidata explícita de una política SR

Para facilitar la referencia, la topología de la red se repite aquí en la Figura 2-11. Esta ilustración muestra dos
Políticas SR en la cabecera Nodo1. Ambas Políticas SR tienen el mismo punto final Nodo4 y cada una tiene una
ruta candidata explícita.

Figura 2-11: Dos políticas SR de Nodo1 a Nodo4

La configuración de la cabecera Nodo1 en el Ejemplo 2-1, especifica dos Políticas SR con los nombres
POLICY1 y POLICY2. Las políticas SR se configuran en la sección de configuración segment-routing
traffic-eng. El nombre de una política SR es definido por el usuario y es único en el nodo de cabecera.
Ejemplo 2-1: Configuración de la política SR Nodo1

segment-routing
traffic-eng
POLÍTICA1
¡¡!! (azul, Nodo4)
color 20 end-point ipv4 [Link]
preferencia de
trayectorias de
candidatos 100
lista explícita de segmentos SIDLIST1
¡!
POLÍTICA2
¡¡!! (naranja, Nodo4)
color 40 end-point ipv4 [Link]
preferencia de
trayectorias de
candidatos 100
lista explícita de segmentos SIDLIST2
¡!
nombre de la lista de segmentos SIDLIST1
index 10 mpls label 16008 ¡¡!! Prefix-SID Node8
index 20 mpls label 24085 !1 Adj-SID link 8->5
index 30 mpls label 16004 ¡¡!! Prefijo-SID Nodo4
¡!
nombre de la lista de segmentos SIDLIST2
index 10 mpls label 16003 ¡¡!! Prefix-SID Node3
index 20 mpls label 24034 !1 Adj-SID enlace 3-
>4

La política SR POLICY1 está configurada con un valor de color 20 y una dirección de punto final [Link]. El
valor de color 20 es elegido por el operador y representa un nivel de servicio específico o una intención
específica para la política. El endpoint [Link] es el prefijo loopback anunciado por Nodo4, como se muestra en
la Figura 2-11.

Se especifica una ruta candidata con preferencia 100: una ruta explícita con una lista de segmentos denominada
SIDLIST1. SIDLIST1 es un nombre definido por el usuario localmente significativo que identifica la lista de
segmentos.

La lista de segmentos SIDLIST1 especifica los SID en orden de índice creciente, que se corresponde con el
orden de arriba a abajo de la pila MPLS SR.

El primer SID (índice 10) es el Prefix-SID 16008 del prefijo loopback [Link]/32 del Nodo8. El segundo SID
(índice 20) es el Adjacency-SID 24085 del Nodo8 para la adyacencia al Nodo5. El tercer y último SID (índice
30) es el Prefix-SID 16004 del prefijo de loopback [Link]/32 del Nodo4. La ruta candidata resultante
(1→7→6→8→5→4) se muestra en la Figura 2-11.

Se configura una segunda política SR POLICY2 con un color 40 y la dirección de punto final [Link].

Se especifica una ruta candidata con preferencia 100: una ruta explícita con una lista de segmentos denominada
SIDLIST2.
El primer SID (índice 10) es el Prefix-SID 16003 del prefijo loopback [Link]/32 del Nodo3. El segundo y
último SID (índice 20) es el Adjacency-SID 24034 del Nodo3 para la adyacencia al Nodo4. El
El camino candidato resultante (1→2→3→4) se muestra en la Figura 2-11.

Validación y selección de rutas

En una política SR con varias rutas candidatas, cada una se configura con un valor de preferencia diferente.
Cuanto mayor sea el valor de preferencia, más preferida será la ruta candidata.

La política SR (azul, Nodo4) del Nodo1 en la Figura 2-12 tiene dos caminos candidatos, uno con preferencia 50
y otro con preferencia 100. El camino candidato con preferencia 100 es el camino activo actual ya que tiene la
preferencia más alta. La ruta candidata de preferencia 100 es la ruta activa actual ya que tiene la preferencia
más alta.

Figura 2-12: Política SR (azul, Nodo4) con dos rutas candidatas

El Ejemplo 2-2 muestra la configuración de la Política SR en el Nodo1 de la cabecera. Esta política SR tiene
dos candidatas. La ruta de preferencia 100 es una ruta explícita con la lista de segmentos SIDLIST1. La
segunda ruta candidata tiene preferencia 50 y es una ruta explícita con la lista de segmentos SIDLIST2.

En la Figura 2-12 se ilustran ambas rutas candidatas.

Ejemplo 2-2: Configuración de la política SR Nodo1 - ruta explícita

segment-routing
traffic-eng
POLÍTICA1
¡¡!! (azul, Nodo4)
color 20 end-point ipv4 [Link]
candidate-paths
preferencia 100
lista explícita de segmentos SIDLIST1
¡!
preferencia 50
lista explícita de segmentos SIDLIST2
¡!
nombre de la lista de segmentos SIDLIST1
index 10 mpls label 16008 ¡¡!! Prefix-SID Node8
index 20 mpls label 24085 !1 Adj-SID link 8->5
index 30 mpls label 16004 ¡¡!! Prefijo-SID Nodo4
¡!
nombre de la lista de segmentos SIDLIST2
index 10 mpls label 16003 ¡¡!! Prefix-SID Node3
index 20 mpls label 24034 !1 Adj-SID enlace 3-
>4

Una ruta candidata dinámica de bajo retardo

Otra Política SR, llamada POLICY3, está ahora configurada en el Nodo1 en la Figura 2-13. Esta Política SR
tiene una ruta dinámica, donde el Nodo1 calcula dinámicamente la ruta de bajo retardo al Nodo4. Esta Política
SR tiene una ruta dinámica, donde el Nodo1 calcula dinámicamente la ruta de bajo retardo al Nodo4. En
ejemplo, todos los nodos en la topología miden el retardo de sus enlaces y distribuyen estas métricas de
retardo usando el IGP. Estas métricas de retardo de enlace medidas se muestran junto a los enlaces en la
ilustración.
Cómo se miden y distribuyen estas de retardo se discute en el capítulo 15, "Monitorización del Rendimiento -
Retardo de Enlace". El IGP en el Nodo1 recibe todas estas métricas de retardo de enlace y las almacena en su
base de datos. A partir de estas métricas de retardo, se puede deducir que la ruta de bajo retardo desde el
Nodo1 al Nodo4 es 1→2→3→4, como se muestra en la Figura 2-13. El retardo acumulado de esta ruta es
12+11+7 = 30.
 Figura 2-13: Topología de red con valores de retardo de enlace medidos

La configuración de esta Política SR en Nodo1 se muestra en el Ejemplo 2-3.

Se asigna un valor de color 30 a esta Política SR con dirección de punto final IPv4 [Link]. Este valor de color
es elegido por el operador para indicar el SLA de "bajo retardo".

Ejemplo 2-3: Configuración de la política SR Nodo1 - ruta dinámica

segment-routing
traffic-eng
POLÍTICA3
¡¡!! (verde, Nodo4)
color 30 end-point ipv4 [Link]
candidate-paths
preferencia 100
métrica
dinámic
a
tipo de retraso

Se especifica una ruta candidata para esta política SR: una ruta dinámica que minimiza el retardo de enlace
acumulado hasta el punto final. La métrica de retardo de enlace es el objetivo de optimización de esta ruta
dinámica. La dirección
La preferencia de la ruta candidata es 100.

Una ruta candidata dinámica que evita enlaces específicos

La siguiente Política SR en la cabecera Nodo1 también tiene una ruta candidata dinámica. Esta ruta de Política
SR proporciona la ruta más corta IGP evitando los enlaces rojos y se ilustra en la Figura 2-14.

Para calcular el camino, el Nodo1 poda los enlaces que no cumplen la restricción "evitar enlaces rojos" del
grafo de red en su DB SR-TE y calcula el camino más corto métrico IGP al Nodo4 en la topología podada. El
camino resultante es 1→2→3→6→5→4. Nodo1 codifica este camino en la lista SID óptima
<16003, 16004>. La primera entrada 16003 es el Prefijo-SID del Nodo3, transportando el paquete a través
del camino más corto IGP al Nodo3; y la segunda entrada 16004 es el Prefijo-SID del Nodo4, transportando
el paquete a través del camino más corto IGP al Nodo4.

Figura 2-14: Topología de red con afinidad de enlaces

La configuración de esta Política SR en Nodo1 se muestra en el Ejemplo 2-4.

Se asigna un valor de color 50 a esta Política SR con dirección de punto final IPv4 [Link]. El operador elige
este valor de color para indicar el SLA de esta ruta.

Ejemplo 2-4: Configuración de la política SR Nodo1 - ruta dinámica

segment-routing
traffic-eng
POLÍTICA4
¡¡!! (púrpura, Nodo4)
color 50 end-point ipv4 [Link]
candidate-paths
preferencia 100
métrica
dinámic
a
tipo igp
¡!
restriccione
s afinidad
excluir-
cualquier
nombre rojo
¡!
mapa de afinidad
nombre rojo bit-posición 3

Se especifica una ruta candidata para esta Política SR. La preferencia de la ruta candidata es 100.

El objetivo de optimización de esta ruta es minimizar el IGP acumulado hasta el punto final. La ruta no debe
atravesar ningún enlace "rojo", tal y como se especifica en las restricciones de esta ruta dinámica. exclude-any
name red significa evitar enlaces que tengan afinidad de enlace de color "rojo".
2.5 Resumen
Una Política SR consiste esencialmente en una lista ordenada de SIDs. En la instanciación SR-MPLS, esta
lista de SID se representa como una pila de etiquetas MPLS que se impone a los paquetes que se dirigen a la
política SR.

Una política de SR se identifica unívocamente mediante la tupla (nodo de cabecera, color, punto final).
Cuando se conoce la cabecera, una política de SR se identifica por (color, punto final).

El color se utiliza para distinguir varias políticas de SR entre el mismo nodo de cabecera y punto final. Suele
ser un identificador del SLA que proporciona la Política SR, por ejemplo, el color "verde=low-delay. El color
es clave para automatizar la dirección del tráfico (Automated Steering (AS) y la instanciación bajo demanda de
la Política SR (ODN)

Una política de SR tiene una o varias rutas candidatas.

Una ruta candidata puede calcularse dinámicamente (ruta dinámica) o especificarse explícitamente (ruta
explícita).

Para una ruta dinámica, la lista de SID se calcula en función de un objetivo de optimización y un conjunto de
restricciones proporcionados por la cabecera.

En el caso de una ruta explícita, la lista SID es especificada explícitamente por el operador o por una aplicación.
La cabecera no interviene en la especificación ni en el cálculo de la lista de SID de la ruta explícita. La cabecera
sólo tiene que validar la lista SID explícita.

Una ruta candidata puede ser instanciada a través de diferentes fuentes CLI/NETCONF o señalizada a través de
PCEP o BGP SR-TE. Una política SR puede contener rutas candidatas de diferentes fuentes.

La ruta candidata activa de una política SR es la ruta válida con mayor preferencia.

Los paquetes dirigidos a una política SR siguen la lista SID asociada a la ruta activa de la política SR.

Una política de SR está vinculada a un Binding-SID. El BSID es una clave de la política SR. En la
instanciación SR-MPLS, un BSID es una etiqueta local en la cabecera de la política. El tráfico recibido por la
cabecera con el BSID como etiqueta superior se dirige a la política. En concreto, el BSID se extrae y la lista
de SID activos se introduce en el paquete.
2.6 Referencias
[SR-book-Part-I] "Segment Routing Part I", Clarence Filsfils, Kris Michielsen, Ketan Talaulikar, octubre de
2016, ASIN: B01I58LSUO (Kindle), ISBN-10: 1542369126, ISBN-13: 978-1542369121,
<[Link]
<[Link]

[draft-ietf-spring-segment-routing-policy] "Arquitectura de políticas de enrutamiento por segmentos",

Clarence Filsfils, Siva Sivabalan, Daniel Voyer, Alex Bogdanov, Paul Mattes, draft-ietf-spring-segment-
routing-policy-02 (Trabajo en curso), octubre de 2018.

[RFC7471] "Extensiones de métrica de ingeniería de tráfico (TE) de OSPF", Spencer Giacalone, David Ward,
John Drake, Alia Atlas, Stefano Previdi, RFC7471, marzo de 2015.

[RFC7810] "Extensiones de métrica de ingeniería de tráfico (TE) de IS-IS", Stefano Previdi, Spencer
Giacalone, David Ward, John Drake, Qin Wu, RFC7810, mayo de 2016.

1. Por defecto, Nodo1 no invalida la lista de segmentos si se expresa utilizando valores de etiqueta.
Encontrará información sobre el control de la validación de una lista de segmentos en el capítulo 3, "Ruta
candidata explícita".más ↩

2. En este libro, utilizamos el término retardo" incluso en casos en los que se suele el término "latencia". La
razón es que la métrica que expresa el retardo de propagación del enlace se denomina "retardo de
enlace" (RFC 7810 y RFC 7471). Un trayecto de bajo retardo es entonces un trayecto con una métrica
acumulativa de retardo de enlace mínima.↩

3. El capítulo 7, "Algoritmo flexible", describe cómo operadores pueden ampliar su "caja de herramientas"
de segmentos definiendo sus propios Prefijo-SID.↩

4. Calcular una ruta es en realidad resolver un problema de optimización. Dada la información en la DB SR-
TE, encontrar el camino óptimo (minimizando la métrica especificada) mientras se adhiere a las
restricciones especificadas.↩
3 Trayectoria explícita del candidato
Lo que aprenderemos en este capítulo:

Una ruta candidata explícita se define formalmente como un conjunto ponderado de listas SID

Una ruta candidata explícita suele ser una única lista SID

Se puede configurar localmente una ruta candidata explícita en el nodo de cabecera

Una ruta candidata explícita puede ser instanciada en el nodo de cabecera por un controlador a través de un
protocolo de señalización

Un SID puede expresarse como un descriptor de segmento o un valor de etiqueta MPLS

Validación de una lista SID explícita y, por tanto, validación de una ruta candidata explícita

Ventajas e inconvenientes de utilizar un descriptor de segmento o un valor de etiqueta MPLS

Dos casos de uso: trayectos desunidos en doble plano y migraciones TDM

Una ruta candidata explícita de una política SR se asocia directamente con una lista de SIDs. Estos SID pueden
expresarse con sus valores de etiqueta MPLS o utilizando descriptores de segmento abstractos la cabecera
resuelve de forma determinista en valores de etiqueta. Esto último proporciona un nivel de resistencia frente a
los cambios en las asignaciones de etiquetas MPLS y permite a la cabecera validar la lista de SID antes de
configurar su tabla de reenvío. Por otro lado, el procedimiento de resolución requiere que la cabecera conozca el
valor de etiqueta de cada descriptor de segmento de lista SID. Dependiendo del alcance de la política SR y del
conocimiento de la entidad que la inicia, se preferirá un tipo de expresión sobre el otro.

En este capítulo se describe la instanciación de la ruta candidata explícita utilizando ambos tipos de expresión
SID, con ejemplos de escenarios en los que se utiliza cada una de ellas. También se detallan dos casos de uso
práctico para ilustrar mejor el papel de las rutas candidatas explícitas en despliegues del mundo real.
3.1 Introducción
Formalmente, una ruta candidata explícita se define como un conjunto ponderado de listas SID. Por ejemplo,
una ruta candidata explícita podría definirse como la lista SID <S1, S2, S3> con peso W1 y la lista SID <S4,
S5, S6> con peso W2. Si esta ruta candidata se selecciona como ruta activa de la política, las dos listas SID se
instalan en el plano de datos. Los flujos de tráfico dirigidos a la política SR se equilibran entre dos listas SID
con una proporción de W1/(W1+W2) en la primera lista y W2/(W1+W2) en la segunda.

En la práctica, la mayoría de los casos de uso definen una ruta candidata explícita como una única lista SID. Por
lo tanto, este capítulo se centra en caso de lista única, mientras que en el capítulo 16, "Operaciones SR-TE", se
ofrecen más detalles sobre la generalización de listas SID múltiples.

La propiedad clave de una ruta candidata explícita es que la lista SID se proporciona a la cabecera. La cabecera
no necesita calcularla y es ajena a la intención del para esta ruta candidata.

Un segmento de una lista SID explícita puede expresarse como una etiqueta SR-MPLS o como un descriptor de
segmento.

Intuitivamente, el descriptor de segmento de un Prefix SID es la dirección IP del prefijo relacionado y el

descriptor de un Adj-SID es la dirección IP de la adyacencia relacionada.

Una ruta candidata explícita puede iniciarse en un nodo de cabecera mediante configuración, utilizando la interfaz
de línea de comandos (CLI), la API XML clásica o el protocolo NETCONF; o mediante un protocolo de
señalización, como PCEP o BGP.

Aunque es posible que un operador configure manualmente este tipo de ruta en el nodo de cabecera, las
rutas explícitas suelen ser iniciadas por un controlador que, a continuación, también asume la
responsabilidad de supervisarlas y mantenerlas. Se denominan trayectos iniciados por el controlador.

La responsabilidad de la cabecera para una ruta candidata suele limitarse a:

1. Traducción de cualquier SID expresado como descriptor de segmento a una etiqueta SR-MPLS

2. Validación de la interfaz saliente y del siguiente salto

3.2 Etiquetas SR-MPLS
Los SID de la lista SID pueden especificarse como etiquetas MPLS, con cualquier valor del rango de etiquetas
MPLS.

Cada SID en una configuración de ruta explícita se asocia a un índice y la lista de SID se ordena por SID
crecientes. En este libro los índices se numeran en incrementos de 10, pero esto no es un requisito.

El Ejemplo 3-1 muestra la configuración requerida para especificar una lista SID, llamada SIDLIST1, con
valores de etiqueta MPLS. La primera entrada (índice 10) es la etiqueta 16008 que es el Prefijo-SID
asociado con el prefijo [Link]/32 en el Nodo8; la segunda entrada (índice 20) es la etiqueta 15085 que es
el Adj-SID del Nodo8 para su adyacencia al Nodo5; y la tercera entrada (índice 30) es la etiqueta 16004
que es el Prefijo-SID asociado con el Nodo4.

Ejemplo 3-1: Política SR con ruta explícita en Nodo1 - Lista SID usando etiquetas MPLS

segment-routing
traffic-eng
POLÍTICA1
color 10 end-point ipv4 [Link]
candidate-paths
preferencia 100
lista explícita de segmentos SIDLIST1
¡!
nombre de la lista de segmentos SIDLIST1
index 10 mpls label 16008 ¡¡!! Prefix-SID Node8
index 20 mpls label 15085 ¡¡!! Adj-SID link 8->5
index 30 mpls label 16004 ¡¡!! Prefix-SID Nodo4

El Adj-SID 15085 es un Adj-SID manual configurado en Nodo8 para su adyacencia a Nodo5. La etiqueta
15085 se asigna desde el SRLB del Nodo8. Como este Adj-SID está configurado, es persistente a través de
recargas.

La lista SID SIDLIST1 se utiliza como parte de una ruta candidata explícita para la Política SR POLICY1,
ilustrada en la Figura 3-1. El nodo de cabecera Nodo1 puede utilizar directamente las etiquetas MPLS en
SIDLIST1 para programar la entrada de la tabla de reenvío para POLICY1. El Nodo1 sólo necesita resolver el
primer SID 16008 para obtener la interfaz saliente que se asociará a la entrada de reenvío de la Política SR.
 Figura 3-1: Ejemplo de ruta explícita

La salida en el Ejemplo 3-2 muestra la política SR POLICY1 instanciada en el Nodo1 con la configuración en
el Ejemplo 3-1. El Nodo1 mapeó el primer valor de etiqueta SID 16008 al Prefijo-SID (línea 16). Nodo1 mapeó
el primer valor de etiqueta SID 16008 al Prefijo-SID (línea 16).

Ejemplo 3-2: Política SR que utiliza una lista de segmentos explícita con valores de etiqueta

1 RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng policy

2
3 Base de datos de la política SR-TE
4
5
6 Color: 10, Punto final: [Link]
7 Nombre: srte_c_10_ep_1.1.1.4
8 Estado:
9 Admin: activo Operativo: activo durante 00:00:15 (desde el 24 de enero 10:51:03.477)
10 Trayectorias de los candidatos:
11 Preferencia: 100 (configuración) (activa)
12 Denominación: POLÍTICA1
13 BSID solicitado: dinámico
14 Explícito: lista de segmentos SIDLIST1 (válido)
15 Peso: 1
16 16008 [Prefijo-SID, [Link]]
17 15085
18 16004
19 Atributos:
20 SID vinculante: 40014
21 Clase Adelante: 0
22 Dirección BGP desactivada: no
23 IPv6 caps enable: yes
Como se puede ver en el Ejemplo 3-2, IOS XR utiliza el nombre autogenerado srte_c_10_ep_1.1.1.4 para
identifica la política de SR. Este nombre está compuesto por el color 10 de la Política SR y el endpoint [Link].
El nombre configurado POLICY1 se utiliza como nombre de la ruta candidata.

El Nodo1 de la cabecera asigna dinámicamente el BSID 40014 para esta Política SR, como se muestra en el
Ejemplo 3-2 (línea 20) e instala la entrada de reenvío BSID para esta Política SR, como se muestra en
Ejemplo 3-3. La entrada de reenvío BSID ordena al Nodo1, para cualquier paquete entrante que tenga el BSID
40014 como etiqueta superior, para saltar la etiqueta BSID y dirigir el paquete a la política SR POLICY1, lo
que provoca la lista SID de la política SR se imponga al paquete.

Ejemplo 3-3: SR Policy BSID forwarding entry on headend Node1

RP/0/0/CPU0:xrvr-1#show mpls forwarding labels 40014

Local Saliente Prefijo Salida Siguiente salto Bytes
Etiqueta Etiqueta o ID Interfaz Conmutado

40014 Pop No ID srte_c_10_ep_1.1.1.4 point2point 0

La entrada de reenvío de la política SR se muestra en el Ejemplo 3-4. La pila de etiquetas impuesta es

(arriba→abajo): (16008, 15085, 16004). La interfaz saliente (Gi0/0/0/1) y el siguiente salto ([Link]) se
derivan del primer SID de la lista (16008) y apuntan hacia el Nodo7.

Ejemplo 3-4: Lista de segmentos impuesta por la política SR en la cabecera Nodo1

RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng forwarding policy detail

Color Punto final Segmento Saliente Saliente Próximo salto Lista
Bytes Etiqueta Interfaz Conmutado

10 [Link] SIDLIST1 16008 Gi0/0/0/1 [Link] 0

Pila de etiquetas (Arriba -> Abajo): { 16008, 15085,
16004 } Path-id: 1, Peso: 0
Paquetes conmutados:
0 Paquetes/Bytes Conmutados: 0/0
(!): FRR respaldo puro
3.3 Descriptores de segmento
Un descriptor de segmento identifica un SID de tal forma que el nodo de cabecera puede recuperar el valor
de etiqueta MPLS correspondiente a través de un procedimiento determinista de resolución de SID. Aunque
existen múltiples tipos de descriptores (véase draft-ietf-spring-segment-routing-policy), este capítulo se centra
en los dos tipos de descriptores más utilizados:

Dirección IPv4 que identifica su Prefijo-SID correspondiente

Dirección IPv4 que identifica un lin k(1) punto a punto numerado y su correspondiente Adj-SID El

descriptor de segmento de un Prefix-SID es su prefijo asociado. Dado que un Prefix-SID es siempre

asociado a un prefijo, la resolución de un prefijo descriptor al correspondiente valor de etiqueta SID es
directa. La asignación de prefijo a etiqueta SID se anuncia a través de IGP o BGP-LS y se almacena en la
base de datos SR-TE de cada nodo. Por ejemplo, la línea 11 de la instantánea SR-TE DB del Ejemplo 3-5
indica que el prefijo [Link](/32) está asociado con la etiqueta 16008.

Cuando hay varios algoritmos de Prefijo-SID disponibles en un dominio, el mismo prefijo puede estar
asociado a varios Prefijo-SID, cada uno vinculado a un algoritmo diferente. En ese , el prefijo por sí solo no es
suficiente para identificar de forma única un Prefix-SID y debe completarse con un identificador de algoritmo.
Si no se especifica el algoritmo, la cabecera selecciona por defecto el Prefijo-SID SPF estricto (algoritmo 1) si
está disponible, o el Prefijo-SID SPF normal (algoritmo 0) en caso contrario. Consulte el capítulo 7,
"Algoritmo flexible", para obtener información detallada sobre distintos algoritmos.

Del mismo modo, una dirección IP configurada en la interfaz de una adyacencia punto a punto puede servir
como descriptor de segmento de un Adj-SID. Dicha dirección IP identifica un enlace L3 específico en la red.
Por ejemplo, la dirección [Link] está configurada en el Nodo8 para su enlace con el Nodo5 y, por tanto,
identifica el enlace entre el Nodo5 y el Nodo8. La cabecera puede entonces deducir la dirección en la que ese
enlace debe ser atravesado a partir del SID precedente en la lista de SID. En este ejemplo, si el SID precedente
en la lista termina en el Nodo 5, entonces el enlace atravesarse desde el Nodo 5 hasta el Nodo 8. Por el
contrario, si el SID precedente en la lista termina en el Nodo 8, entonces el enlace debe atravesarse desde el
Nodo 5 hasta el Nodo 8. A la inversa, si el SID precedente terminara en el Nodo8, entonces ese mismo enlace
debería haber sido recorrido desde el Nodo8 hasta el Nodo5.
Esta inteligencia de cabecera permite que el descriptor de segmento sea la dirección IP de cualquiera de los
extremos del enlace; no es necesario que sea específicamente una dirección de interfaz local o remota. El
enlace y la dirección
identifican conjuntamente una adyacencia específica que la cabecera puede consultar en su DB SR-TE para
determinar el valor de la etiqueta Adj-SID.

Un nodo puede anunciar varios Adj-SIDs para una adyacencia dada. Típicamente, un Adj-SID protegido 2 y un
Adj-SID no protegido, como se ilustra en las líneas 23 y 35 del Ejemplo 3-5. En esta , la cabecera selecciona un
Adj-SID protegido por defecto.

Ejemplo 3-5: Traducción de descriptor de segmento a etiqueta MPLS

1 RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng ipv4 topology [Link]

2
3 Base de datos de topología SR-TE
4
5
6 Nodo 8
7 TE router ID: [Link]
8 Nombre del host: xrvr-8
9 ID del sistema ISIS: 0000.0000.0008 nivel-2
10 Prefijo SID:
11 Prefijo [Link], etiqueta 16008 (regular)
12
13 Enlace[0]: dirección local [Link], dirección remota [Link]
14 Nodo local:
15 ID del sistema ISIS: 0000.0000.0008 nivel-2
16 Nodo remoto:
17 TE router ID: [Link]
18 Nombre del host: xrvr-5
19 ID del sistema ISIS: 0000.0000.0005 nivel-2
20 Métrica: IGP 10, TE 10, Retardo 6
21 Admin-grupos: 0x00000000
22 Adj SID: 24085 (protegido) 24185 (no protegido)
23
24 Enlace[1]: dirección local [Link], dirección remota [Link]
25 Nodo local:
26 ID del sistema ISIS: 0000.0000.0008 nivel-2
27 Nodo remoto:
28 TE router ID: [Link]
29 Nombre del host: xrvr-6
30 ID del sistema ISIS: 0000.0000.0006 nivel-2
31 Métrica: IGP 10, TE 10, Retardo 10
32 Admin-grupos: 0x00000000
33 Adj SID: 24086 (protegido) 24186 (no protegido)

El Ejemplo 3-6 y la Figura 3-2 muestran como se usan estos descriptores de segmento como parte de una
configuración de lista SID explícita. La primera entrada (índice 10) usa la dirección IPv4 [Link] como el
descriptor de segmento para el Prefijo-SID asociado con el prefijo [Link]/32 de Nodo3. La segunda entrada
(índice 20) utiliza la dirección [Link] como descriptor de segmento para el Adj-SID del Nodo3 para su
adyacencia al Nodo4. La dirección [Link] está configurada en la interfaz del Nodo3 para el enlace punto a
punto entre el Nodo3 y el Nodo4, y el segmento precedente que termina en el Nodo3 indica que el enlace debe
ser atravesado desde el Nodo3 al Nodo4.
Ejemplo 3-6: SID especificados como descriptores de segmento

segment-routing
traffic-eng
POLÍTICA2
color 20 end-point ipv4 [Link]
candidate-paths
preferencia 100
lista explícita de segmentos SIDLIST2
¡!
nombre de la lista de segmentos SIDLIST2
index 10 address ipv4 [Link] ¡¡!! ¡¡Prefix-SID Nodo3
índice 20 dirección ipv4 [Link] !! Adj-SID enlace 3->4

Figura 3-2: Ejemplo de SID especificados como descriptores de segmento

La lista SID SIDLIST2 está configurada como una ruta candidata explícita de la política SR POLICY2. La
salida en el Ejemplo 3-7 muestra que la cabecera Nodo1 resolvió los descriptores de segmento en SIDLIST2 en
los valores de etiqueta correspondientes y los utilizó para programar la entrada de la tabla de reenvío para
POLICY2. La dirección [Link] se resuelve a la etiqueta Prefix-SID 16003 y [Link] a la etiqueta protegida
Adj-SID 24034.
Ejemplo 3-7: Política SR utilizando lista de segmentos explícita con direcciones IP

RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng policy

Base de datos de la política SR-TE

Color: 20, Punto final: [Link]

Nombre: srte_c_20_ep_1.1.1.4
Estado:
Admin: activo Operativo: activo durante 00:00:20 (desde el 4 de mayo
09:25:54.847) Rutas de candidatos:
Preferencia: 100 (configuración) (activa) Nombre:
POLÍTICA2
BSID solicitado: dinámico
Explícito: segment-list SIDLIST2 (válido) Peso: 1
16003 [Prefijo-SID, [Link]]
24034 [Adjacency-SID, [Link] - [Link]]
Atributos:
Encuadernación SID: 40114
Clase de reenvío: 0
Dirección BGP desactivada:
no Caps IPv6 activadas: sí

Si la etiqueta Adj-SID en Nodo3 para la adyacencia a Nodo4 cambia de valor, por ejemplo tras una recarga
de Nodo3, la cabecera Nodo1 actualiza automáticamente la lista SID con el nuevo valor de la etiqueta Adj-
SID. No se requiere ningún cambio de configuración en Nodo1.

Las entradas de reenvío BSID y SR Policy son equivalentes con el ejemplo anterior.

En los dos ejemplos anteriores, la lista SID explícita se configuró sólo con valores de etiqueta MPLS o sólo
con descriptores de segmento. Los descriptores de segmento y los valores de etiqueta MPLS también pueden
combinarse en una lista SID explícita, pero con una limitación: una vez que una entrada de lista SID se
especifica como un valor de etiqueta MPLS, todas las entradas posteriores también deben especificarse como
valores de etiqueta MPLS. En otras palabras, un SID especificado como descriptor de segmento no puede
seguir a un SID especificado como valor de etiqueta MPLS.
3.4 Validación de rutas
Un camino candidato explícito es válido si su lista de SID es válida. En términos más generales, cuando una
ruta candidata explícita se expresa como un conjunto ponderado de listas SID, la ruta candidata explícita es
válida si tiene al menos una lista SID válida.

Una lista SID es válida si se cumplen todas las condiciones siguientes:

La lista SID contiene al menos un SID

La lista SID tiene un peso superior a 0

La cabecera puede resolver todos los SID expresados como descriptores de segmento en etiquetas MPLS

La cabecera puede resolver el primer SID en una o más interfaces salientes y siguientes saltos La

primera condición es obvia: una lista de SID vacía no es válida.

Como se menciona en el capítulo 2, "Política SR", cada lista SID tiene un valor de peso asociado que controla
la cantidad relativa de tráfico dirigido a través de esta lista SID en particular. El peso por defecto es 1 para las
listas SID definidas como parte de una ruta candidata explícita. Si el peso es cero, lista SID se considera
inválida.

El nodo de cabecera utiliza la información de su DB SR-TE local para resolver cada SID especificado como
descriptor de segmento a su valor de etiqueta MPLS. Si un descriptor de segmento no está presente en la base
de datos SR-TE del nodo de cabecera, éste no podrá recuperar el valor de etiqueta correspondiente. Por lo tanto,
una lista SID que contenga un descriptor de segmento que no pueda resolverse se considerará inválida.

Por último, el nodo de cabecera debe ser capaz de averiguar dónde enviar el paquete tras imponer la lista de
SID. El nodo de cabecera utiliza su información local para determinar un conjunto de interfaces salientes y
próximos saltos a partir del primer SID de la lista. Si no es capaz de resolver el primer SID de una lista SID
en al menos una interfaz saliente y un siguiente salto, entonces esa lista SID no es válida.

Para ilustrar el procedimiento de validación de rutas explícitas, comparamos dos variantes de configuración
para la política SR ilustrada en la Figura 3-3: los SID especificados como valores de etiqueta y los SID
especificados como descriptores de segmento.
Se ha producido un fallo en la red: el enlace entre Nodo8 y Nodo5 se ha caído. Como resultado, el IGP retira
el Adj-SID de este enlace. La cabecera retira el Adj-SID de su DB SR-TE. Si este Adj-SID está protegido por
TI-LFA, el tráfico se reenviará temporalmente (~ 15 minutos) por la ruta de backup TI- LFA.

Figura 3-3: Ejemplo de ruta explícita

En primer lugar, considere el caso en el que los SID de lista de SID se especifican como valores de etiqueta.
Esta es la configuración del ejemplo 3-8. La lista de SID no está vacía y tiene el valor de peso predeterminado
de 1, por lo que se cumplen las dos primeras condiciones de validación. La siguiente condición no se aplica ya
que los SID se especifican como valores de etiqueta. El primer SID de la lista es 16008, que es el Prefijo-SID
del Nodo8. El Nodo8 todavía es alcanzable desde el Nodo1, a través del Nodo7, y por lo tanto el Nodo1 puede
resolver la interfaz saliente y el nexthop para 16008 en consecuencia. Esto satisface la última condición de
validación. En consecuencia, el Nodo1 sigue considerando la SIDLIST1 como válida y sigue dirigiendo el
tráfico hacia la POLICY1. Si el Adj-SID 15085 está protegido por TI-LFA, entonces el tráfico es reenviado a
lo largo de la ruta de backup y continúa alcanzando el Nodo4 durante un tiempo, pero empieza a ser descartado
por el Nodo8 tan pronto como el IGP elimina la ruta de backup del Adj-SID. Si el Adj-SID no está protegido,
entonces el tráfico es descartado inmediatamente por el Nodo8 cuando el enlace cae.
Ejemplo 3-8: Política SR con ruta explícita en Nodo1 - Lista SID usando etiquetas MPLS

segment-routing
traffic-eng
POLÍTICA1
color 10 end-point ipv4 [Link]
candidate-paths
preferencia 100
lista explícita de segmentos SIDLIST1
¡!
nombre de la lista de segmentos SIDLIST1
index 10 mpls label 16008 ¡¡!! Prefix-SID Node8
index 20 mpls label 15085 ¡¡!! Adj-SID link 8->5
index 30 mpls label 16004 ¡¡!! Prefix-SID Nodo4

Ahora, considere el caso donde los SIDs en la lista SID son especificados con descriptores de segmento. Esta es
la configuración del Ejemplo 3-9. Las dos primeras condiciones de validación, lista de SID no vacía y peso no
0, se cumplen. La cuarta condición también se cumple: el prefijo-SID 16008 del prefijo del Nodo8
[Link]/32 sigue siendo accesible desde el Nodo1 de cabecera a través del Nodo7. Sin embargo, cuando el
Nodo1 intenta resolver el segundo descriptor de segmento [Link] en un valor de etiqueta MPLS, es incapaz de
encontrar la dirección IP en su DB SR-TE. Esta entrada fue eliminada de la DB SR-TE tras la retirada del
enlace entre Nodo8 y Nodo5 en el IGP. El fallo en la resolución de este segundo descriptor de segmento viola la
tercera condición de validación y provoca que Nodo1 invalide SIDLIST2. La ruta candidata y la Política SR
también se invalidan ya que no otra opción disponible.

Ejemplo 3-9: SID especificados como descriptores de segmento

segment-routing
traffic-eng
POLÍTICA2
color 20 end-point ipv4 [Link]
candidate-paths
preferencia 100
lista explícita de segmentos SIDLIST2
¡!
nombre de la lista de segmentos SIDLIST2
¡¡index 10 address ipv4 [Link] !! Prefix-SID Nodo8
índice 20 dirección ipv4 [Link] !!Adj-SID enlace 8->5
índice 30 dirección ipv4 [Link] !! Prefijo-SID Nodo4

El Ejemplo 3-10 muestra el estado de la Política SR con la configuración del Ejemplo 3-9 cuando el enlace
Nodo8-Nodo5 está caído. Nótese que esta política SR está Operacionalmente caída (línea 9) ya que su única
ruta Candidata está caída.
Ejemplo 3-10: Política SR usando lista de segmentos explícita con direcciones IP - estado caído

1 RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng policy

2
3 Base de datos de la política SR-TE
4
5
6 Color: 20, Punto final: [Link]
7 Nombre: srte_c_20_ep_1.1.1.4
8 Estado:
9 Admin: activo Operativo: inactivo durante 00:00:06 (desde el 4 de mayo 10:47:10.263)
10 Trayectorias de los candidatos:
11 Preferencia: 100 (configuración)
12 Denominación: POLÍTICA2
13 BSID solicitado: dinámico
14 Explícito: lista de segmentos SIDLIST2 (inactiva)
15 Razón de inactividad: La dirección [Link] no puede resolverse a un SID
16 Peso: 1
17 Atributos:
18 Clase Adelante: 0
19 Dirección BGP desactivada: no
20 IPv6 caps enable: yes

Restricciones

Además de las cuatro condiciones de validación explicadas anteriormente, el operador puede expresar otras
restricciones a una ruta candidata explícita.

Por ejemplo, el operador puede solicitar a la cabecera que garantice que la ruta seguida por la lista SID
explícita nunca utilice un enlace o nodo con un SRLG o afinidad TE determinados, o puede exigir que el
retardo acumulado del enlace sea inferior a un límite.

El Capítulo 4, "Ruta candidata dinámica" contiene más información sobre las restricciones.

Resiliencia

Aunque las rutas explícitas son estáticas por naturaleza, se benefician de diferentes mecanismos de resiliencia.
Consideremos el Adj-SID S1 asociado al enlace L. Supongamos que S1 es el primer SID de la lista o se expresa
como un descriptor de segmento.

En caso de que L falle, la convergencia IGP garantiza que la DB SR-TE de la cabecera se actualice en unos
pocos cientos de mseg. La actualización de la DB SR-TE provoca la invalidación de S1, la invalidación de su
lista SID asociada y, por tanto, la invalidación de su ruta candidata explícita asociada (suponiendo que sea la
única lista SID para esta ruta candidata). Esta invalidación puede permitir que otra ruta candidata de la política
SR se active o puede provocar que la política SR se invalide y, por tanto, se elimine de la tabla de reenvío. En
tal caso, el tráfico seguiría la ruta más corta IGP por defecto (o se descartaría como se describe en el capítulo
16, "Operaciones SR-TE").
3.5 Consideraciones prácticas
En la práctica, la elección de expresar una lista SID con valores de etiqueta o descriptores de segmento
depende de varios factores, como la fiabilidad con la que la entidad que inicia la ruta puede mantenerla, o si
la cabecera tiene suficiente visibilidad para resolver todos los descriptores de segmento que se utilizarían en
la lista SID.

En esta sección se ofrecen algunas pistas sobre el modo de expresión más adecuado a través de varios ejemplos
prácticos.

Es posible que un controlador no quiera que la cabecera haga segundas interpretaciones

Un controlador externo suele calcular una ruta candidata explícita. El controlador conoce la intención de esa
ruta.

Este controlador suele supervisar la red en tiempo real y actualiza cualquier lista explícita de SID cuando es
necesario. Esto puede ocurrir cuando se pierde un enlace o nodo (se selecciona una ruta alternativa) o se
añade un enlace o nodo a la topología (ahora es posible una ruta mejor).

Como el controlador conoce la intención y supervisa la red en real, lo más probable es que no quiera que la
cabecera cuestione sus decisiones.

En tal caso, el controlador expresará los SID como etiquetas MPLS. La cabecera no comprueba la validez de
tales SID y el controlador mantiene el control total.

Un operador puede querer monitorizar la cabecera

El operador puede instanciar una Política de SR explícita como dos (o más) rutas candidatas explícitas (CPs):
CP1 con preferencia 200 y CP2 con preferencia 100. El operador no desea comprobar continuamente el estado
de la red y reaccionar rápidamente ante un cambio. En su lugar, el operador quiere que la cabecera cambie
automáticamente de CP1 a CP2 cuando CP1 deje de estar disponible y de CP2 a CP1 cuando CP1 esté
disponible.

En tal , el operador expresará los SID como descriptores de segmento. Esto obligará a la cabecera a validar cada
SID individualmente y, por tanto, la lista de SID en su totalidad. Cuando un SID de la lista de SID del CP1 deje
de ser válido, la cabecera invalidará toda la lista de SID y el CP1, y activará el CP2. Cuando el SID vuelva a ser
válido, la cabecera volverá a activar la lista de SID y activará CP1.
La traducción del SID se limita al dominio de la cabecera

Cuando se sabe que un descriptor de segmento no está presente en el DB SR-TE de la cabecera, el SID debe
expresarse como un valor de etiqueta. De lo contrario, la conversión de descriptor de segmento a valor de
etiqueta SID no funcionaría y, por lo tanto, no tendría sentido expresar el SID relacionado utilizando un
descriptor de segmento.

Este suele ser el caso cuando un SID se encuentra fuera del dominio local de la cabecera.

Las etiquetas asignadas dinámicamente son difíciles de predecir

Es necesario conocer el valor de etiqueta de un SID para poder utilizar ese modo de expresión.

Esto no es un problema para los Prefix-SID, ya que tienen valores de etiqueta fijos para toda la

red 3.

Puede ser un problema para Adj-SIDs o Peering-SIDs que a menudo utilizan valores de etiqueta asignados
dinámicamente que son difíciles - incluso imposibles - de predecir. Estas etiquetas dinámicas están sujetas a
cambios; por ejemplo, un router podría asignar diferentes valores de etiqueta para sus Adj-SIDs después de
haber sido recargado. Si el valor de la etiqueta Adj-SID cambia, la lista SID configurada con el antiguo valor
de etiqueta Adj-SID ya no proporciona la ruta correcta y debe ser reconfigurada.

Supongamos que en la configuración del Ejemplo 3-1 el operador había configurado la etiqueta Adj-SID
dinámica 24085 en lugar del Adj-SID manual. Entonces asume que el Nodo8 fue recargado y ha adquirido un
nuevo valor de etiqueta 24000 para el Adj-SID del enlace Nodo8→Nodo5. Dado que el antiguo valor de
etiqueta 24085 para este Adj-SID ya no es correcto, la entrada Adj-SID (índice 20) en la lista SID de la
política SR en Nodo1 debe entonces reconfigurarse, utilizando el nuevo valor de etiqueta, como índice 20
mpls label 24000.

Una solución a este problema es configurar explícitamente Adj-SIDs y Peering SIDs. Al estar configurados, son
persistentes, incluso tras recargas.
3.6 Ruta candidata iniciada por el controlador
Un controlador, o una aplicación por encima de un controlador, puede traducir un SLA desde una cabecera H a
un punto final E en una Ruta Candidata Explícita. Una vez calculada, el controlador señala la ruta a H a través
de PCEP o BGP SR-TE.

Dejamos los detalles del protocolo para los capítulos dedicados a estos protocolos. Por ahora, basta con saber
que estos protocolos proporcionan los medios para transmitir la ruta candidata explícita del controlador a la
cabecera.

Tras el intercambio de protocolos, el nodo de cabecera instala la ruta o la actualiza si ya existía.

Interfaces en dirección sur y norte

Las indicaciones hacia el sur y hacia el norte se refieren al dibujo arquitectónico típico, en el que la interfaz hacia el norte se dibuja encima del
componente ilustrado y la interfaz hacia el sur se dibuja debajo.

Para un controlador, ejemplos de la interfaz norte son: REST (Representational State Transfer) y NETCONF (Network Configuration Protocol).

Los ejemplos de interfaz sur de controlador son PCEP, BGP, XML clásico y NETCONF.

En la topología de la Figura 3-4, un controlador está programado para proporcionar una ruta de bajo retardo
desde el Nodo1 a
[Link] (Nodo4). El controlador está monitorizando la topología y se entera de que el enlace entre Nodo7 y
Nodo6 experimenta un retardo superior al normal, debido por ejemplo a un cambio de circuito óptico. Por lo
tanto, el controlador decide evitar este enlace iniciando en el Nodo1 de la cabecera un nuevo camino
explícito con la lista SID <16003, 16004>, que codifica el camino 1→2→3→6→5→4.

El controlador señala este camino para la Política SR (azul, [Link]) al Nodo1 de cabecera a través de su interfaz
hacia el sur. Esta ruta es una ruta candidata para la Política SR (azul, [Link]). Si la Política SR (azul, [Link]) ya
existe en el Nodo1 (iniciada por cualquier protocolo: CLI, PCEP, BGP, ...), este nuevo camino candidato se
añade a la lista de caminos candidatos de esta Política SR. A continuación, el procedimiento de selección de
rutas decide qué ruta candidata se convierte en la ruta activa. En este caso, suponemos que la Política SR (azul,
[Link]) aún no existe en Nodo1. Por lo tanto, el Nodo1 instanciará la Política SR con un único
y programa la entrada de reenvío para esta política SR. La ruta está entonces lista para ser utilizada, el tráfico
puede ser dirigido hacia ella.

Figura 3-4: Ruta iniciada por el controlador

Mediante este mecanismo, un controlador puede dirigir cualquier flujo de tráfico por cualquier ruta deseada a
través de la red con sólo programar la ruta de la política SR en nodo de cabecera.

El controlador es responsable de mantener la ruta. Por ejemplo, tras un cambio en la red, debe volver a
calcular la ruta y actualizarla en el Nodo1 de la cabecera si es necesario.
3.7 Migración TDM
En este caso de uso, explicamos cómo un operador puede vincular un pseudocable (PW) a una política de SR
específica y garantizar que el tráfico del PW se eliminará en la ruta seleccionada de la política de SR deje de
ser válida.

La dirección del PW en la política SR no es el objetivo de esta sección. Brevemente, usamos el mecanismo

de ruta preferida de L2VPN que nos permite dirigir un PW en una política SR. Detallaremos esto en el
capítulo 10, "Más detalles sobre el direccionamiento automatizado".

Esta sección se centra en dos mecanismos específicos:

La posibilidad de evitar el uso de una ruta de copia de seguridad TI-LFA FRR

Posibilidad de forzar la caída del tráfico en caso de invalidación de la política SR (en lugar de dejar que el PW
siga la ruta más corta del IGP).

Las rutas explícitas permiten fijar servicios en una ruta predefinida a través de la red. Esto puede ser
conveniente, por ejemplo, al migrar un servicio de multiplexación por división en el tiempo (TDM) a una
infraestructura IP/MPLS.

En el ejemplo de topología de la Figura 3-5, dos PWs disjuntos están configurados entre el Nodo1 y el
Nodo4. Estos PWs llevan altos volúmenes de tráfico y el operador no quiere que ambos PWs atraviesen el
mismo enlace central (2-3 o 6-5) ya que su carga combinada excede la capacidad de estos enlaces.

El operador configura dos Políticas SR en Nodo1 y dirige un PW en cada una de ellas utilizando la
funcionalidad de ruta preferente de L2VPN.
 Figura 3-5: Migración TDM

Cada una de estas dos Políticas SR tiene una lista SID explícita, donde los SIDs son los Adjacency-SIDs
desprotegidos de los enlaces en la ruta. Esto asegura que las políticas SR están fijadas a su ruta.

Adj-SID desprotegido

Los Adj-SIDs desprotegidos no están protegidos por un mecanismo de protección local como TI-LFA. Al utilizar este tipo de Adj-SIDs para esta
ruta, se puede habilitar la protección local en todos los enlaces de la red para que otros flujos de tráfico se beneficien de ella, mientras que los
flujos de tráfico que utilizan los Adj-SIDs desprotegidos no utilizan la funcionalidad de protección local.

La configuración relevante del Nodo1 se muestra en el Ejemplo 3-11. Los Adj-SIDs en las listas SID se
especifican como direcciones IP de interfaz. Por ejemplo, [Link] es la dirección IP de la interfaz en Nodo2
para su enlace a Nodo1.

El Nodo1 de cabecera mapea estas direcciones IP de interfaz al Adj-SID del enlace. Sin embargo, como se
mencionó en la sección 3.3, las direcciones IP son mapeadas a etiquetas Adj-SID protegidas por defecto. Por
lo tanto, se añade la línea de configuración constraints segments unprotected (ver líneas 10-12 del
Ejemplo 3-11) para indicar al Nodo1 que mapee las direcciones IP a las etiquetas Adj-SID desprotegidas.
Por defecto, una Política SR sin ruta candidata válida es invalidada y el tráfico que fue dirigido hacia ella
vuelve su ruta de reenvío por defecto, que es normalmente la ruta IGP más corta hacia su destino. Sin
embargo, en este caso de uso, el operador quiere forzar específicamente que el tráfico sea descartado tras la
invalidación de la Política SR. Este comportamiento se consigue configurando el direccionamiento
caída de invalidación bajo la Política SR (ver líneas 5-6 del Ejemplo 3-11).

"El comportamiento de invalidación-derrota es un gran ejemplo de colaboración entre operadores líderes.

El operador principal planteó su requisito en una fase muy temprana del proceso de diseño de SR-TE (~2014), lo que nos ayudó a
definir e implementar el comportamiento. Este comportamiento está disponible desde 2015 y se utiliza en el despliegue cuando el
operador interrumpir parte del tráfico en lugar de dejarlo fluir por rutas que no cumplen sus requisitos (por ejemplo, desde el punto de
vista del ancho de banda y la capacidad).... "

- Clarence Filsfils
Ejemplo 3-11: Migración TDM - configuración del Nodo1

1 segmento de enrutamiento
2 motor de tráfico
3 POLÍTICA1
4 color 10 end-point ipv4 [Link]
5 dirección
6 baja por invalidación
7 rutas de los candidatos
8 preferencia 100
9 lista explícita de segmentos SIDLIST1
10 limitaciones
11 segmentos
12 sin protección
13 ¡!
14 POLÍTICA2
15 color 20 end-point ipv4 [Link]
16 dirección
17 baja por invalidación
18 rutas de los candidatos
19 preferencia 100
20 lista explícita de segmentos SIDLIST2
21 limitaciones
22 segmentos
23 sin protección
24 ¡!
25 nombre de la lista de segmentos SIDLIST1
26 index 10 address ipv4 [Link] !! link 1->2
27 index 20 address ipv4 [Link] !! link 2->3
28 index 30 address ipv4 [Link] !! link 3->4
¡29 !
30 nombre de la lista de segmentos SIDLIST2
31 index 10 address ipv4 [Link] !! link 1->6
32 index 20 address ipv4 [Link] !! link 6->5
33 index 30 address ipv4 [Link] !! link 5->4
¡34 !
35 l2vpn
36 pw-class PREF-PATH1
37 encapsulación mpls
38 preferred-path sr-te policy POLICY1
¡39 !
40 pw-class PREF-PATH2
41 encapsulation mpls
42 preferred-path sr-te policy POLICY2
¡43 !
44 Grupo xconnect XG1
45 p2p PW1
46 interfaz GigabitEthernet0/0/0/0
47 neighbor ipv4 [Link] pw-id 1
48 clase pw PREF-PATH1
49 ¡!
50 p2p PW2
51 interfaz GigabitEthernet0/0/0/1
52 neighbor ipv4 [Link] pw-id 2
53 clase pw PREF-PATH2

En el momento de redactar este documento, la caída de la invalidación de la dirección y las

restricciones segmentos desprotegidos

sólo estaban disponibles en la CLI SR-TE inicial (y ahora obsoleta).

3.8 Trayectorias disjuntas en dos planos mediante Anycast-SID

"Existen al menos tres soluciones SR para el caso de uso de rutas disjuntas: SR Policy con una ruta dinámica, SR IGP Flex-Algo y Explicit
candidate path. En esta describimos la última opción. Describiremos las otras más adelante en este libro.

El punto clave que me gustaría destacar es que esta opción de ruta candidata explícita ha sido seleccionada para su despliegue.

En teoría, esta solución de ruta explícita no funciona cuando un nodo de acceso pierde todos sus enlaces con el plano azul elegido (2-
11 y 2-13 fallan ambos en la siguiente ilustración) o el plano azul se divide (11-12 y 13-14 fallan ambos).

Sin embargo, en la práctica, algunos operadores estiman que estos sucesos son muy poco probables, por lo que eligen esta solución
simple de doble plano por su sencillez pragmática.

Otros operadores prefieren una solución que garantice dinámicamente que el objetivo de disociación se cumpla siempre sea cual sea
el estado de la , aunque sea poco probable. Las otras dos opciones de diseño cumplen esos requisitos. Las trataremos más adelante en
el libro. "

- Clarence Filsfils

La topología de la Figura 3-6 muestra una topología de red de doble plano, un diseño que se utiliza en muchas
redes.

El plano azul está formado por los nodos 11 a 14.

El plano verde está formado por los nodos 21 a

24.

La práctica común consiste en configurar las conexiones entre planos, también conocidas como enlaces de
derivación, (por ejemplo, el enlace entre el Nodo11 y el Nodo21) con una métrica IGP alta (mala). Estos
enlaces se representan con líneas más finas para ilustrarlo.

Cuando los enlaces de derivación tienen una métrica tan alta, el tráfico que entra en un plano permanece en el
mismo plano hasta su destino. El único escenario que haría que el tráfico cruzara al otro plano es una partición
de su inicial; decir, un fallo que provoque que una parte del plano quede aislada del resto. En este caso, la
accesibilidad entre las particiones sólo posible a través del otro plano.
Esto es muy raro en la práctica, ya que requeriría al menos dos fallos independientes.

Los nodos de borde se conectan de forma redundante a cada plano, mediante enlaces directos o indirectamente a
través de otro nodo de borde.
 Figura 3-6: Trayectorias disjuntas en dos planos utilizando anycast-SID

Supongamos que todos los nodos azules están configurados con Anycast-SID 16111 y todos los nodos verdes
con Anycast-SID 16222.
 Anycast-SID

explicamos en la Parte 1 de este libro, los Anycast-SID no sólo proporcionan más equilibrio de carga y resistencia de los nodos, sino que también
son útiles para expresar políticas de macroingeniería que dirigen el tráfico a través de grupos de nodos ("conjuntos anycast") en lugar de a través
de nodos individuales. Cada miembro de un conjunto anycast anuncia el mismo Anycast-SID.

Todos los nodos del plano azul anuncian el Anycast-SID 16111. Para ello, la configuración del Ejemplo 3-12 se aplica en todos nodos del plano
azul. En esencia, un Anycast-SID es un Prefijo-SID que es anunciado por múltiples nodos. Por lo tanto, para se utiliza la configuración Prefix-
SID normal. Todos los nodos del plano azul anuncian el mismo prefijo Loopback1 [Link]/32 con Prefijo-SID 16111.

Ejemplo 3-12: Rutas disjuntas de doble plano - configuración anycast-SID

interfaz Loopback1
description blue plane anycast address
ipv4 address [Link]/32
¡!
router isis 1
interface Loopback1
address-family ipv4 unicast
prefix-sid absolute 16111 n-flag-clear

Por defecto, al configurar un Prefix-SID, su indicador N está activado, lo que indica que el Prefix-SID identifica un único nodo. Sin embargo,
un Anycast-SID no identifica a un único nodo, sino a un grupo de nodos: un conjunto anycast. Por lo tanto, un Anycast-SID debe anunciarse
con el indicador N del Prefix-SID desactivado, lo que requiere la palabra clave n-flag-clear en la configuración del Prefix-SID. Tenga en
cuenta que para ISIS, esta configuración también borra el indicador N en el atributo de prefijo.
 Segmentos Anycast: versátiles y potentes

"Los segmentos anycast son, en mi , una herramienta muy versátil y potente para cualquier diseñador de redes que no quiera o no
pueda confiar completamente en un controlador central para iniciar todas las rutas necesarias. Siempre que las políticas de TE sean
diseñadas e incluso configuradas por un humano, los segmentos anycast pueden resolver varios problemas:

Proporcionan resistencia. Más de un nodo puede llevar el mismo SID y es posible que varios nodos sirvan para el mismo
propósito y se sustituyan entre sí. Véase el capítulo 8, "Resistencia de la red".

Utilizar el mismo SID o descriptor SID en todos los routers simplifica significativamente la configuración de los mismos.

El esfuerzo de TI se reducirá a menudo, ya que se necesitan menos parámetros para generar la configuración de cada router.

Por último, los segmentos anycast pueden un método de abstracción: Un Anycast-SID ya no sólo representa un nodo o grupo de
nodos concreto, sino más bien una función que debe aplicarse a un paquete, o una determinada propiedad de reenvío de un paquete
a través de una red.

Así pues, para mis necesidades específicas, los segmentos anycast son un elemento esencial de cómo el enrutamiento por segmentos
lleva la ingeniería de tráfico a un nivel completamente nuevo. "

- Martin Horneffer

En tal topología de doble plano, una solución muy sencilla para dirigir el tráfico a través del plano azul al
Nodo3 consiste en imponer la lista SID <16111, 16003>, donde 16003 es el Prefijo-SID del Nodo3.

De hecho, el 16111 dirige el tráfico al plano azul y luego el diseño de doble plano garantiza que permanezca en
el mismo plano hasta su destino. El tráfico no utilizaría el otro plano, ya que los enlaces de derivación tienen
una métrica muy mala y se necesitarían múltiples fallos independientes para particionar el plano azul.

Del mismo modo, el tráfico puede dirigirse en el plano verde con la lista SID <16222, 16003>.

Para dirigir el tráfico a través del plano azul, el operador configura una política SR "BLUE" con color azul
(valor 10), endpoint [Link] (Nodo3) y la lista de segmentos explícita SIDLIST1, como se muestra en
Ejemplo 3-13. Esta lista SID se expresa con dos descriptores de segmento: [Link] se resuelve en el segmento
plano azul Anycast-SID 16111 y [Link] mapea al Prefijo-SID del Nodo3.

Una segunda política SR, denominada "GREEN", con color verde (valor 20), endpoint [Link] (Nodo3) y la
lista SID explícita SIDLIST2 se utiliza para dirigir el tráfico a través del plano verde. SIDLIST2 también
contiene
dos entradas: [Link] corresponde al plano verde Anycast-SID 16222 y [Link] corresponde al Prefix-SID del
Nodo3.

Ejemplo 3-13: Trayectorias disjuntas de doble plano utilizando anycast-SID - configuración

segment-routing
traffic-eng
política AZUL
color 10 end-point ipv4 [Link]
candidate-paths
preferencia 100
lista explícita de segmentos SIDLIST1
¡!
política VERDE
color 20 end-point ipv4 [Link]
candidate-paths
preferencia 100
lista explícita de segmentos SIDLIST2
¡!
nombre de la lista de segmentos SIDLIST1
index 10 address ipv4 [Link] !! blue plane anycast index 20
address ipv4 [Link]
¡!
nombre de la lista de segmentos SIDLIST2
index 10 address ipv4 [Link] !! green plane anycast index 20
address ipv4 [Link]

Ahora, supongamos que se requiere un servicio L3VPN entre Nodo1 y Nodo3, con dos VRFs: azul y verde.
Estas dos VRFs deberían ser transportadas por caminos separados siempre que sea posible. Esto se puede
conseguir dirigiendo los paquetes azules VRF a la política SR BLUE, y los paquetes verdes VRF a la política
SR GREEN. Los detalles del direccionamiento del tráfico se tratan en el capítulo 5, "Direccionamiento
Automatizado". Por ahora, es suficiente saber que los prefijos de color azul se dirigen a la política SR de color
azul y los prefijos de color verde se dirigen a la política SR de color verde.

La salida de traceroute en el Ejemplo 3-14 muestra que el tráfico del VRF azul atraviesa el plano azul (nodos
11 a 14) mientras que el tráfico del VRF verde atraviesa el plano verde (nodos 21 a 24). Ambos prefijos VRF
[Link] y [Link] tienen al Nodo3 como siguiente salto BGP.

Las etiquetas MPLS en el paquete recibido por Nodo2 son el Anycast-SID del plano, 16111 o 16222, el Prefix-
SID del siguiente salto BGP, 16003, y la etiqueta VPN 9000x para el prefijo.
Ejemplo 3-14: Rutas disjuntas de doble plano utilizando anycast-SID - traceroute

RP/0/0/CPU0:xrvr-1#traceroute vrf blue [Link]

Escriba la secuencia de escape para

abortar. Rastreando la ruta a
[Link]

1 [Link] [MPLS: Etiquetas 16111/16003/90009 Exp 0/0/0] 19 mseg 19 mseg 19 mseg

2 [Link] [MPLS: Etiquetas 16003/90009 Exp 0/0] 29 mseg 19 mseg 19 mseg
3 [Link] [MPLS: Etiquetas 16003/90009 Exp 0/0] 19 mseg 19 mseg 19 mseg
4 [Link] 19 mseg 19 mseg 19 mseg RP/0/0/CPU0:xrvr-

1#traceroute vrf green [Link]

Escriba la secuencia de escape para

abortar. Rastreando la ruta a
[Link]

1 [Link] [MPLS: Etiquetas 16222/16003/90007 Exp 0/0/0] 19 mseg 19 mseg 19 mseg

2 [Link] [MPLS: Etiquetas 16003/90007 Exp 0/0] 29 mseg 19 mseg 19 mseg
3 [Link] [MPLS: Etiquetas 16003/90007 Exp 0/0] 19 mseg 19 mseg 19 mseg
4 [Link] 19 mseg 19 mseg 19 mseg
3.9 Resumen
Se puede proporcionar una ruta explícita a la cabecera mediante configuración o señalada por un controlador
(NETCONF, PCEP, BGP).

Una ruta candidata explícita se define formalmente como un conjunto ponderado de listas SID. Una ruta
candidata explícita suele ser una única lista SID.

Un nodo de cabecera no interviene en el cálculo de la ruta ni en la codificación de la lista SID de una ruta
explícitainstanciará una ruta explícita al pie de la letra, tal y como se proporciona.

Un SID puede expresarse como una etiqueta MPLS o un descriptor de segmento.

Se prefiere un descriptor de segmento cuando se desea que la cabecera valide el SID.

No se puede utilizar un descriptor de segmento para un SID desconocido para la cabecera (por ejemplo,

interdominio). Una ruta candidata explícita es válida si al menos una de sus listas de SID es válida.

Una lista SID explícita es válida si se todas las condiciones siguientes:

La lista SID contiene al menos un SID

La lista SID tiene un valor de peso superior a 0

La cabecera puede resolver todos los SID expresados como descriptores de segmento

La cabecera puede resolver el primer SID en una o más interfaces salientes y siguientes saltos. Una

ruta candidata explícita tiene muchas aplicaciones. Ilustramos dos de ellas:

Migración TDM a una infraestructura basada en SR

Trayectorias disjuntas en una red de doble plano

3.10 Referencias
[SR-book-Part-I] "Segment Routing Part I", Clarence Filsfils, Kris Michielsen, Ketan Talaulikar, octubre de
2016, ASIN: B01I58LSUO (Kindle), ISBN-10: 1542369126, ISBN-13: 978-1542369121,
<[Link]
<[Link]

[RFC8402] "Arquitectura de enrutamiento por segmentos", Clarence Filsfils, Stefano Previdi, Les Ginsberg,
Bruno Decraene, Stephane Litkowski, Rob Shakir, RFC8402, julio de 2018.

[draft-ietf-spring-segment-routing-policy] "Arquitectura de políticas de enrutamiento por segmentos",

Clarence Filsfils, Siva Sivabalan, Daniel Voyer, Alex Bogdanov, Paul Mattes, draft-ietf-spring-segment-
routing-policy-02 (Trabajo en curso), octubre de 2018.

1. Restringir este descriptor de segmento a enlaces punto a punto permite determinar el SID con una única
dirección de interfaz, en lugar de con un par de direcciones de interfaz (local, remota) en el caso
general.↩

2. Como se describe en el libro SR Parte I y en el capítulo 8, "Network Resiliency", un Adj-SID protegido

está habilitado para FRR mientras que su homólogo desprotegido no lo está.↩

3. A menos que no utilice el mismo SRGB en todos los nodos, lo que se desaconseja totalmente.↩
4 Trayectoria dinámica del candidato
Lo que aprenderemos en este capítulo:

El cálculo dinámico de una ruta SR-TE consiste en resolver un problema de optimización con un objetivo de
optimización y restricciones. La información de la DB SR-TE se utiliza para calcular una ruta.

Se han desarrollado algoritmos optimizados para SR para calcular rutas y codificar estas rutas en listas
SID para hacer un uso óptimo de los beneficios de SR, aprovechando el ECMP disponible en la red.

El nodo de cabecera o un elemento de cálculo de trayectos (PCE) puede calcular trayectos SR-TE.

El software base IOS XR ofrece la funcionalidad de servidor SR PCE.

En muchos casos, el propio nodo de cabecera puede computar rutas SLA en una única área IGP, por ejemplo
computar rutas optimizadas en retardo, o rutas que eviten recursos específicos.

Para cálculos de trayectos específicos, en los que la cabecera no dispone de la información necesaria en su
DB SR-TE, el nodo de cabecera utiliza un SR PCE para calcular los trayectos. Por ejemplo, calcular
trayectos disjuntos desde distintos nodos de cabecera o calcular trayectos interdominio de extremo a
extremo.

Una cabecera no sólo solicita a un SR PCE que calcule rutas, sino que también puede delegar el control de
las en el SR PCE, que las mantiene de forma autónoma.

La base de datos SR-TE multidominio de forma nativa. El SR PCE aprende las topologías de todos los
dominios y los Peering-SID de los enlaces de peering BGP a través de BGP-LS.

La funcionalidad SR PCE puede distribuirse entre varios servidores SR PCE a lo largo de la red. Si es
necesario, estos servidores pueden sincronizarse entre .
4.1 Introducción
Un trayecto candidato dinámico es un trayecto candidato de una política SR que es calculado automáticamente
por una cabecera (encaminador) o por un elemento de cálculo de trayecto (PCE) a petición de la cabecera. Este
tipo de ruta se vuelve a calcular automáticamente cuando es necesario para adaptarse a una red cambiante.

4.1.1 Expresión del objetivo y las restricciones de la ruta dinámica

Mientras que una ruta explícita se expresa como una lista de segmentos, una ruta dinámica se expresa como un
objetivo de optimización y un conjunto de restricciones. Estos dos elementos especifican la intención SR-TE.

El objetivo de optimización es la característica de la ruta que debe optimizarse. Normalmente, se trata de la

minimización de una métrica específica, como la métrica de enlace IGP o la métrica mínima de retardo de
enlace.

Las restricciones son limitaciones que debe respetar el trayecto resultante. Por ejemplo, se puede querer que la
ruta evite enlaces o grupos de enlaces específicos o que tenga una métrica de ruta acumulativa que esté
limitada por un valor máximo.

4.1.2 Calcular ruta= Resolver problema de optimización

Calcular un camino a través de una red que satisfaga una serie de requisitos dados es resolver un problema de
optimización, básicamente un problema de camino más corto con restricciones.

"Encontrar el camino más corto a cada nodo de la " es un ejemplo de problema de optimización que se
resuelve utilizando el conocido algoritmo Shortest Path First (SPF) de Dijkstra. Para resolver este problema,
el algoritmo de Dijkstra utiliza el grafo de la red (formado por nodos y enlaces, también conocidos como
vértices y aristas en la teoría de grafos) y un coste asociado a cada arista (enlace).

En redes, los IGP de estado de enlace utilizan el algoritmo de Dijkstra para calcular el Árbol del Camino más
Corto (SPT); el coste de la arista es entonces la métrica de enlace IGP. Los prefijos son hojas que cuelgan de
los nodos (vértices).

La información necesaria para ejecutar el SPF de Dijkstra y calcular la accesibilidad a los prefijos (nodos,
enlaces y prefijos) se distribuye a través de los IGP de estado de enlace. Cada nodo guarda esta información en
su base de datos de estado de enlace (LS-DB).

Esto introduce dos elementos necesarios para calcular los trayectos en una red: una base de datos
que contiene toda la información necesaria sobre la red y un motor de cálculo que aplica
algoritmos a la información para resolver el problema de optimización, es decir, calcular rutas dinámicas.

Base de datos

La base de datos utilizada para el cálculo es la SR-TE DB. Además del grafo de la red (nodos y enlaces), la BD
SR-TE contiene otros elementos de información que el motor de cálculo utiliza para resolver distintos problemas
de optimización. Algunos ejemplos lo ilustran. Para calcular rutas con retardo optimizado, se necesita
información sobre el retardo de los enlaces. Para proporcionar trayectos disjuntos, se necesita información
sobre los trayectos programados.

El capítulo 12, "Base de datos SR-TE", entra en mucho más detalle sobre la base de datos SR-TE.

Motor de cálculo

El motor de cálculo traduce una intención SR-TE en una lista SID.

Los algoritmos de cálculo de rutas son el núcleo del motor de cálculo. Se han desarrollado algoritmos de
optimización SR-native eficientes basados en una amplia investigación científica; véase el documento de
SIGCOMM 2015 [SIGCOMM2015].

Este capítulo se centra en cuatro casos de uso: trayectos con optimización de retrasos, trayectos para evitar
recursos, trayectos disjuntos y trayectos entre dominios.

4.1.3 Algoritmos SR nativos frente a algoritmos basados en circuitos

MPLS-TE clásico (RSVP-TE) se diseñó hace 20 años como hermano de ATM/FR. Su componente fundamental
es un circuito punto a punto no ECMP con estado por circuito en cada salto.

Aunque el ECMP está omnipresente en las redes IP, las rutas clásicas RSVP-TE basadas en circuitos no
aprovechan este ECMP por definición. Como resultado, la solución RSVP-TE necesita muchos túneles entre el
mismo conjunto de cabeceras y puntos finales para utilizar múltiples rutas a través de la red (un túnel sobre
cada ruta posible). Esto aumenta drásticamente la complejidad operativa y disminuye la escalabilidad debido al
número de necesarios para un equilibrio adecuado de la carga de tráfico.

Como se ha indicado anteriormente, se ha investigado mucho en el desarrollo de algoritmos eficientes de

cálculo de rutas optimizadas para SR-TE. Estos algoritmos utilizan de forma nativa las características de la red IP
y aprovechan de forma inherente todas las rutas ECMP disponibles. El resultado de un algoritmo nativo
optimizado para SR
es una lista reducida de SID que aprovecha las capacidades de SR, como los segmentos multisalto y el
conocimiento de ECMP.

Pocas SID, ECMP

"Como se explica en la introducción de la Parte 1, la intuición para el Enrutamiento por Segmentos surgió mientras conducía hacia
Roma y me di cuenta de que el camino a Roma evitando el paso del Gottardo (el camino más corto a Roma desde Bruselas es a través
del paso del Gottardo) podría expresarse simplemente como "desde Bruselas, ir a Chamonix y luego desde Chamonix ir a Roma".
Sólo se necesitan dos segmentos. Todas simulaciones que hicimos más tarde confirmaron esta intuición básica pero clave: se
necesitaban pocos SID.

Mi experiencia en el diseño y despliegue de redes había dicho que ECMP es una propiedad básica de las redes IP modernas. De ahí
que, mientras conducía hacia , también intuyera que los trayectos enrutados por segmentos favorecerían naturalmente el ECMP.

Esto estaba claro porque cada segmento de prefijo expresa un camino más corto y las topologías de red están diseñadas de tal
manera que los caminos más cortos implican tanto ECMP como sea posible (para compartir la carga y utilizar mejor los recursos
y por robustez).

Esta propiedad ECMP se demostró más tarde con todas las simulaciones que hicimos. "

- Clarence Filsfils

Para ilustrar las ventajas de los algoritmos SR-native sobre la solución RSVP-TE clásica basada en circuitos,
la Figura 4-1 compara la optimización RSVP-TE basada en circuitos con la optimización SR-TE. En la
topología se calcula una ruta utilizando ambos métodos desde el Nodo1 al Nodo3, evitando el enlace entre el
Nodo2 y el Nodo3.
 Figura 4-1: Optimización del circuito frente a optimización del SR

La solución RSVP-TE poda primero el enlace rojo. En segundo lugar, calcula el camino más corto de 1 a 3 en el
gráfico podado. En tercer lugar, selecciona un único camino no ECMP del camino más corto (potencialmente
ECMP). En este ejemplo, hay tres posibles caminos más cortos y supongamos que RSVP-TE elige el camino
1→4→5→7→3. Aplicando esta antigua solución basada en circuitos a SR se especificaría cada enlace de la
ruta, dando lugar a una lista SID <24014, 24045, 24057, 24073>, donde 240XY representa el Adj-SID de
NodoX a NodoY. Esta lista de SID puede acortarse a <16005, 16003>, donde 1600X es el Prefijo-SID del
NodoX, utilizando un algoritmo trivial de lista de ruta a SID. Sin embargo, esto no es tan bueno como la
solución nativa SR descrita en este capítulo. Todavía no aprovecha ECMP y este cálculo de ruta clásico no
puede adaptar la ruta a los requisitos específicos de SR, como el tamaño de la lista de segmentos o más rutas
ECMP.

La solución SR-TE utiliza un algoritmo completamente distinto que trata de aprovechar al máximo el ECMP
utilizando el menor número de SID. Por esta razón, lo llamamos algoritmo "SR-nativo". En este ejemplo, el
algoritmo nativo SR encuentra la lista SID <16007, 16003>, donde 1600X es el Prefijo-SID del NodoX. Esta
lista de SID sólo utiliza dos SID. Esta lista SID equilibra la carga de tráfico en 3 rutas.
Está claro que el algoritmo SR-native es preferible para las aplicaciones SR.
4.2 Computación distribuida
El motor de cálculo SR-TE puede funcionar en una cabecera (router) o en un elemento de cálculo de trayecto SR
(SR PCE). En el primer caso se trata de una solución distribuida, mientras que en el segundo se trata de una
solución centralizada. Tanto la cabecera como el SR PCE aprovechan los algoritmos nativos de SR.

La implementación de SR-TE en IOS XR se puede utilizar como cabecera de SR-TE y como PCE de SR.

Cuando sea posible, se debe aprovechar el cálculo de la ruta SR-TE de la cabecera (diseño distribuido). Esto
proporciona una solución muy escalable. Cuando sea necesario, el cálculo de la ruta se delega en un SR PCE
(centralizado).

El encaminador y el SR PCE utilizan los mismos algoritmos de cálculo de rutas. La diferencia de su funcionalidad
no es el motor de cálculo, sino el contenido de la DB SR-TE.

La DB SR-TE de una cabecera suele limitarse al dominio local y a las políticas SR locales.

La DB SR-TE de un SR PCE puede contener (mucha) más información, como el estado de otras Políticas SR
e información adicional de rendimiento. Conocer otras Políticas SR permite el cálculo de rutas disjuntas, y
conocer otros dominios permite el cálculo de rutas entre dominios.

El cálculo de un trayecto SR-TE desde una cabecera a un punto final dentro de la misma área IGP sólo requiere
información del área IGP local. El nodo de cabecera aprende la información de su área IGP local y, por lo tanto,
puede calcular por sí mismo dichos trayectos. En las secciones 4.2.1 y 4.2.2 se detallan dos ejemplos de este
tipo: bajo retardo y exclusión de recursos.

En un modelo distribuido, la propia cabecera calcula las rutas localmente. Siempre que sea posible, debe
utilizarse este modelo, ya que ofrece una solución muy escalable.

4.2.1 La cabecera calcula la ruta de bajo retardo

El operador de red desea proporcionar una ruta de bajo retardo para una aplicación sensible al retardo. El
origen y el destino de la ruta se encuentran en la misma área IGP. Para que SR-TE pueda calcular dicho
trayecto, la información sobre el retardo de los enlaces debe estar disponible en la DB de SR-TE. Cada nodo
del área mide los retardos de sus enlaces e inunda la métrica de retardo de enlace medida en el IGP.
 Métrica de retardo del enlace

El operador puede utilizar la métrica de retardo de enlace medida, que el router mide dinámicamente por enlace y distribuye en el IGP. Esta
metodología tiene la ventaja de garantizar siempre un retardo de enlace correcto, incluso si la topología óptica cambia debido a la restauración
del circuito óptico. Además, el uso del retardo de enlace medido elimina la complejidad operativa de configurar manualmente los retardos de
enlace. Consulte el capítulo 15, "Supervisión del rendimiento - Retardo de enlace" para obtener más detalles sobre la funcionalidad de la métrica
de retardo medido.

En caso de que la medición y distribución directa de la métrica de retardo de enlace no esté disponible, el operador puede utilizar la métrica de
enlace TE para representar el retardo de enlace. La métrica TE es una métrica de enlace adicional, distribuida en la IGP, que el operador puede
aprovechar para representar las necesidades de una aplicación concreta. Si los retardos de enlaces en la red son constantes y conocidos (por
ejemplo, basados en información proveniente de la red óptica y longitudes de fibra), el operador puede configurar la métrica de enlace TE para
representar el retardo (estático) del enlace.

Dado que cada nodo distribuye las métricas de retardo de enlace en el IGP, cada nodo cabecera de la zona
recibe esta información y la almacena en su DB SR-TE. De este modo, un nodo de cabecera dispone de la
información necesaria para calcular rutas con retardo optimizado en la red.

Para que una cabecera introduzca la información aprendida del IGP en la DB SR-TE, se debe configurar el
comando distribute link-state en el IGP, como se ilustra en el Ejemplo 4-1 tanto para ISIS como para
OSPF. Este comando tiene un parámetro opcional instance-id <id>, que sólo es relevante en topologías
multidominio. Ver capítulo 17, "BGP-LS" para más detalles.

Ejemplo 4-1: Alimentar DB SR-TE con información IGP

router isis SR
distribute link-state
¡!
router ospf SR
distribute link-state

Como ejemplo, el operador ha habilitado los nodos de la red de la Figura 4-2 para medir el retardo de sus
enlaces. Los retardos de enlace actuales se muestran en la ilustración como el retardo de enlace unidireccional
en milisegundos. Las métricas de enlace IGP son 10.
 Figura 4-2: La cabecera calcula la ruta de bajo retardo

El operador necesita una ruta con retardo optimizado desde el Nodo1 al Nodo5 y configura una Política SR en
el Nodo1 con una ruta dinámica, optimizando la métrica de retardo. El ejemplo 4-2 muestra la configuración de
la política SR en el Nodo1. La política SR "LOW-DELAY" tiene una única ruta candidata que se calcula
dinámicamente optimizando la métrica de retardo. No se aplican restricciones de ruta.

Ejemplo 4-2: Configuración de la política SR - ruta dinámica de bajo retardo computada en cabecera

segment-routing
traffic-eng
política LOW-DELAY
color 20 end-point ipv4 [Link]
candidate-paths
preferencia 100
dinámica
métrica
tipo de retraso

El camino resultante, 1→2→3→4→5 con un retardo acumulado de 10 + 10 + 10 + 9 = 39 ms, se ilustra en la

Figura 4-2. Esta ruta puede expresar con una lista de SID <16003, 16004, 16005>, donde 1600X es el Prefijo-
SID del NodoX. Cada uno de estos Prefijo-SIDs expresa el camino más corto IGP a su nodo destino. Esta lista
SID se muestra en el Ejemplo 4-3.
Ejemplo 4-3: Ruta de política SR de bajo retardo calculada en cabecera

RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng policy

Base de datos de la política SR-TE

Color: 20, Punto final: [Link]

Nombre: srte_c_20_ep_1.1.1.5
Estado:
Admin: up Operativo: up for 06:57:40(since Sep 14 07:55:11.176)
Candidate-paths:
Preferencia: 100 (configuración) (activa) Nombre:
LOW-DELAY
BSID solicitado: dinámico
Dinámico (válido)
Tipo de métrica: retardo, Métrica de la ruta acumulada:
39 16003 [Prefijo-SID, [Link]]
16004 [Prefijo-SID, [Link]]
16005 [Prefijo-SID, [Link]]
Atributos:
Encuadernación SID: 40026
Clase de reenvío: 0
Dirección BGP desactivada:
no Caps IPv6 activadas: sí

El operador se da cuenta de que esta ruta con retardo optimizado sólo utiliza la ruta a través del Nodo4,
mientras que hay disponibles dos rutas de igual coste (métrica IGP) entre el Nodo3 y el Nodo5. Esto se debe a
una pequeña diferencia en el retardo del enlace entre estas dos rutas desde el Nodo3 al Nodo5: la ruta a través
del Nodo4 tiene un retardo de 10+ 9 = 19 ms, mientras que la ruta a través del Nodo6 tiene un retardo de 10+
10= 20 ms, 1 ms más. El operador considera insignificante la diferencia de retardo entre estas dos y preferiría
aprovechar el ECMP disponible entre el Nodo3 y el Nodo5.

El operador puede conseguirlo especificando un margen para tolerar una solución que no sea óptima pero que
esté dentro del margen especificado de la solución óptima. El margen puede especificarse como valor
absoluto o como valor relativo (porcentaje), ambos en comparación con la solución óptima.

En el Ejemplo 4-4 se especifica un margen absoluto de 2 ms (2000 µs) para la ruta dinámica de la Política
SR al Nodo5 en Nodo1. El retardo acumulado de la ruta de solución puede ser hasta 2 ms mayor que la ruta
de retardo mínimo. Con esta configuración la lista SID de la solución es <16003, 16005>, que aprovecha el
ECMP entre Nodo3 y Nodo5.

Utilice la palabra clave relative para especificar un margen relativo.

Ejemplo 4-4: Trayectoria dinámica con margen de retardo

segment-routing
traffic-eng
política LOW-DELAY
color 20 end-point ipv4 [Link]
candidate-paths
preferencia 100
dinámica
métrica
tipo de retraso
margen absoluto 2000

Margen de retraso

"Ya en 2014, cuando diseñamos los algoritmos nativos de SR-TE, nos dimos cuenta de que la intuición de utilizar tanto ECMP como fuera
posible no funcionaría para la optimización del retardo sin la noción de margen.

En primer lugar, expliquemos la razón. De nuevo, se trata de algo muy intuitivo.

El ser humano optimiza las topologías de red y asigna métricas IGP para potenciar la naturaleza ECMP de los caminos más cortos.

Por ejemplo, a dos fibras entre Bruselas y se les asigna el mismo coste IGP de 10 mientras que una fibra recorre 300 km y la otra
500 km. Desde el punto de vista de la capacidad, esta diferencia de distancia no importa.

Desde el punto de vista del retardo, sí importa. El control dinámico del rendimiento de las dos fibras basado en routers detectará una
diferencia 200 km/c ≈ 1 mseg, donde c es la velocidad de la luz en la fibra.

El IGP inundará un enlace con 1,5 mseg de retardo y el otro enlace con 2,5 mseg de retardo.

Los routers remotos que calculen una ruta de bajo retardo (por ejemplo, de Estocolmo a Madrid) tendrían que insertar un prefijo-SID
en Bruselas seguido del SID de adyacencia de la primera fibra para asegurarse de que se evita la segunda fibra. Dos SID más y sin
ECMP sólo para ganar 1 mseg entre Estocolmo y Madrid.

Podríamos adivinar fácilmente que algún operador preferiría menos SID y más ECMP a cambio de cierto margen en torno a la ruta de
bajo retraso.

De ahí que hayamos introducido la noción de margen para la optimización SR-nativa de bajo retardo.

A continuación, diseñamos el algoritmo correspondiente que encuentra el trayecto enrutado por segmentos con la menor cantidad de
SID dentro del margen sobre el trayecto de menor retardo. "

- Clarence Filsfils

Siempre que la topología cambia, o las medidas de retardo de enlace cambian significativamente (ver capítulo
15, "Monitorización del Rendimiento - Retardo de Enlace", donde se discute la medida de retardo de enlace), el
Nodo cabecera1 re-computa los caminos en la nueva topología y actualiza la lista SID de la Política SR en
consecuencia.
4.2.2 La cabecera calcula rutas restringidas
El operador debe proporcionar una ruta que evite determinados recursos.

La red del ejemplo es una red de doble plano. Una característica de este diseño de red es que, cuando un
paquete aterriza en un plano, permanece en hasta su destino, siempre que el plano no esté particionado. Por
defecto, los flujos de tráfico se equilibran en ambos planos.

El operador puede dirigir los flujos de tráfico hacia uno de los planos. Esto se puede conseguir de varias
maneras. Una forma es utilizando un Anycast-SID asignado a todos los dispositivos de un plano, como se
describe en el capítulo anterior (capítulo 3, "Explicit Candidate Path").

Otra posibilidad es calcular trayectorias dinámicas, restringiendo la trayectoria a un plano determinado. Este
método se describe en esta sección. Otra posibilidad es utilizar la funcionalidad Flex-Algo descrita en el
capítulo 7, "Algoritmo flexible".
 Exclusión de recursos

"La riqueza de solución SR-TE permite resolver un problema dado de diferentes maneras, cada una de ellas con distintas

compensaciones. Ilustrémoslo con el caso de uso de los caminos disjuntos en el plano dual (por ejemplo, imponer un flujo a

través del plano azul).

En el capítulo 3 sobre , "Explicit Candidate Pathrutas explícitas", mostramos una primera solución utilizando el SID anycast del plano

azul. En este sobre rutas dinámicas mostramos una segunda solución utilizando una ruta dinámica con un "verde de afinidad

excluyente".

Más , en el capítulo 7 de SR IGP Flex-Algo, "Algoritmo flexible", describiremos una tercera solución.

La primera solución no requiere ninguna inteligencia en la cabecera, pero puede no adaptarse a problemas de topología poco frecuentes.

La segunda solución requiere inteligencia de cabecera SR-TE (SR-TE DB y el algoritmo SR-native) sin cambio o dependencia de
IGP en toda la red.

La tercera solución aprovecha el propio IGP, pero requiere una capacidad de funciones en toda la red.

En mi opinión, cada uno es útil, y la selección se hace caso por caso en función de la situación específica del operador.

Mi experiencia lo confirma, ya que he participado en el despliegue de las dos primeras y, en el momento de escribir estas líneas,
participo en el despliegue del tercer tipo de solución. Cada operador tenía sus razones específicas para preferir una solución a otra.

La solución SR se construye como módulos. Cada operador puede utilizar el módulo que desee en función de su análisis específico
y sus preferencias. "

- Clarence Filsfils

[Link] Colores de los enlaces de afinidad

Para dirigir los flujos de tráfico en un único plano, el operador utiliza una Política SR con una ruta dinámica que
está restringida al plano deseado. Una forma de aplicar esta restricción es utilizando la funcionalidad de
afinidad de enlaces. Los enlaces en cada plano están coloreados; los enlaces en un plano están coloreados en
azul y los enlaces en el otro plano en verde. La ruta a través del plano verde se puede calcular como "optimizar
la métrica IGP, evitando los enlaces azules", y la ruta a través del plano azul como "optimizar la métrica IGP,
evitando los enlaces verdes".
 Colores de los enlaces y afinidad

Un operador puede marcar enlaces con los llamados colores de enlace de afinidad, conocidos como grupos administrativos en la terminología
IETF. Históricamente, había 32 colores diferentes (grupos) disponibles, ampliados posteriormente para permitir más (256 colores en Cisco IOS
XR). Estos colores permiten asignar enlaces a grupos o clases. Por ejemplo, los enlaces de una región determinada son de color rojo y los enlaces
de otra región son de color verde.

Los colores de un enlace se anuncian en el IGP como un mapa de bits, en el que cada color representa un bit. El IGP anuncia los mapas de bits de
afinidad con las adyacencias. Un operador puede elegir libremente qué bit representa cada color. Por ejemplo, el color rojo está representado por
el primer bit del mapa de bits y el color verde por el tercer bit. Si un enlace tiene un color determinado, el mapa de bits de afinidad de ese enlace
se anuncia con el bit del color correspondiente configurado. Cada enlace puede tener varios colores, en cuyo se activarán varios bits del mapa de
bits.

Estos colores de enlace se insertan en la DB SR-TE. Un nodo de cabecera puede entonces utilizar estos colores de enlace en su cálculo de ruta para
incluir o excluir enlaces con un determinado color o conjunto de colores en la ruta. Por ejemplo, el operador puede especificar que se calcule una ruta
dinámica, optimizando la métrica IGP y evitando los enlaces con color rojo.

Consulte RFC 3630, RFC 5305 y la Sección 6.2 de RFC 2702 para obtener información del IETF sobre afinidad y colores de enlace.

La topología de la Figura 4-3 es una red de dos planos. Un , denominado "Verde", está formado por los nodos
11 a 14, mientras que el otro plano, denominado "Azul", está formado por los nodos 21 a 24. El nodo2 y el
nodo3 están conectados a ambos planos. Los nodos 2 y 3 están conectados a ambos planos. Todos los enlaces
del plano Verde están coloreados con el mismo color de afinidad (verde), los enlaces del plano Azul con otro
color de afinidad (azul).

Figura 4-3: ejemplo de evitación de recursos por afinidad en doble plano

La configuración del color de afinidad se ilustra con la configuración del Nodo2 en el Ejemplo 4-5. Este nodo
tiene un enlace en cada plano, el enlace al Nodo11 en el plano Verde y el enlace al Nodo21 en el plano Azul.

La configuración comienza definiendo nombres de colores de afinidad amigables. Estos nombres pueden ser
cualquier cadena definida por el usuario, no sólo nombres de colores como se suele mostrar en los ejemplos.
Cada nombre identifica un bit específico en el mapa de bits de afinidad. La posición del bit en el mapa de
bits está basada en cero, el primer bit tiene la posición 0. El nombre VERDE en el ejemplo corresponde al
bit en la posición 0 del mapa de bits (posición 0 de VERDE), el nombre AZUL corresponde al bit en la
posición 2.

El esquema de nomenclatura de los mapas de afinidad es significativo a nivel local; los nombres y su
asignación a las posiciones de bits no se distribuyen. La coherencia es clave; se recomienda encarecidamente
tener una configuración coherente de asignación de nombres a posiciones de bits en todos los nodos, por
ejemplo, mediante el uso de un sistema de orquestación.

Una vez definidos los nombres, se pueden asignar a los enlaces. La interfaz Gi0/0/0/0 en Nodo2 está en el
plano Verde y está marcada con afinidad VERDE (nombre de afinidad VERDE), mientras que la interfaz
Gi0/0/0/1, que está en el plano Azul, está marcada con el nombre AZUL. Cada enlace puede marcarse con
varios nombres configurando varios nombres de afinidad en la interfaz. El nodo anuncia entonces para cada
interfaz el mapa de bits de afinidad con los bits que corresponden a los nombres configurados puestos a 1.

Ejemplo 4-5: Asignación de colores de enlaces de afinidad - Nodo2

segment-routing
traffic-eng
mapa de afinidad
nombre VERDE bit-posición 0
nombre AZUL bit-posición 2
¡!
interfaz Gi0/0/0/0
!! enlace a Nodo11, en plano Verde
afinidad nombre VERDE
¡!
interfaz Gi0/0/0/1
!! enlace a Nodo21, en plano Azul
afinidad nombre AZUL

Dado que cada nodo anuncia el mapa de afinidad de sus enlaces en el IGP, todos los nodos del área IGP
reciben esa información y la insertan en su DB SR-TE. Un nodo de cabecera puede entonces utilizar esta
información en sus cálculos de ruta.

[Link] Restricción de afinidad

El operador configura dos Políticas SR para Nodo3 en Nodo1. Cada política SR utiliza uno de los dos planos.
El operador configura una Política SR para calcular una ruta dinámica que evite los enlaces AZUL, por lo tanto
restringida al plano Verde, y otra Política SR con una ruta que evite los enlaces VERDES,
por lo tanto restringido al plano Azul. La configuración de la Política SR del Nodo1 se muestra en el Ejemplo 4-6.

Ejemplo 4-6: Ejemplo de evitación de recursos de color de enlace de afinidad - Nodo1

segment-routing
traffic-eng
política VIA-PLANE-GREEN
color 20 end-point ipv4 [Link]
candidate-paths
preferencia 100
dinámica
métrica
tipo igp
¡!
restriccione
s afinidad
excluir
cualquier
nombre AZUL
¡!
política VIA-PLANE-BLUE
color 30 end-point ipv4 [Link]
candidate-paths
preferencia 100
dinámica
métrica
tipo igp
¡!
restriccione
s afinidad
excluir-
cualquier
nombre
VERDE

La primera política SR, denominada VIA-PLANE-GREEN, tiene color 20 y endpoint [Link] (Nodo3). Se
configura una única ruta candidata, calculando dinámicamente una ruta optimizada para la métrica IGP,
excluyendo los enlaces con color AZUL. El Nodo1 de cabecera calcula localmente la ruta. En la Figura 4-3 se
muestra la ruta resultante. Obsérvese que ruta sigue el plano Verde, aprovechando el ECMP disponible dentro
de este plano. El ejemplo 4-7 muestra el estado de esta política SR en el Nodo1.
Ejemplo 4-7: Estado de la Política SR en Nodo1

RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng policy

Base de datos de la política SR-TE

Color: 20, Punto final: [Link]

Nombre: srte_c_20_ep_1.1.1.3
Estado:
Admin: up Operativo: up para 00:10:54 (desde Mar 2 17:27:13.549) Rutas-
candidato:
Preferencia: 100 (configuración) (activa) Nombre:
VIA-PLANO-VERDE
BSID solicitado: dinámico
Restricciones:
Afinidad:
excluir-
cualquiera:
AZUL
Dinámico (válido)
Tipo de métrica: IGP, Métrica de la ruta acumulada:
50 16014 [Prefijo-SID, [Link]]
16003 [Prefijo-SID, [Link]]
Atributos:
Encuadernación SID: 40048
Clase de reenvío: 0
Dirección BGP desactivada:
no Caps IPv6 activadas: sí

La segunda Política SR en la configuración del Nodo1, llamada VIA-PLANE-BLUE, dirige el tráfico a lo largo
del plano Azul. El Nodo1 calcula esta ruta optimizando la métrica IGP y evitando los enlaces de color VERDE.

Cada vez que cambia la topología, el Nodo1 de la cabecera vuelve a calcular las rutas de las Políticas SR en la
nueva topología y actualiza las listas SID de las Políticas SR en consecuencia.

Con la configuración del Ejemplo 4-6, hay tres rutas disponibles para el Nodo3, dos a través de políticas SR
y una a través de la ruta más corta IGP. Las Políticas SR restringen el tráfico a uno de los planos, mientras
que la ruta más corta IGP utiliza ambos planos.

Por defecto, el tráfico de servicio se dirige a través del camino más corto IGP a su . Si el nexthop tiene un
Prefijo-SID asociado, éste será impuesto. Este es el comportamiento de reenvío Prefix-SID por defecto. Por
ejemplo, el tráfico de servicio con nexthop Nodo3 se dirige a través del Prefijo-SID 16003 del Nodo3.

El prefijo IGP-SID 16003 sigue el camino más corto IGP sin restricciones, aprovechando todos los caminos
ECMP disponibles. Por lo tanto, por defecto, los flujos de tráfico del Nodo1 al Nodo3 no se limitan a un único
plano, sino que se distribuyen por todos los ECMP disponibles.
El direccionamiento del tráfico de servicio a las políticas SR hacia su nexthop puede realizarse utilizando el
direccionamiento automático (AS) adjuntando el color de la política SR requerida al prefijo de destino.
Adjunte el color 20 para dirigir el tráfico de servicio hacia la política SR VIA-PLANE-GREEN y el color 30
para dirigirlo hacia la política SR VIA- PLANE-BLUE. El Capítulo 5, "Automated Steering" describe AS con
más detalle.

Esto ofrece al operador tres posibilidades de dirección: a través de ambos planos para destinos no coloreados, a
través del plano Verde para destinos con color 20, y a través del plano Azul para destinos con color 30.

4.2.3 Otros casos de uso y limitaciones

[Link] Rutas disjuntas limitadas a una única cabecera
Los trayectos disjuntos (diversos) son trayectos que no atraviesan elementos comunes de la red, como
enlaces, nodos o SRLG. Para calcular trayectos SR-TE disjuntos, se necesita información sobre todos los
trayectos.

Si las rutas disjuntas tienen una cabecera común y los puntos finales de estas rutas están dentro de la misma
área IGP, la cabecera puede calcular estas rutas por sí misma. En ese caso, la cabecera conocimiento del
área IGP local y de ambos trayectos, ya que es la cabecera de ambos.

Si los trayectos disjuntos tienen cabeceras distintas, estas cabeceras no pueden calcular los trayectos, ya sólo
conocen sus propios trayectos de política SR y desconocen los trayectos de política SR de la otra cabecera. Si
una no conoce la otra ruta, no es posible calcular una ruta disjunta.

Este caso de uso requiere una solución centralizada en la que una entidad de cómputo centralizada conozca
ambos trayectos para proporcionar aptos disjuntos. La sección 4.3 de este capítulo detalla el caso de uso de
rutas disjuntas entre dos conjuntos de cabeceras y extremos.

[Link] La ruta entre dominios requiere información multidominio

El cálculo de rutas que atraviesan diferentes áreas o dominios IGP requiere el conocimiento de todas estas
áreas y dominios IGP.

Normalmente, un nodo de cabecera sólo conoce su área IGP local. Es posible que la base de datos SR-TE de
la cabecera contenga una base de datos de topología multidominio, pero esto todavía no se ve en la práctica,
por razones de escalabilidad.
Si el nodo de cabecera no dispone de información multidominio, no puede calcular los trayectos interárea e
interdominio. Para ello es necesario utilizar una solución centralizada. La sección 4.3.3 de este capítulo
detalla el caso de uso del cálculo de rutas entre dominios.
4.3 Cálculo centralizado
Cuando sea posible, se debe aprovechar el cálculo de la ruta SR-TE de la cabecera (diseño distribuido). Cuando
sea necesario, el cálculo de la ruta se delega en un SR PCE (centralizado).

El encaminador y el SR PCE utilizan los mismos algoritmos de cálculo de rutas. La diferencia de su funcionalidad
no es el motor de cálculo, sino el contenido de la DB SR-TE.

La DB SR-TE de una cabecera suele limitarse a su dominio local y a sus propias políticas SR, como ya se ha
señalado.

La DB SR-TE de un SR PCE puede contener más información, como la topología de otros dominios y el
estado de otras Políticas SR. El conocimiento de otros dominios permite el cálculo de rutas entre dominios.
El conocimiento de otras Políticas SR permite el cálculo de rutas disjuntas.

4.3.1 SR PCE
Un elemento de cálculo de trayecto (PCE) es un elemento de la red que proporciona un servicio de cálculo de
trayecto a los clientes de cálculo de trayecto (PCC).

Normalmente, un PCC se comunica con un PCE utilizando el protocolo de comunicación PCE (PCEP). Cada
nodo de cabecera puede actuar como PCC y solicitar al PCE que calcule un trayecto utilizando un modelo
cliente/servidor de solicitud/respuesta. El PCE calcula el trayecto y responde al PCC proporcionándole los
detalles del mismo.

Para calcular los trayectos, un SR PCE tiene una base de datos SR-TE y un motor de cálculo, como un nodo de
cabecera SR-TE. Para su área IGP local, el PCE SR obtiene la información topológica del IGP y la almacena en
su DB SR-TE. El PCE utiliza esta información para calcular los trayectos, utilizando los mismos algoritmos de
cálculo de trayectos que un nodo de cabecera.

Un nodo de cabecera actúa como PCC y solicita a un SR PCE que calcule una ruta a un punto final. En su
solicitud, la cabecera proporciona el objetivo y las restricciones de optimización de la ruta. A continuación, el
SR PCE calcula la ruta y la devuelve al PCC (cabecera) en forma de lista SID. A continuación, la cabecera
instanciará esta ruta.

Pero un PCE SR puede hacer más que calcular rutas; como PCE con estado, puede controlar rutas. Un PCC
entrega el control de un camino un PCE delegando este camino al PCE.
 "Es una tarea muy tediosa organizar la eficiencia de una red en lo que respecta a RSVP-TE. Tenemos que ajustar manualmente los
temporizadores, el coste y añadir muchas políticas de ruta para asegurarnos de que el tráfico utilice el patrón que queremos.

La ruta dinámica SR-TE reduce drásticamente esta complejidad y elimina la necesidad de intervención manual, al tiempo que
mantiene una infraestructura de red altamente optimizada y robusta. Un caso de uso sencillo son las rutas disjuntas para el streaming
de vídeo; cuando se envían flujos duplicados, la ruta dinámica SR-TE nos permite asegurarnos de que las dos copias nunca utilizarán
los mismos enlaces a lo largo de toda ruta desde el origen hasta el destino. Esto se consigue recopilando automáticamente
información de la LS-DB al PCE SR. El PCE puede entonces calcular rutas de política SR que se ajusten al objetivo deseado, como
el retardo, y a las restricciones. "

- Daniel Voyer

Servidor IOS XR SR PCE

La funcionalidad de servidor SR PCE está disponible en la imagen de software IOS XR base y se puede utilizar
en todas las plataformas IOS XR físicas y virtuales.

La funcionalidad SR PCE se puede habilitar en cualquier nodo IOS XR que ya esté en la red. Sin embargo,
por motivos de escalabilidad y para evitar una mezcla de funcionalidades en un nodo determinado, puede ser
conveniente desplegar nodos independientes para la funcionalidad de servidor SR PCE, utilizando una
plataforma de hardware o virtual.

La funcionalidad de servidor SR PCE se habilita en IOS XR utilizando una configuración como la del Ejemplo
4-8. La dirección IP configurada se utiliza para la sesión PCEP entre el PCC y el PCE. Debe ser una dirección
IP local accesible globalmente (no en una VPN).

SR PCE recibe su información de topología de los diferentes protocolos (ISIS, OSPF y BGP) a través de una
API interna. Para permitir que el IGP (ISIS u OSPF) del nodo PCE alimente su base de datos IGP link-state
(LS-DB) al proceso SR-TE, configure distribuir link-state bajo el IGP. De esta forma, el servidor SR
PCE aprende la información topológica del área IGP local y la inserta en su DB SR-TE. BGP alimenta
automáticamente su información BGP-LS al SR PCE, sin configuración adicional, como se describe en la
sección 4.3.3. El instance-id 101 en el comando distribute link-state es el identificador de dominio
que se utiliza para distinguir entre dominios en la DB SR-TE. Esto se explica con más detalle en el capítulo
12, "Base de datos SR-TE" y en el capítulo 13, "SR PCE".
Ejemplo 4-8: Configuración del servidor SR PCE

pce
dirección ipv4 [Link]
¡!
router isis SR !! o "router ospf SR"
distribute link-state instance-id 101

Cliente IOS XR PCE (PCC)

Para habilitar una cabecera como Cliente PCE (PCC), configurar la dirección del SR PCE, como se muestra en
el Ejemplo 4-9 para un PCE con dirección [Link]. Con esta configuración, el PCC establece una sesión PCEP
con el SR PCE. Se pueden configurar múltiples PCEs con un orden de , como se explica en el capítulo 13, "SR
PCE".

Ejemplo 4-9: Dirección PCE en PCC

segment-routing
traffic-eng
pcc
dirección pce ipv4 [Link]

[Link] SR PCE Redundancia

SR PCE utiliza la funcionalidad de alta disponibilidad de PCEP existente para proporcionar redundancia. Los tres
componentes principales de esta funcionalidad son el aprendizaje de topología, la notificación de políticas SR y
el comportamiento de redelegación.

Una cabecera tiene una conexión PCEP con un par (o incluso un grupo mayor) de PCEs. Para la redundancia, es
importante que estos PCEs tengan un conocimiento común de la topología y de las Políticas SR en la red. De
esta forma, la cabecera puede utilizar cualquiera de estos PCEs en caso de que su PCE primario falle.

Todos los PCEs conectados tienen el mismo conocimiento de la topología ya que todos reciben la misma
alimentación de topología del IGP y/o BGP-LS.

Cuando una política SR se instala, actualiza o elimina, la cabecera envía un informe de estado de la política SR
a todos sus conectados. Esto mantiene sincronizada la base de datos de directivas SR de todos estos PCE, y así
un PCE puede actuar como reserva de otro PCE.

Una cabecera delega el control de una ruta de política de SR a un único PCE de SR, el PCE de SR primario que
también computa la ruta.
El fallo de este PCE primario, no afecta a las Políticas SR que se le delegan ni al tráfico que se dirige a él. En
caso de fallo de este PCE, la cabecera mantiene las políticas SR y las delega en otro PCE conectado. Este
nuevo PCE delegado asume el control de la ruta, la verifica y la actualiza si es necesario. Dado que la
información disponible para todos los PCE de este conjunto es la misma y los PCE utilizan los mismos
algoritmos de cálculo de rutas, la ruta no se actualizará si la topología no ha cambiado entretanto.

Encontrará más detalles en el capítulo 13, "SR PCE".

4.3.2 SR PCE calcula rutas disjuntas

En este primer caso de uso de cálculo centralizado, un PCE de SR centralizado calcula rutas disjuntas desde
dos cabeceras diferentes. El SR PCE no sólo calcula los trayectos, sino que los controla. Estos son los
requisitos clave para proporcionar disjuntas óptimas desde diferentes cabeceras.

La red de la Figura 4-4 es una red de área única que interconecta dos emplazamientos de clientes, el
Emplazamiento 1 y el Emplazamiento 2. El operador de esta red desea proporcionar trayectos disjuntos entre
los emplazamientos de los clientes. El operador de esta red desea proporcionar trayectos disjuntos entre los
emplazamientos de los clientes. Las rutas separadas parten de dos nodos de cabecera diferentes: una ruta del
Nodo1 al Nodo4 y otra ruta del Nodo5 al Nodo8.
 Figura 4-4: Topología de red para rutas disjuntas

Se añade un SR PCE a la red. A efectos ilustrativos, el SR PCE se dibuja como entidad independiente. En el
Capítulo 13, "SR PCE", se tratan las diferentes opciones de conectividad del SR PCE.

Las cabeceras Nodo1 y Nodo5 no pueden simplemente calcular los caminos más cortos IGP habituales a
Nodo4 y Nodo8 respectivamente, ya que estos caminos no son disjuntos, como se ilustra en la Figura 4-5. Los
dos caminos más cortos IGP comparten Nodo6, Nodo7 y el enlace entre Nodo6 y Nodo7. Los dos caminos
más cortos IGP comparten el Nodo6, el Nodo7 y el enlace entre el Nodo6 y el Nodo7.
 Figura 4-5: Los caminos más cortos IGP no son disjuntos

Las cabeceras no pueden calcular caminos disjuntos de forma independiente, ya que ninguna de ellas conoce el
camino calculado por la otra.

Proporcionar trayectos disjuntos en una red IP/MPLS siempre ha sido engorroso, especialmente cuando los
trayectos disjuntos deben conseguirse entre pares de nodos distintos. El operador podría utilizar restricciones de
trayecto para conseguir trayectos disjuntos. El operador podría, por ejemplo, utilizar colores de enlace de
afinidad para marcar los enlaces atravesados por la ruta del Nodo5 al Nodo8 y luego excluir estos enlaces de la
ruta entre el Nodo1 y el Nodo4. Sin embargo, esta solución no garantiza que se encuentren caminos disjuntos.
Además, supondría una carga operativa, ya que habría que actualizar los colores de los enlaces cada vez que
cambiara la topología. Es muy deseable disponer de una solución dinámica que proporcione un servicio de rutas
disjuntas. El SR PCE ofrece esta solución.

[Link] Grupo disjunto

Las rutas disjuntas se expresan asignándolas a una entidad denominada grupo de asociación disjunta, o
grupo disjunto para abreviar.

Un identificador de grupo identifica un grupo disjunto. Los trayectos con el mismo identificador de grupo
disjunto (es decir, miembros del mismo grupo disjunto) son disjuntos entre sí. Los grupos disjuntos pueden
aplicarse a trayectos con origen en el
misma cabecera o cabeceras diferentes.

El operador indica qué caminos deben ser disjuntos entre sí asignando a ambos caminos el mismo identificador
de grupo disjunto. El PCE entiende y aplica esta restricción.

Un grupo disjunto también especifica los parámetros de diversidad, como el tipo deseado de caminos disjuntos:
enlace, nodo, SRLG, o nodo+SRLG. El tipo de trayectos disjuntos indica qué recursos no se comparten entre
los dos trayectos disjuntos, por ejemplo, los trayectos disjuntos de enlace no comparten ningún enlace, los
trayectos disjuntos de nodo no comparten ningún nodo, etc.

[Link] Solicitud de ruta, respuesta e informe

El operador primero configura el Nodo5 como un PCC especificando la dirección [Link] del SR PCE. Luego
operador configura una Política SR al Nodo8 en el , como se muestra en el Ejemplo 4-10.

La política SR, denominada POLICY1, tiene una única ruta candidata dinámica con preferencia 100. La palabra
clave pcep bajo dynamic indica que el Nodo5 utiliza un PCE SR para calcular la ruta. La palabra clave pcep
debajo de dynamic indica que el Nodo5 utiliza un SR PCE para calcular la ruta. El objetivo de optimización es
minimizar la métrica IGP. Como restricción, la ruta es miembro del grupo disjoint con identificador 1 y las
rutas en este grupo deben ser disjoint de nodos (tipo disjoint node).

Ejemplo 4-10: Configuración de la ruta disjunta de la política SR en el Nodo5

segment-routing
traffic-eng
POLÍTICA1
color 20 punto final [Link]
rutas-candidato
preferencia 100
dinámica
métrica
pcep
tipo igp
restriccione
s
grupo-asociación
tipo nodo disjunto identificador 1
¡!
pcc
dirección pce ipv4 [Link]
 Figura 4-6: Primer camino del grupo disjunto

Tras configurar la Política SR en el Nodo5, éste envía una Solicitud de Cálculo de Trayecto (PCReq) al SR PCE
[Link] (ver ➊ en la Figura 4-6). En esa PCReq, Nodo5 proporciona toda la información necesaria para que el
SR PCE pueda calcular el trayecto: la cabecera y el punto final, el objetivo de optimización y las restricciones.
En este ejemplo, el Nodo5 solicita al SR PCE que calcule un camino desde el Nodo5 al Nodo8, optimizando la
métrica IGP, con la restricción de que debe ser nodo-disociable de otros caminos con un group-id 1 disjoint.

Como el SR PCE no conoce ningún otro camino existente con group-id 1 disjoint, calcula el camino
optimizado con métrica IGP sin restricciones hacia el Nodo8. Esto se indica como ➋ en la Figura 4-6. El SR
PCE envía el resultado del cálculo al Nodo5 en un mensaje de Respuesta de Cálculo de Ruta (PCRep).
(marcado➌). Si el cálculo de la ruta se ha realizado correctamente, el PCRep contiene la lista SID de la solución.
En
el ejemplo, la lista de SID resultante es <16008>, que sólo contiene el Prefijo-SID del Nodo8.

El Nodo5 instancia el camino para la Política SR al Nodo8 (ver ➍ en la Figura 4-6). El Nodo5 comunica la
información de este trayecto al PCE, utilizando un mensaje de Informe de Cálculo de Trayecto (PCRpt)
(marcado con➎). En este PCRpt, el Nodo5 proporciona todos los detalles sobre el estado del trayecto al SR
PCE.

Figura 4-7: Segunda ruta del grupo disjunto

Algún tiempo después, el operador configura la Política SR al Nodo4 en la cabecera Nodo1, como se muestra
en el Ejemplo 4-11. Esta configuración es casi una copia idéntica de la configuración en Nodo5 en el Ejemplo
4-10, pero elegimos usar un nombre diferente aunque esto no es requerido.
Ejemplo 4-11: Configuración de la ruta disjunta de la Política SR en Nodo1

segment-routing
traffic-eng
POLÍTICA2
color 20 punto final [Link]
rutas-candidato
preferencia 100
dinámica
métrica
pcep
tipo igp
restriccione
s
grupo-asociación
tipo nodo disjunto identificador 1
¡!
pcc
dirección pce ipv4 [Link]

Después de configurar la Política SR en Nodo1, Nodo1 envía un PCReq al PCE SR (ver ➊ en

Figura 4-7). Nodo1 indica en este PCReq que necesita una ruta a Nodo4, con métrica IGP optimizada
y nodo-disojo de otros caminos con un grupo-id 1 disjunto. El PCE SR encuentra otro camino con grupo-id 1
disjunto en su DB SR-TE: el camino del Nodo5 al Nodo8 que fue instanciado antes. El
SR PCE calcula la pat h(1) (marcada ➋ en la Figura 4-7) , disjunta de la existente, y encuentra que
la ruta del Nodo1 al Nodo4 es 1→2→3→4, con la lista SID <16002, 24023, 16004>. Envía un PCRep al Nodo1
(➌), que instanciará la ruta (➍) y enviará un PCRpt al PCE SR con la etiqueta
estado de la ruta (➎).

[Link] Delegación de ruta

La secuencia descrita en la sección anterior funciona bien cuando se configura primero la Política SR en Nodo5
y luego la Política SR en Nodo1. Para describir otro importante mecanismo SR PCE, la delegación de ruta,
supongamos que primero se configura la Política SR en Nodo1. La figura 4-8 ilustra esto.

Después de configurar la Política SR en el Nodo1, el Nodo1 envía una Solicitud de Cálculo de Ruta (PCReq) al
PCE SR, ver ➊ en la Figura 4-8.
 Figura 4-8: SR PCE calcula caminos disjuntos - paso 1

Como el SR PCE no conoce ningún otro camino existente con group-id 1 disjoint, calcula el camino
optimizado sin restricciones de métrica IGP al Nodo4. Esto se indica con ➋ en la Figura 4-8. La lista de SID
resultante es . La lista SID resultante es <16004>, conteniendo sólo el Prefijo-SID del Nodo4. El SR PCE
envía el resultado al Nodo1 en un mensaje Path Computation Reply (PCRep), marcado con➌. El Nodo1
instancia la ruta para la Política SR al Nodo4, ver ➍ en la Figura 4-8. Nodo1 comunica la información de este
trayecto a PCE, utilizando un mensaje de Informe de Cálculo de Trayecto (PCRpt), marcado ➎.

Si ahora el Nodo5 solicita una ruta al Nodo8 que sea nodo-disociada de la ruta entre el Nodo1 y el Nodo4, no
existe tal ruta ya que todas las rutas tendrían que atravesar el Nodo6 y el Nodo7, violando el requisito de
diversidad. La única solución es cambiar el camino entre Nodo1 y Nodo4 a 1→2→3→4.
Para que esto posible, el Nodo1 ha delegado el control de la ruta calculada por el SR PCE al SR PCE. Cuando
un PCC delega el control del trayecto en el SR PCE, éste puede indicar de forma autónoma al PCC que debe
actualizar el . De este modo, el SR PCE puede mantener la intención del trayecto, por ejemplo tras un cambio
de topología o después de añadir o cambiar un trayecto de un par de trayectos disjuntos.

Para delegar una ruta al SR PCE, el PCC establece el indicador de delegación en el mensaje PCRpt para esa
ruta. Un PCC IOS XR siempre delega automáticamente el control al SR PCE cuando ha calculado la ruta.

El siguiente paso en el ejemplo es la configuración de la Política SR al Nodo8 en el Nodo5 de cabecera.

Después de configurar esta Política SR en el Nodo5, el Nodo5 envía un PCReq al PCE SR (ver ➊ en la Figura
4-9).
Nodo5 indica en este PCReq que necesita una ruta a Nodo8, con métrica IGP optimizada y nodo-.
disjuntos de otros caminos con un grupo-id 1 disjunto. SR PCE encuentra otro camino con grupo-id 1 disjunto
en su DB SR-TE: el camino desde Nodo1 a Nodo4 que fue instanciado anteriormente. En lugar de
simplemente calcular el camino, disjunto del camino existente, el SR PCE calcula concurrentemente ambos
caminos disjuntos, ya que esto produce los caminos disjuntos óptimos. Esto está marcado ➋ en la Figura 4-9.
Como resultado de este cálculo, el SR PCE encuentra que el camino desde el Nodo1 al Nodo4 debe ser
actualizado a un nuevo camino 1→2→3→4, de lo contrario no es posible un camino disjunto desde el Nodo5
al Nodo8.

Dado que el Nodo1 ha delegado el control de la ruta al SR PCE, el SR PCE puede actualizar autónomamente
esta ruta cuando sea necesario. El SR PCE actualiza la ruta enviando una Actualización de Cálculo de Ruta
(PCUpd) al Nodo1 (marcado ➌ en la Figura 4-9) con la nueva lista de SID <16002, 24023, 16004>. 16002 es
el Prefijo-SID del Nodo2, 24023 es el Adj-SID del enlace del Nodo2 al Nodo3, y 16004 es el Prefijo-SID del
Nodo4.
 Figura 4-9: SR PCE calcula caminos disjuntos - paso 2

El Nodo1 actualiza la ruta (indicada con ➍ en la Figura 4-9) y el Nodo1 informa de la nueva ruta al SR PCE
utilizando un PCRpt (marcado con ➎).

El SR PCE también había calculado la ruta desde el Nodo5 al Nodo8 (5→6→7→8), con la lista de SID de
solución <16008>, donde 16008 es el Prefijo-SID del Nodo8. SR PCE responde a Nodo5 con esta lista de SID
de solución <16008> en el mensaje PCRep. Esto es ➏ en la Figura 4-10. El Nodo5 instancia el camino
(indicado con➐) y envía un PCRpt con la información del camino al SR PCE (marcado con ➑). Con este
PCRpt, el Nodo5 también delega el control de esta ruta al SR PCE de tal forma que el SR PCE puede ordenar
de forma autónoma al Nodo5 que actualice la ruta si es necesario.

Figura 4-10: SR PCE calcula caminos disjuntos - paso 3

Cada vez que cambia la topología, SR PCE vuelve a calcular de forma autónoma las rutas y las actualiza si es
necesario para mantener rutas disjuntas.

Las dos cabeceras de los trayectos disjuntos deben utilizar el mismo SR PCE para calcular los trayectos y
garantizar la diversidad mutua. Sin embargo, cualquier par de cabeceras puede utilizar cualquier SR PCE
para el cálculo. Para ampliar el ejemplo que descrito anteriormente, podría introducirse en la otro SR PCE, o
par de SR PCE. Este SR PCE puede, por ejemplo, calcular caminos disjuntos desde el Nodo4 al Nodo1 y
desde el Nodo8 al Nodo5. Los SR PCEs que calculan caminos para diferentes grupos disjuntos no necesitan
sincronizarse entre . Estos cálculos son completamente independientes.
Los PCEs son típicamente desplegados en pares por razones de redundancia y la sincronización intra-par
(sesiones PCEP state- sync) puede ser aprovechada para alta disponibilidad. Véase el capítulo 13, "SR PCE"
para más detalles.

4.3.3 SR PCE calcula rutas entre dominios de extremo a extremo

En las secciones anteriores de este capítulo, los cálculos de rutas dinámicas, realizados por el nodo de cabecera
o por un PCE, se restringían a una única área IGP. En esta sección, vamos un paso más allá añadiendo múltiples
dominios a la mezcla.

La Figura 4-11 muestra una topología consistente en tres dominios. Los tres dominios están habilitados para SR
y, según la recomendación de diseño de SR, todos los nodos usan el mismo SRGB. Dominio1 y Dominio2 son
Sistemas Autónomos (ASs) diferentes, interconectados por dos enlaces eBGP peering, entre Nodo14 y Nodo24,
y entre Nodo15 y Nodo25. El Dominio2 y el Dominio3 están interconectados por dos nodos frontera: Nodo22 y
Nodo23. Si el Dominio2 y el Dominio3 son dominios IGP diferentes, estos frontera ejecutan dos instancias
IGP, una para cada dominio conectado. Si el Dominio2 y el Dominio3 son dos áreas en un único dominio IGP,
entonces el Nodo22 y el Nodo23 son Enrutadores de Frontera de Área (ABRs).

Mejoras significativas entre dominios

"En el periodo ~2005/2009trabajé con Martin Horneffer y Jim Uttaro para definir el "diseño Seamless MPLS". En esencia, utilizamos la
RFC3107 para proporcionar un LSP MPLS de mejor esfuerzo a través de múltiples dominios.

SR-TE mejora drásticamente esta solución, ya que permite eliminar RFC3107 (menos protocolo) y admite políticas interdominio
habilitadas para SLA (que el diseño Seamless MPLS no podía admitir).

Las políticas SR pueden utilizarse para crear una ruta de mejor esfuerzo entre dominios. Un operador podría aprovechar esto para eliminar
la RFC3107 y simplificar así su funcionamiento.

Además, las políticas SR proporcionan de forma nativa políticas SLA (bajo retardo, evitación de recursos, rutas disjuntas) en la ruta entre
dominios, mientras que Seamless MPLS basado en RFC3107 sólo proporciona best-effort. "

- Clarence Filsfils
 Figura 4-11: Topología de red multidominio

Una política SR puede proporcionar una interdominio de extremo a extremo sin fisuras. Para ilustrarlo,
empezaremos por examinar una política de SR con una ruta interdominio explícita, en lugar de pasar directamente
al cálculo dinámico de rutas para redes multidominio.

Para proporcionar una ruta inter-dominio de extremo a extremo desde el Nodo11 al Nodo31 en la red de la
Figura 4-11, el operador configura una Política SR con una lista SID explícita en el Nodo11. La lista SID es:
<16014, 51424, 16022, 16031>, donde 160XX es el Prefijo-SID del NodoXX. 51424 es el SID que dirige el
tráfico a través del enlace BGP peering entre Nodo14 y Nodo24: el Peering-SID. Este Peering-SID se describe
en el capítulo 14, "SR BGP Egress Peer Engineering". Por ahora, puede ver el Peering-SID como el equivalente
BGP del IGP Adj-SID: los paquetes recibidos con un Peering-SID como etiqueta superior son dirigidos hacia el
vecino BGP asociado.

La Figura 4-12 muestra la ruta de la Política SR. Esta ilustración también muestra un paquete con su pila de
etiquetas mientras viaja del Nodo11 al Nodo31 usando la lista SID anterior. El Prefijo-SID 16014 lleva el
paquete desde el Nodo11 al Nodo14 a través del camino más corto IGP ECMP-aware. El Peering-SID 51424
lleva el paquete desde el Nodo14 al Nodo24, atravesando el enlace peering. El Prefijo-SID 16022 lleva el del
Nodo24 al Nodo22 a través del camino más corto IGP, y finalmente, el Prefijo-SID 16031 lleva el paquete al
Nodo31 a través del camino más corto ECMP IGP.
 Figura 4-12: Ruta explícita interdominio de extremo a extremo

Así, una política SR puede proporcionar una ruta interdominio de extremo a extremo sin fisuras. Pero el
operador quiere una solución dinámica que ajuste las rutas SLA de extremo a extremo a la red cambiante.
Instanciar una política SR en el Nodo11 con una ruta dinámica calculada localmente por el nodo de cabecera
no funciona. En una red multidominio, un nodo de cabecera sólo puede ver la topología de su área local; no
puede ver la topología de la red más allá de los nodos fronterizos. El IGP inunda la información de topología
sólo en el área local. Por lo tanto, el nodo de cabecera no tiene suficiente información en su DB SR-TE para
calcular rutas interdominio.

Para resolver este problema, el nodo de cabecera puede utilizar un SR PCE para calcular la ruta. Este SR PCE
tendrá que conocer las topologías de todos los dominios.

[Link] Capacidad multidominio de SR PCE

La información sobre los enlaces peering BGP inter-AS se proporciona a través de la funcionalidad SR
BGP EPE. El conocimiento sobre todas las topologías de dominio y sobre los enlaces peering BGP inter-AS
es distribuido por BGP-LS.

BGP-LS

En secciones anteriores de este capítulo, hemos visto que un SR PCE puede obtener la información topológica
de su área IGP conectada. Para obtener la información topológica de dominios remotos, el servidor SR PCE
puede utilizar BGP y la familia de direcciones BGP link-state, comúnmente conocida como "BGP-LS". BGP-LS
transporta
una LS-DB IGP utilizando señalización BGP. Básicamente, BGP-LS puede empaquetar el contenido de
la LS-DB y transportarlo en BGP a una ubicación remota, típicamente un PCE. BGP-LS se beneficia
de toda la funcionalidad de propagación de rutas BGP, como el uso de Route-reflectors, como veremos
más adelante.

Desde su introducción, BGP-LS ha superado esta funcionalidad inicial y, gracias a diversas extensiones, se ha
convertido en el mecanismo preferido para enviar cualquier información a un controlador. BGP-LS se describe
con más detalle en el capítulo 17, "BGP-LS".

El servidor SR PCE aprende la información topológica de los diferentes dominios de la red a través de BGP-
LS. En el ejemplo de topología de la Figura 4-13, un nodo de cada dominio alimenta su LS-DB local a través
de una sesión BGP-LS a un único Route Reflector (RR) local. Esta configuración mínima es sólo para fines
ilustrativos; en la práctica, se proporcionaría redundancia.

El Ejemplo 4-12 muestra la configuración BGP-LS e IGP del Nodo21. La sesión BGP al vecino [Link], que es
el RR de Dominio2, tiene habilitada la familia de direcciones Link-state (BGP-LS). Nótese que tanto AFI como
SAFI se denominan "link-state", por lo tanto el doble link-state en la configuración de address-family.

Con la configuración distribute link-state bajo router isis, Nodo21 distribuye su LS-DB ISIS a
BGP. El instance-id 102 en este comando es un identificador de "universo de enrutamiento" que hace
posible diferenciar múltiples topologías, posiblemente superpuestas. Este identificador se lleva en todos los
anuncios de BGP-LS y para cada anuncio identifica la instancia IGP que alimentó la información a BGP-LS.
En este ejemplo, la información de topología de la instancia ISIS "SR" en Nodo21 se identifica por instance-
id 102. Toda la información que la instancia ISIS "SR" envía a lleva el identificador 102. Encontrará más
información en el capítulo 17, "BGP-LS".

Recuerda de las secciones 4.2.1 y 4.3.1 de este capítulo que este mismo comando también permite la
distribución de la IGP LS-DB al proceso SR-TE en el nodo de cabecera y SR PCE.
Ejemplo 4-12: Configuración de BGP-LS en Nodo21

router isis SR !! o "router ospf SR"

distribute link-state instance-id 102
¡!
router bgp 2
bgp router-id [Link]
address-family link-state link-state
¡!
¡¡neighbor [Link] !! Dominio2 RR
remote-as 2
update-source Loopback0
address-family link-state link-state

En la práctica, varios nodos tendrán una sesión BGP-LS con varios RR locales por redundancia. La familia de
direcciones link-state (BGP-LS) puede ser transportada en sesiones de BGP Interno (iBGP) y BGP Externo
(eBGP), y está sujeta a las reglas estándar de propagación de BGP.

En el ejemplo, una malla completa de sesiones BGP-LS interconecta los RRs de dominio, pero son posibles
otras opciones de diseño, como RRs jerárquicos. Finalmente, cada RR de la red tiene la información LS-DB de
todos los dominios IGP en su base de datos BGP-LS.

Figura 4-13: Distribución multidominio de la información LS-DB en BGP-LS

BGP Peering-SIDs
En este punto, aún no hemos discutido cómo BGP-LS obtiene la información sobre los enlaces peering BGP
entre el Dominio1 y el Dominio2. Estos enlaces no están en la LS-DB IGP ya que no hay adyacencia IGP
formada a través de ellos. Anteriormente en esta sección, al hablar de la ruta explícita entre dominios, hemos
introducido el BGP Peering-SID. Este Peering-SID cumple una función para los peers BGP que es similar a la
función que tiene un Adj-SID para las adyacencias IGP. Cuando se aplican al caso de uso interdominio, los
Peering-SID de BGP proporcionan la funcionalidad de cruzar la frontera entre dos AS y codificar una ruta que
abarca diferentes dominios.

Los BGP Peering-SIDs son SIDs que se asignan a un peer BGP o a enlaces peering BGP cuando se activa la
funcionalidad Egress Peer Engineering (EPE). El Capítulo 14, "SR BGP Egress Peer Engineering" está
dedicado a EPE.

Los EPE Peering SIDs son anunciados en BGP-LS por cada nodo peering habilitado para EPE. Para ello, los
nodos frontera habilitados para EPE Nodo14, Nodo15, Nodo24 y Nodo25 tienen una sesión BGP-LS con su RR
local, como se muestra en la Figura 4-14. Las sesiones BGP-LS entre RRs también distribuyen la información
EPE. Las sesiones BGP-LS entre los RRs también distribuyen la información EPE.

Figura 4-14: Distribución multidominio de la información EPE en BGP-LS

Tenga en cuenta que la información distribuida por BGP-LS no es una instantánea periódica de la
topología; es una alimentación reactiva en tiempo real. Se actualiza a medida que se dispone de nueva
información.

SR PCE aprende información multidominio

Ahora que hemos aprendido cómo toda la información necesaria para calcular rutas entre dominios está
disponible en BGP-LS, podemos introducir esta información en la DB SR-TE del SR PCE. Por lo tanto, el
servidor SR PCE se conecta a través de BGP-LS a su RR local para recibir información consolidada sobre toda
la red.

El modelo de despliegue del servidor SR PCE es similar al modelo de despliegue de BGP RR. Múltiples
servidores SR PCE en la red pueden realizar la funcionalidad de cálculo de ruta entre dominios, siempre que
se conecten a la fuente de información BGP-LS. Como se pueden desplegar múltiples servidores SR PCE en
la red, el operador puede especificar qué cabecera utiliza qué servidor SR PCE, basándose en la proximidad
geográfica o el tipo de servicio, por ejemplo. Esto permite una escalabilidad horizontal, añadiendo más SR
PCE cuando la escala lo requiera y dividiendo el trabajo entre ellos.

SR PCE escala como BGP RR

"Una ventaja clave de solución SR es que sus PCE SR se escalan como los reflectores de rutas BGP.

puede desplegar un par de SR PCE en cada PdP o región y dedicarse a dar servicio a las cabeceras de ese PdP/región. A medida que
aumenta su carga, pueden añadirse más pares.

No es necesario sincronizar todos los PCE SR de un dominio SR.

Sólo es necesario sincronizar dentro de un par. Esto puede hacerse de forma indirecta (mediante comunicaciones BGP-LS/PCEP con
las cabeceras que reflejan la misma información a los dos PCE SR de su par) o de forma directa (sincronización PCEP entre los dos
PCE SR) "

- Clarence Filsfils

En el ejemplo de la Figura 4-15, se han agregado dos servidores SR PCE a la red, uno en el Dominio1 y otro
en el Dominio3. Ambos se conectan a su RR local para aprovechar la alimentación reactiva BGP-LS en
tiempo real para obtener información topológica actualizada. El Nodo de Cabecera11 utiliza el SR PCE en el
Dominio1 para calcular rutas interdominio, mientras que el Nodo31 puede utilizar el SR PCE en el Dominio3
para calcular estas rutas.
Nótese que los nodos de cabecera sólo necesitan utilizar un SR PCE para calcular rutas si no disponen de la
información necesaria en su propia DB SR-TE. Por ejemplo, el Nodo11 puede calcular por sí mismo un
camino optimizado en retardo hacia el Nodo14, que se encuentra en su propio dominio. El Nodo11 no
necesita involucrar al SR PCE, ya que toda la información necesaria se encuentra en su propia BD SR-TE.

Figura 4-15: Servidores PCE utilizando BGP-LS para recibir información topológica multidominio

Los servidores SR PCE del ejemplo son routers IOS XR con la funcionalidad de servidor SR PCE habilitada.
La configuración SR PCE y BGP-LS en el nodo SR PCE del Dominio1 en este ejemplo se muestra en el
Ejemplo 4-13. La funcionalidad de servicio SR PCE se habilita configurando la dirección IP local utilizada para
las sesiones PCEP, [Link] en este ejemplo. El SR PCE obtiene su información SR-TE DB de BGP-LS, por lo
tanto tiene una sesión BGP-LS al RR [Link] del Dominio1. El SR PCE puede combinar la información
recibida vía BGP-LS con la información de su instancia IGP local.
Ejemplo 4-13: Configuración del servidor PCE y BGP-LS en el nodo SR PCE del Dominio1

pce
dirección ipv4 [Link]
¡!
router bgp 1
bgp router-id [Link]
address-family link-state link-state
¡!
¡¡neighbor [Link] !! Dominio1 RR
remote-as 1
update-source Loopback0
address-family link-state link-state

[Link] SR PCE calcula la ruta entre dominios

Para proporcionar una ruta optimizada en retardo de extremo a extremo desde el Nodo11 al Nodo31, el
operador configura Política SR en el Nodo11. El operador especifica que el PCE SR en el Dominio1 calcula
esta ruta dinámica de la Política SR.

El Ejemplo 4-14 muestra la configuración de la Política SR en el Nodo11. La Política SR al endpoint [Link] -

la dirección loopback del Nodo31 - tiene una ruta dinámica calculada por el servidor SR PCE. El SR PCE debe
optimizar el retardo de la ruta (métrica tipo retardo). El Nodo11 se conecta al servidor SR PCE con la
dirección [Link] para calcular la ruta, tal y como se ha configurado en la sección pcc del Nodo11.

Ejemplo 4-14: Política SR con ruta interdominio optimizada en retardo en Nodo11

segment-routing
traffic-eng
POLÍTICA1
color 20 punto final [Link]
rutas-candidato
preferencia 100
dinámica
métrica
pcep
tipo de retraso
¡!
pcc
dirección pce ipv4 [Link]

Todos los nodos de la red han habilitado la medición del retardo de enlace y distribuyen las métricas de retardo
de enlace en IGP. Cómo funciona esto y cómo utilizarlo se explica en el capítulo 15, "Monitorización del
Rendimiento - Retardo de Enlace". Junto con el resto de información de topología, las métricas de retardo de
enlace se distribuyen en BGP- LS. Para simplificar la ilustración, la métrica de retardo de enlace por defecto en
la ilustración es 10.

El intercambio de protocolo PCEP que se produce después de configurar la política SR, como se ilustra en la
Figura 4-16, es equivalente a la secuencia que hemos visto antes en el ejemplo de rutas disjuntas de un solo
dominio
(sección 4.3.2).

Figura 4-16: Secuencia PCEP de ruta entre dominios

Después de configurar la Política SR en el Nodo11, el Nodo11 envía una Petición PCEP a su PCE SR,
solicitando un camino optimizado en retardo al punto final Nodo31 (marcado ➊ en la Figura 4-16). El SR PCE
utiliza la información multi-dominio en su DB SR-TE para calcular el camino optimizado en retardo de
extremo a extremo (indicado con
➋).

El SR PCE devuelve la lista de SID de solución <16015, 51525, 24523, 16031> al Nodo11 (➌ en la ilustración).

El Nodo11 instancia esta ruta (marcada➍). Este camino sigue el camino más corto IGP al Nodo15 usando el
Prefijo-SID 16015 del Nodo15. Luego atraviesa el enlace peering BGP usando el Peering-SID 51525. Para
atravesar el enlace de bajo retardo y alta métrica IGP entre el Nodo25 y el Nodo23, se utiliza el Adj-SID del
Nodo25 para este enlace: etiqueta 24523. Finalmente, la ruta sigue el camino más corto IGP hasta el Nodo31,
utilizando el Prefijo-SID 16031 del Nodo31.

El Nodo11 informa del estado trayecto al SR PCE en un mensaje de Informe PCEP (marcado➎). En este
Informe, el Nodo11 también delega el control de este trayecto al SR PCE. El SR PCE puede solicitar de forma
autónoma al Nodo11 que actualice el trayecto en caso necesario.
[Link] SR PCE Actualiza la ruta entre dominios
Para ilustrar la reactividad de la ruta computada SR PCE, supongamos que se produjo un fallo en la red. El
enlace entre el Nodo25 y el Nodo23 se cayó (indicado con ➊ en la Figura 4-17). Como primera reacción al
fallo, Nodo25 activa la ruta de backup TI-LFA para el Adj-SID 24523 del enlace fallido (➋). Esto restaura
rápidamente la conectividad del tráfico transportado en la política SR.

Figura 4-17: Stateful PCE actualiza la ruta entre dominios tras un fallo

El IGP inunda el cambio de topología y Nodo21 lo anuncia en BGP-LS (marcado ➌). BGP propaga la
actualización de topología al SR PCE (➍ en la ilustración). El SR PCE vuelve a calcular la ruta (➎) y envía un
mensaje de actualización PCEP al Nodo de cabecera11 (marcado con ➏). El Nodo11 actualiza el trayecto (➐) y
envía un mensaje de Informe PCEP al SR PCE con el estado del trayecto (indicado con➑).

La secuencia de eventos en este ejemplo es desencadenada por eventos, cada evento desencadena el siguiente
evento. Sin embargo, no es instantánea y está sujeta a retrasos, como los retrasos en BGP para propagar el
cambio de topología al SR PCE.
4.4 Resumen
Este capítulo explica cómo se calculan dinámicamente las rutas de ingeniería de tráfico.

Calcular una ruta TE es resolver un problema de optimización que tiene un objetivo de optimización y
restricciones.

La información necesaria para calcular los trayectos SR-TE se almacena en la base de datos SR-TE.

Se han desarrollado algoritmos optimizados por SR para calcular rutas y codificarlas en listas SID minimizando
el número de SID y maximizando ECMP.

En muchos casos, el propio nodo de cabecera puede calcular rutas SLA en una única área IGP. El bajo retardo y
las exclusiones de recursos son ejemplos típicos. Toda la información necesaria para estos cálculos está
disponible en la base de datos SR-TE de la cabecera.

Cuando la cabecera no dispone de la información necesaria en su DB SR-TE, el nodo de cabecera utiliza un

SR PCE para calcular los trayectos. Un ejemplo frecuente es el cálculo de trayectos disjuntos desde distintos
nodos de cabecera. Las dos cabeceras delegan el cálculo de su política de SR en el mismo SR PCE para
garantizar la diversidad mutua de caminos.

El PCE SR es responsable de mantener óptimas las rutas SR delegadas. Vuelve a calcular los trayectos
delegados en caso de cambios topológicos e indica a las cabeceras que actualicen los trayectos si es necesario.

Otro caso que requiere un SR PCE para calcular rutas es el caso multidominio. Un nodo de cabecera no puede
calcular rutas óptimas de extremo a extremo en una red multidominio, ya que el IGP sólo proporciona
información topológica sobre el área local, no sobre las áreas y dominios remotos. Un SR PCE aprende la
información topológica sobre todos los dominios de una red utilizando BGP-LS y almacena esta información
en su SR-TE DB. La base de datos SR-TE nativamente multidominio. BGP-LS no sólo transporta
información de topología IGP en BGP, sino también otra información, como la información EPE. BGP-LS
proporciona una alimentación reactiva en tiempo real para esta información que el PCE puede . El PCE SR
utiliza la DB SR-TE multidominio para calcular rutas interdominio óptimas de extremo a extremo para los
nodos de cabecera.

La funcionalidad SR PCE no se concentra en un único servidor centralizado. Los servidores SR PCE pueden
estar distribuidos por toda la red (analogía típica es la distribución de reflectores de ruta BGP).
Los servidores SR PCE no necesitan sincronizarse sí. Sólo necesitan obtener la información necesaria (por
ejemplo, topología) a través de su alimentación BGP-LS, y de los informes PCEP de sus PCC conectados.
4.5 Referencias
[SIGCOMM2015] "A Declarative and Expressive Approach to Control Forwarding Paths in Carrier-
Grade Networks.", Renaud Hartert, Stefano Vissicchio, Pierre Schaus, Olivier Bonaventure, Clarence
Filsfils, Thomas Telkamp, Pierre François, SIGCOMM 2015, octubre de 2015,
<[Link]

[RFC2702] "Requirements for Traffic Engineering Over MPLS", Michael D. O'Dell, Joseph Malcolm, Jim
McManus, Daniel O. Awduche, Johnson Agogbua, RFC2702, septiembre de 1999.

[RFC3107] "Carrying Label Information in BGP-4", Eric C. Rosen, Yakov Rekhter, RFC3107, mayo de
2001.

[RFC3630] "Traffic Engineering (TE) Extensions to OSPF Version 2", Derek M. Yeung, Dave Katz,
Kireeti Kompella, RFC3630, octubre de 2003.

[RFC5305] "IS-IS Extensions for Traffic Engineering", Tony Li, Henk Smit, RFC5305, octubre de 2008.

[RFC5440] "Path Computation Element (PCE) Communication Protocol (PCEP)", JP Vasseur, Jean-
Louis Le Roux, RFC5440, marzo de 2009.

[RFC7752] "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP",
Hannes Gredler, Jan Medved, Stefano Previdi, Adrian Farrel, Saikat Ray, RFC7752, marzo de 2016.

[RFC8231] "Extensiones del protocolo de comunicación de elementos de cálculo de ruta (PCEP) para PCE con
estado", Edward Crabbe, Ina Minei, Jan Medved, Robert Varga, RFC8231, septiembre de 2017.

[draft-ietf-idr-bgp-ls-segment-routing-ext] "BGP Link-State extensions for Segment Routing", Stefano

Previdi, Ketan Talaulikar, Clarence Filsfils, Hannes Gredler, Mach Chen, draft-ietf-idr- bgp-ls-segment-
routing-ext-12 (Trabajo en curso), marzo de 2019.

1. En lugar de calcular simplemente el camino, disjunto existente, el SR PCE calcula concurrentemente ambos
caminos disjuntos, ya que esto tiene la mayor probabilidad de encontrar una solución y produce el
solución óptima. Véase la sección siguiente para más detalles.↩
5 Dirección automática
Lo que aprenderemos en este capítulo:

Un Provider Edge (PE) que anuncia una ruta de servicio (BGP, Pseudowire (PW) o Protocolo de
Separación Localizador/ID (LISP)) puede etiquetarla con un color, que indica una intención específica
(por ejemplo, color 30 = "bajo retardo", color 20 = "sólo a través del plano de red azul").

En BGP, el color está soportado por el conocido atributo de comunidad extendida color. La misma extensión
se ha definido para LISP.

La dirección automatizada (AS) por destino dirige automáticamente una ruta de servicio a una política SR
válida en función de su siguiente salto y color.

Si no existe tal política SR válida, la ruta de servicio se instala en su lugar "clásicamente" en el plano de
reenvío con una recursión en la ruta al siguiente salto, es decir, el Prefijo-SID al siguiente salto.

AS está activado por defecto pero puede desactivarse por protocolo (por ejemplo, BGP) y por AFI/SAFI.

Una variante por flujo de AS se detallará en una futura revisión de este libro. La dirección por flujo permite
dirigir los flujos de tráfico teniendo en cuenta varios campos de la cabecera del paquete, como la dirección
de origen o el DSCP.

En los capítulos anteriores hemos explorado la política SR, sus rutas y las listas SID. Hemos visto cómo estas
rutas pueden ser calculadas e instanciadas en un nodo de cabecera. Pero, ¿cómo podemos hacer uso de estas
Políticas SR? ¿Cómo dirigir el tráfico hacia ellas?

En este capítulo describimos en primer lugar cómo un operador puede indicar los requisitos de servicio de una
ruta etiquetándola con un color, una comunidad de color BGP para rutas BGP. Este color es un identificador de
una . El nodo de entrada puede entonces utilizar el color de la y el nexthop para dirigirla automáticamente a la
política SR correspondiente. Esto se denomina Automated Steering (AS). A continuación, explicamos cómo el
AS granular por destino se aplica a varios tipos de rutas de servicio BGP. Por último, mostramos cómo puede
desactivar AS si es necesario.
5.1 Introducción
La funcionalidad Automated Steering (AS) dirige automáticamente las rutas de servicio hacia la política SR que
proporciona la intención o SLA1 deseados.

AS es un componente clave de la solución SR-TE, ya que automatiza la dirección del tráfico de servicio en las
políticas SR que ofrecen el SLA requerido.

AS puede funcionar por flujo2. En este , múltiples flujos hacia el mismo destino de servicio (por ejemplo, la ruta
BGP [Link]/8) pueden ser dirigidos automáticamente hacia diferentes Políticas SR. Aunque puede utilizar
cualquier técnica de clasificación por flujo, las más utilizadas es la clasificación DSCP/EXP. Por ejemplo, el
tráfico a [Link]/8 con DSCP 1 iría a la Política SR 1 mientras que el tráfico a [Link]/8 con DSCP 2 iría a la
Política SR 2.

En esta revisión del libro, nos centraremos en la solución de AS por destino. Por ejemplo, dos destinos BGP
[Link]/8 y [Link]/8 con el mismo siguiente salto [Link] pueden ser dirigidos automáticamente en dos Políticas
SR diferentes a [Link].

Aunque el concepto se aplica a cualquier tipo de ruta de servicio, utilizaremos BGP como ilustración.
 Omnes viae Romam ducunt (todos los caminos conducen a Roma)

☺
"El diseño ODN/AS surgió en un taxi en Roma .◻

Nos dirigíamos a una excelente trattoria en Trastevere. Estábamos atrapados en el tráfico de orilla derecha del río Tevere, en
algún lugar entre Castel San Angelo y piazza Trilussa. Mis queridos amigos Alexander Preusche y Alberto Donzelli me estaban la
bronca sobre la necesidad de una solución "SDN" que fuera "fácil de manejar".

Sabía que SR se adaptaba perfectamente a una solución centralizada (por ejemplo, véase la charla de Paul Mattes [SR-for-DCI]).

Sin embargo, me resistí a adoptar esta solución única, ya que pensé que requería un nivel de inversión operativa que muchos
proveedores de servicios querrían evitar.

Quería una solución que lo hiciera:

mucho más automatizada.

no depender de un único servidor poderoso.

integrarse con la distribución de rutas BGP/VPN, ya que es el corazón de los servicios SP/empresa.

El atasco fue una bendición, al igual que la presión amistosa de Alex y Alberto. Finalmente, la idea surgió y me muy sencilla: cuando
recibe las rutas VPN de un CPE conectado, el PE de salida marca las rutas recibidas con un color que codifica el SLA requerido por el
cliente relacionado; el reflejador de rutas refleja este atributo de color de forma transparente; el PE de entrada solicita automáticamente
al proceso SR-TE local que instancie una política SR utilizando una plantilla al color (esto se convertiría en ODN); una vez
instanciada, el proceso SR-TE devuelve la llamada a BGP y proporciona el BSID de la política instanciada; BGP instala
automáticamente la ruta de servicio coloreada en el BSID (esto se convertiría en AS).

La idea se aplica naturalmente al multidominio, ya que la plantilla ODN podría solicitar la delegación SR PCE para objetivos SLA que
excedan la información disponible en el PE de entrada.

Después de una muy buena comida con Alberto y Alex, llamé a Siva y le expliqué la idea. Como de costumbre, con su energía
desbordante, dijo "hagámoslo" y unas semanas después teníamos la primera prueba de concepto.

Bertrand comprendió de inmediato el enorme atractivo comercial de la solución y contribuyó de forma decisiva a incluirla en la hoja de
ruta del producto.

Gracias a Siva, Bertrand, Alberto y Alex... y a Roma ☺◻".

- Clarence Filsfils

A lo largo de este capítulo utilizaremos la red de la Figura 5-1 para ilustrar los distintos conceptos.

Esta red consiste en una única área IGP. La métrica de enlace IGP por defecto es 10, los enlaces entre Nodo3
y Nodo4 y entre Nodo5 y Nodo8 tienen una métrica de enlace IGP mayor 100, como se indica en
el dibujo. Se asigna un color de afinidad rojo al enlace entre el Nodo6 y el Nodo7.

Figura 5-1: Topología de referencia de la dirección automatizada

El operador de la red de la Figura 5-1 ha activado la medición del retardo en todos los enlaces de la red (véase
el capítulo 15, "Monitorización del rendimiento - Retardo de enlace"). Para simplificar, suponemos que los
retardos de enlace medidos de todos los enlaces son iguales: 10 milisegundos.

El operador de la red proporciona varios servicios que se describirán en el resto de este capítulo. La Figura 5-1
ilustra un servicio VPN para un cliente NewCo, utilizando los CEs Nodo13 y Nodo43, conectados a los PEs
Nodo1 y Nodo4 respectivamente. La ilustración también muestra un servicio de Internet representado con una
nube conectada al PE Nodo4.

CE Nodo43, que está configurado en VRF NewCo en Nodo4, anuncia los prefijos [Link]/24 y [Link]/24 vía
BGP a Nodo4. PE Nodo4 también se entera de un prefijo global [Link]/24 y propaga estos prefijos vía BGP
a Nodo1 y se establece a sí mismo (router-id [Link]) como el nexthop BGP.

El Nodo PE1 recibe estas rutas del Nodo4 y propaga las rutas en VRF NewCo al Nodo CE13. El Nodo1
conmuta el tráfico a estas rutas (VPN y global) a través del camino más corto IGP al Nodo4
(1→7→6→5→4).
Nos basaremos en esta topología para explicar cómo proporcionar el SLA adecuado para los distintos destinos
del servicio.
5.2 Colorear una ruta BGP
En el corazón de la solución AS se encuentra el concepto de etiquetado: cuando el Provider Edge (PE) de
salida anuncia una ruta BGP (servicio), el PE de salida colorea la ruta.

El color se elige para indicar el SLA requerido por la ruta BGP.

No existe una asignación fija de color a la semántica de SLA. Cualquier operador es libre de diseñar la
asignación. Por ejemplo, en este capítulo utilizaremos el color 30 para representar un de bajo retardo.

5.2.1 Comunidad ampliada de color BGP

La solución SR-TE aprovecha la Comunidad Extendida de Color BGP.

Comunidades BGP

Las comunidades BGP (RFC 1997) son etiquetas adicionales que pueden añadir a las rutas para proporcionar información adicional para
procesar esa ruta de una manera específica. Las comunidades BGP de una ruta se agrupan en un atributo de comunidades BGP adjunto a esa
ruta. Las comunidades BGP se utilizan normalmente para influir en las decisiones de enrutamiento. Las comunidades BGP pueden añadirse,
modificarse o eliminarse selectivamente a medida que la ruta viaja de un enrutador a otro.

Una comunidad BGP es un número de 32 bits, normalmente formado por el número de AS de 16 bits del originador seguido de un número de 16
bits con un significado definido por el operador.

La RFC 4360 introdujo un formato mayor (48 bits) de comunidad, la comunidad extendida. Tiene un campo de tipo para indicar el tipo y dictar
la estructura de los bytes restantes de la comunidad. Ejemplos de tipos de comunidad extendida son la comunidad Route-Target (RT) para rutas
VPN y comunidad Route Origin, ambas especificadas en RFC 4360.

La Comunidad Extendida Opaca es otro tipo de comunidad extendida definida en el RFC 4360. En realidad es una clase de comunidades extendidas.
La comunidad extendida Color, especificada en RFC 5512, es un subtipo de esta clase.

Las comunidades extendidas BGP de una ruta se agrupan en un atributo de comunidades extendidas BGP adjunto a esa ruta.

RFC 5512 especifica el formato de la Comunidad Extendida de Color que se muestra en la Figura 5-2.

Los dos primeros octetos indican el tipo de comunidad extendida. El primer octeto indica que es una comunidad
extendida opaca transitiva. "Transitiva" significa que un nodo BGP debe pasarla a sus vecinos, aunque no
reconozca el atributo. El segundo octeto indica el tipo de comunidad extendida opaca, el tipo 11 (o 0x0b) es
Color.
 Figura 5-2: Formato de Comunidad Ampliada en Color

El valor de color es un número plano de 32 bits. El valor es definido por el usuario y es opaco a BGP. Para

ser completos, notamos que draft-ietf-idr-segment-routing-te-policy especifica que cuando el Valor de Color
Comunidad Extendida se utiliza para dirigir el tráfico hacia una política SR, dos bits del campo Reservado se
utilizan para llevar los bits de Sólo Color (bits CO), como se muestra en la Figura 5-3.

Figura 5-3: Banderas CO de la Comunidad ampliada en color

El uso de estos bits CO para otros ajustes distintos del valor por defecto "00" no es muy común. Los casos de
uso se explican en el capítulo 10, "Más detalles sobre la dirección automática".

5.2.2 Colorear rutas BGP en el PE de salida

Automated Steering utiliza la comunidad extendida de color para etiquetar las rutas de servicio con un color.
Este color de comunidad extendida se hace coincidir con el color de una política SR. La funcionalidad y la
configuración que se utiliza para colorear las rutas BGP - decir, adjuntar una comunidad de color extendida a
una ruta - no es específica de SR-TE, cubrimos este aspecto para completar.

Existen múltiples formas de adjuntar comunidades (extendidas) a las rutas BGP, todas ellas implican una
política de ruta, pero se aplican diferentes "puntos de adjunción". Una política de ruta es una construcción que
implementa un
política de enrutamiento. Esta política de enrutamiento ordena al enrutador que inspeccione las rutas, las filtre y
potencialmente modifique sus atributos.

Una política de rutas se escribe en Routing Policy Language (RPL), que se asemeja a un lenguaje de
programación simplificado.

En este capítulo ilustramos dos puntos de conexión de políticas de ruta diferentes, una política de ruta BGP de
entrada y una política de ruta BGP de salida. Otros puntos de conexión son posibles pero no se tratan en este
libro.

En la Figura 5-1, el Nodo4 recibe las rutas de servicio del Nodo CE43. Aplicando una política de ruta de
entrada en Nodo4 para la sesión BGP a Nodo43, las rutas recibidas y sus atributos pueden ser manipulados,
como añadir una comunidad extendida de color.

Nodo4 anuncia el prefijo global [Link]/24 a Nodo1. Aplicando una política de ruta de salida en Nodo4 para
la sesión BGP a Nodo1, las rutas transmitidas y sus atributos pueden ser manipulados, como añadir una
comunidad extendida de color.

Antes de ver las políticas de ruta en el Nodo 4, echemos un vistazo a las comunidades extendidas de color.
Las comunidades extendidas de color que el Nodo4 usa en sus políticas de ruta, están definidas en los
conjuntos extcommunity-set Azul, Verde y Púrpura, como se muestra en el Ejemplo 5-1.

Ejemplo 5-1: conjuntos de comunidades de color extendidas en Nodo4

extcommunity-set opaco Azul 20

end-set
¡!
extcommunity-set opaco Verde 30
end-set
¡!
extcommunity-set opaco Púrpura 40
end-set

Usando la configuración del Ejemplo 5-2, Nodo4 aplica la política de ruta VRF-COLOR como una política
de ruta de entrada bajo la familia de direcciones ipv4 unicast para el vecino de VRF NewCo [Link]
(Nodo43) (ver línea 39). Como se aplica bajo la sesión BGP VRF NewCo, sólo se aplica a las rutas de esa
VRF.
La política de ruta VRF-COLOR se define en las líneas 1 a 9. Esta política de ruta asigna la comunidad de color
extendido Azul a [Link]/24 y Verde a [Link]/24.

La política de ruta GLOBAL-COLOR, definida en las líneas 11 a 16, adjunta la comunidad extendida de color
Púrpura a [Link]/24. Esta política de ruta se aplica como una política de ruta de salida bajo la familia de
direcciones ipv4 unicast para el vecino global [Link] (Nodo1) (ver línea 27).

Ejemplo 5-2: Aplicación de políticas de ruta en Nodo4 para colorear rutas

1 política de ruta VRF-COLOR

2 si destino en ([Link]/24) entonces
3 set extcommunity color Azul
4 endif
5 si destino en ([Link]/24) entonces
6 set extcommunity color Verde
7 endif
8 pase
9 fin de la política
¡10 !
11 route-policy GLOBAL-COLOR
12 if destination in ([Link]/24) then
13 set extcommunity color Purple
14 endif
15 pase
16 fin de la política
¡17 !
18 router bgp 1
19 bgp router-id [Link]
20 address-family ipv4 unicast
21 address-family vpnv4 unicast
¡22 !
23 vecino [Link]
24 remoto-as 1
25 update-source Loopback0
26 address-family ipv4 unicast
27 route-policy GLOBAL-COLOR out
28 ¡!
29 address-family vpnv4 unicast
¡30 !
31 vrf NewCo
32 rd auto
33 address-family ipv4 unicast
34 ¡!
35 vecino [Link]
36 remoto-as 2
37 descripción a CE43
38 address-family ipv4 unicast
39 route-policy VRF-COLOR in

5.2.3 Conflicto con el uso de otros colores

La comunidad ampliada de color se definió hace muchos años y puede utilizarse simultáneamente con seguridad
para muchos fines distintos.
La regla de diseño para el operador es asignar gamas de colores en de la aplicación.

Por ejemplo, un operador puede haber asignado 10-99 para indicar los requisitos de SLA mientras que
decidió utilizar 1000-1999 para rastrear el PdP de origen de las rutas de Internet.

En cuanto se asigne un rango específico a efectos de SLA/SR-TE, el operador sólo utilizará estos colores
para las configuraciones de la política SR (color, punto final).

A la inversa, en este ejemplo, una Política SR nunca será configurada con un color 1000 y por lo tanto una
ruta de Internet proveniente del PoP 1000 nunca correrá el riesgo de ser direccionada automáticamente sobre
una Política SR de color 1000.

Se pueden adjuntar simultáneamente varias comunidades extendidas y regulares a una ruta determinada, por
ejemplo, una para indicar los requisitos de SLA y otra para rastrear el PoP de origen.
5.3 Dirección automática de un prefijo VPN
Otro cliente Acme utiliza el servicio L3VPN de la red mostrada en la Figura 5-4. El Nodo CE12 de este se
conecta al Nodo PE1 en VRF Acme y de forma similar el Nodo CE42 se conecta al Nodo PE4.

El cliente Acme necesita una ruta de bajo retardo de CE12 a CE42.

Para satisfacer este requisito, el operador configura en Nodo1 una Política SR con color "verde" (valor 30,
asociado a SLA de bajo retardo) y el prefijo de loopback [Link]/32 de Nodo4. El nombre de una Política SR es
definido por el usuario. Aquí hemos elegido el nombre "VERDE", que coincide con el nombre que utilizamos
para el color de esta Política SR, pero podríamos haberla llamado "retardo_al_nodo4" o cualquier otro nombre
con sentido. La política SR VERDE tiene una única ruta candidata con preferencia 100. Esta ruta candidata es
una ruta dinámica con una preferencia 100. Esta ruta candidata es una ruta dinámica con una métrica de retardo
optimizada y sin restricciones. La configuración de esta política SR se muestra en el Ejemplo 5-3.

Ejemplo 5-3: Configuración de la política SR GREEN en Nodo1

segment-routing
traffic-eng
política VERDE
color 30 end-point ipv4 [Link]
candidate-paths
preferencia 100
dinámica
tipo métrico
retraso

La ruta de la política SR VERDE se muestra en la Figura 5-4.

 Figura 5-4: Dirección automatizada de una ruta BGP verde

CE42 anuncia el prefijo [Link]/24 vía BGP al Nodo PE4. Esto se indica con ➊ en la Figura 5-4. Nodo4 asigna
una etiqueta VPN 92220 para el prefijo [Link]/24 en VRF Acme y anuncia este prefijo vía BGP a Nodo1 con
el nexthop BGP fijado a su dirección de loopback [Link].

Para indicar el requisito de bajo retardo para el tráfico destinado a este prefijo, el Nodo4 añade una
comunidad extendida con color "verde" a la actualización BGP para el prefijo [Link]/24 de VRF Acme (➋
en la Figura 5-4). Como se describió anteriormente, el color "verde" se refiere al valor de color 30 que fue
elegido para identificar el SLA de bajo retardo.

El Nodo1 recibe la ruta BGP e intenta hacer coincidir el color adjunto de la (30) y su nexthop ([Link]) con el
color y el endpoint de una SR Policy válida. BGP encuentra la política SR GREEN coincidente, con color 30 y
endpoint [Link], e instala automáticamente el prefijo [Link]/24 en la tabla de reenvío apuntando a política SR
GREEN (➌), en lugar de apuntar al nexthop BGP. Todo el tráfico destinado a la ruta VRF Acme [Link]/24 se
reenvía entonces a través de la política SR GREEN.

Al asignar directamente el color del prefijo BGP al color de la política SR, no se requieren configuraciones de
direccionamiento del tráfico complejas y operacionalmente intensivas. Al instalar el prefijo BGP en la tabla de
reenvío, apuntando a la Política SR, el direccionamiento del tráfico no tiene impacto en el rendimiento del
reenvío.
 Simplicidad de la dirección automática

"En nuestro primer despliegue de clientes SR en 2017tuvimos que utilizar el modo de interfaz de túnel SR-TE, ya que el modo SR
Policy no estaba disponible en ese momento (véase la sección "nueva CLI" en el capítulo 1, "Introducción"). En consecuencia, se
utilizaron técnicas heredadas como SPP (Service Path Preference) para dirigir el tráfico a los túneles correspondientes. Este cliente ha
tenido problemas con la granularidad y complejidad del direccionamiento del tráfico. Por eso, cuando introdujimos la capacidad de
autodirección del modo SR Policy, este cliente la aceptó de inmediato: granularidad por flujo, sólo tiene que preocuparse de los
"colores". Ahora el cliente está planeando migrar el modo de interfaz de túnel SR-TE existente al modo SR Policy para disfrutar de las
ventajas de la dirección automática. "

- YuanChao Su

Más detalles

Ahora exploraremos la funcionalidad de Automated Steering con más detalle examinando las rutas BGP y las
entradas de reenvío.

El Ejemplo 5-4 muestra la configuración BGP del Nodo4. Es una configuración VPNv4 base normal. Nodo4
tiene dos sesiones BGP, una sesión VPNv4 iBGP a Nodo1 ([Link]) y una sesión eBGP en VRF Acme a
CE42 ([Link]).

Se define un conjunto comunitario ampliado Verde para el valor de color 30 (líneas 14-17). Tenga en cuenta
que el nombre Verde es sólo un identificador definido por el usuario localmente significativo de este conjunto.

Para adjuntar el color 30 a los prefijos recibidos del CE Nodo42, el operador ha elegido usar una política de
ruta de entrada COLOR_GREEN para address-family ipv4 unicast de la sesión BGP a Nodo42 en VRF Acme.
Para simplificar el ejemplo, la política de ruta COLOR_GREEN adjunta incondicionalmente el conjunto de
comunidad extendida Green a todas las rutas entrantes en esa sesión BGP.
Ejemplo 5-4: Configuración de BGP en Nodo4

1 vrf Acme
2 address-family ipv4 unicast
3 importar ruta-objetivo
4 1:1
5 ¡!
6 export ruta-objetivo
7 1:1
¡8 !
9 interfaz GigabitEthernet0/0/0/1.100
10 vrf Acme
11 dirección ipv4 [Link] [Link]
12 encapsulation dot1q 100
¡13 !
14 extcommunity-set opaco Verde
15 # SLA de bajo retardo
16 30
17 finales
¡18 !
19 política de ruta COLOR_GREEN
20 set extcommunity color Verde
21 fin de la política
¡22 !
23 route-policy PASS
24 pase
25 fin de la política
¡26 !
27 router bgp 1
28 bgp router-id [Link]
29 address-family vpnv4 unicast
¡30 !
31 vecino [Link]
32 remoto-as 1
33 update-source Loopback0
34 address-family vpnv4 unicast
¡35 !
36 vrf Acme
37 rd auto
38 address-family ipv4 unicast
39 ¡!
40 vecino [Link]
41 remoto-as 2
42 descripción a CE42
43 address-family ipv4 unicast
44 route-policy COLOR_GREEN en

BGP en Nodo4 recibe la ruta [Link]/24 desde CE Nodo42. En el Ejemplo 5-5 se muestra esta ruta BGP. Note
que la ruta tiene una comunidad extendida de color adjunta Color:30, como resultado de la política de ruta
BGP de entrada COLOR_GREEN, como se describió anteriormente. La otra comunidad extendida de esa ruta
es una comunidad Route-Target (RT) con valor 1:1 que se utiliza para propósitos de L3VPN.
Ejemplo 5-5: Nodo4 recibe la ruta BGP [Link]/24 desde CE42

RP/0/0/CPU0:xrvr-4#show bgp vrf Acme [Link]/24

Entrada en la tabla de enrutamiento BGP para [Link]/24, Distintivo de ruta:
[Link]:0 Versiones:
Proceso bRIB/RIB SendTblVer
Altavoz 10 10
Etiqueta local: 92220
Última modificación: 5 jun 09:30:24.894 para 01:58:01
Caminos: (1 disponible, mejor #1)
Anunciado a los pares PE (en grupos de actualización
únicos): [Link]
Ruta #1: Recibido por el altavoz 0
Anunciado a los pares PE (en grupos de actualización
únicos): [Link]
2
[Link] de [Link] ([Link])
Origen IGP, métrica 0, localpref 100, valid, external, best, group-best, import-candidate ID de ruta
recibida 0, ID de ruta local 1, versión 10
Comunidad ampliada: Color:30 RT:1:1
Validez Origin-AS: (desactivada)

De acuerdo con la funcionalidad regular de L3VPN, Nodo4 asignó dinámicamente una etiqueta 92220 para
este prefijo VPN y lo anunció a Nodo1, con la comunidad extendida de color adjunta. Nodo4 ha establecido
su router-id [Link] como nexthop BGP para los prefijos VPN. En el Ejemplo 5-6 se muestra la ruta BGP
recibida por el Nodo1. La salida muestra que la ruta VRF Acme [Link]/24 tiene nexthop BGP [Link] y color
30.

Ejemplo 5-6: Nodo1 recibe la ruta VPN [Link]/24 de PE Nodo4

RP/0/0/CPU0:xrvr-1#show bgp vrf Acme [Link]/24

Entrada en la tabla de enrutamiento BGP para [Link]/24, Distintivo de ruta:
[Link]:0 Versiones:
Proceso bRIB/RIB SendTblVer
Altavoz 7 7
Última modificación: 5 Jun 09:31:12.880 para 02:04:00
Rutas: (1 disponible, la mejor #1)
No anunciada a ningún par Ruta
#1: Recibida por el altavoz 0 No
anunciada a ningún par
2
[Link] C:30 (bsid:40001) (métrica 40) de [Link] ([Link])
Etiqueta recibida 92220
Origen IGP, métrica 0, localpref 100, válido, interno, mejor, grupo-mejor, import-candidato, importado Received Path
ID 0, Local Path ID 1, versión 7
Comunidad ampliada: Color:30 RT:1:1
SR policy color 30, up, registered, bsid 40001, if-handle 0x00000410

Fuente AFI: VPNv4 Unicast, VRF de origen: por defecto, Distintivo de ruta de origen: [Link]:0

La política SR GREEN en Nodo1, con color 30 y endpoint [Link], coincide con el color 30 y nexthop BGP
[Link] de la ruta VRF Acme [Link]/24. Utilizando la funcionalidad Automated Steering, BGP
instala la ruta en la tabla de reenvío, apuntando a la política SR GREEN. BGP utiliza el BSID de política SR
como clave.

Dado que el operador no proporcionó ningún BSID explícito como parte de la configuración de la política
(Ejemplo 5-3), el nodo cabecera asigna uno dinámicamente; este es el comportamiento por defecto. Para
averiguar el BSID real de una Política SR, podemos mirar su . El ejemplo 5-7 muestra el estado de la política
SR GREEN. La salida muestra el Binding SID asignado dinámicamente para esta política SR: label 40001.
La lista SID de esta política SR es <16003, 24034>.

Ejemplo 5-7: Estado de la Política SR VERDE en Nodo1

RP/0/0/CPU0:xrvr-1#show segment-routing traffic-eng policy

Base de datos de la política SR-TE

Color: 30, Punto final: [Link]

Nombre: srte_c_30_ep_1.1.1.4
Estado:
Admin: activo Operativo: activo a las 07:45:16 (desde el 28 de mayo
09:48:34.563) Rutas de candidatos:
Preferencia: 100 (configuración) (activa) Nombre:
VERDE
BSID solicitado: dinámico
Dinámico (válido)
Tipo de métrica: retardo, Métrica de la ruta acumulada:
30 16003 [Prefijo-SID, [Link]]
24034 [Adjacency-SID, [Link] - [Link]]
Atributos:
Encuadernación SID: 40001
Clase de reenvío: 0
Dirección BGP desactivada:
no Caps IPv6 activadas: sí

Sin Automated Steering, BGP instalaría la ruta VRF Acme [Link]/24 recursivamente en su nexthop BGP
[Link]. Recursión significa básicamente que la ruta se refiere a otra ruta para su información de reenvío. Al
recursar sobre el nexthop BGP, todo el tráfico destinado a [Link]/24 seguiría el Prefijo-SID de [Link] hacia el
Nodo4.

Con el direccionamiento automatizado, BGP no recurre a la ruta en su nexthop BGP, sino en el BSID de la
política SR correspondiente. En este caso, BGP instala la ruta [Link]/24 recurriendo al BSID 40001 de la
Política SR GREEN, como se muestra en el Ejemplo 5-8. La entrada RIB (la primera salida en el Ejemplo 5-
8) muestra el BSID (Binding Label: 0x9c41 (40001)). La entrada CEF (la segunda salida) muestra que la
ruta pasa por local-label 40001, que resuelve a la política SR GREEN ((con color 30 y