Cette vidéo, proposée par Jean-Charles Bisecco pour la Task-Force IPv6 et l'Arcep présente le protocole SRv6 (Segment Routing over IPv6 dataplane) et la stratégie de déploiement.
L'introduction du protocole par Polytechnique Paris est faite dans cette vidéo : https://www.dailymotion.com/video/x8qhull
Une vidéo se consacre à BIERv6 (Bit Index Explicit Replication IPv6 encapsulation) : https://www.dailymotion.com/video/x8qhupv
Licence Creative Commons BY-SA 4.0 Jean-Charles Bisecco.
Category
🤖
TechnologieTranscription
00:00 Bonjour, je suis Jean-Charles Bizéco et je vais vous parler aujourd'hui d'un protocole en plein essor
00:06 notamment chez les opérateurs destinés au transport de données
00:10 qui se nomme SRV6 pour segment de routing basé sur IPv6
00:16 Historiquement, différents réseaux coexistaient pour fournir de la téléphonie ou de la télédiffusion par exemple
00:26 plus tard, on a commencé à fournir de la donnée puis de l'internet pour les particuliers et les entreprises sur ces réseaux
00:33 Cette convergence était permise d'une part par une consolidation protocolaire
00:41 au bas niveau de ces services, d'autre part par l'arrivée du tout sur IP
00:47 notamment de la voix sur IP et donc de la télévision sur IP
00:50 Il reste cependant quelques exceptions
00:53 par exemple les réseaux câblés continuent de fournir la télévision de façon classique
00:58 Si l'on s'intéresse maintenant à la fibre optique
01:01 elle est arrivée dans un monde où les protocoles étaient déjà capables de fournir les services sur IP
01:07 et on a donc aujourd'hui chez une majorité des utilisateurs
01:12 une encapsulation complète intégrale de tous les services sur de l'IP
01:19 Sinon, si l'on s'est intéressé aux terminaisons et aux fournitures chez les clients finaux
01:25 il a fallu également côté opérateur trouver des moyens de converger le transport de ces différents services
01:34 On en a donc de différents types avec des contextes
01:40 et des besoins de qualité de service sur les différents types
01:46 et des besoins de qualité de service qui sont différents avec parfois par exemple de la réservation de bandes passantes
01:53 Il y a eu diverses technologies qui ont existé
01:57 Actuellement, le protocole MPLS est le protocole dominant chez les backbones opérateurs pour transporter des services IP
02:08 Avec le temps, les débits ont augmenté
02:15 Plus récemment, l'arrivée de la fibre optique et de la 4G puis de la 5G
02:20 ont fait exploser les débits et permis des nouveaux usages extrêmement consommateurs
02:24 On a pu notamment voir l'arrivée du streaming
02:28 mais également si vous vous intéressez à l'évolution des systèmes
02:31 voir la taille des packages applicatifs sur les téléphones par exemple exploser en taille
02:36 ou également les mises à jour de jeux être très consommatrices de ressources réseaux
02:42 Cela se caractérise par les opérateurs avec une augmentation considérable des capacités d'échange
02:46 Vous pouvez voir ici une étude sur un petit peu moins de 10 ans de l'évolution
02:52 En parallèle, les opérateurs ont toujours une quête de réduction de la latence et de la gigue
03:00 pour permettre à de nouveaux usages d'être possibles sur les réseaux et d'améliorer la perception client
03:10 Pour autant, il n'est pas possible de déployer des capacités à l'infini
03:14 notamment pour permettre des bascules et des secours en cas de coupure
03:18 Il faut donc trouver les moyens techniques de rester compétitif en exploitant au mieux les ressources
03:27 en les mutualisant tout en étant capable de servir les clients et les besoins les plus spécifiques en parallèle des autres
03:36 Si l'on continue à s'intéresser à MPLS, l'arrivée du Traffic Engineering avec MPLS-TE
03:42 a permis de mieux répartir le trafic vers une même destination sur plusieurs chemins
03:46 de permettre le reroutage rapide local en cas de panne
03:49 en complément de capacités de restauration de bout en bout
03:53 voire de protection globale pour les usagers les plus exigeants avec des chemins préétablis
04:00 Si l'on prend un cas typique d'un site à gauche qui chercherait à joindre son datacenter à droite via deux chemins totalement différents
04:08 et que l'on simule une panne, on souhaiterait dans l'idéal que le trafic ne repasse pas par des équipements communs au premier chemin en bleu
04:19 Certes, il est possible de faire ce genre de choses pour éviter ce cas de figure
04:27 mais cela se complexifie rapidement en ajoutant énormément de règles manuelles sur les équipements
04:33 ce qui donne des coûts d'exploitation, une complexité de configuration
04:38 et même si aujourd'hui on a des orchestrateurs chez les opérateurs pour gérer ce type de cas
04:45 cela devient extrêmement lourd au quotidien
04:53 Au final, si l'on traite tous les clients avec une rigueur extrême sur les chemins et la séparation
05:01 on peut vite se retrouver avec un véritable labyrinthe intermédiaire de cheminement et de circuit virtuel constitué entre les équipements
05:11 Choisir le bon chemin entre deux sites n'est pas toujours aisé
05:21 On va généralement s'intéresser au chemin le plus rapide
05:23 même si l'on a parfois des chemins plus courts en latence mais avec des bandes passantes moins élevées
05:29 Si l'on privilégie ces chemins transverses en temps normal
05:34 parfois ils deviendront des chemins de secours dans certains cas
05:39 alors qu'on souhaiterait passer par encore d'autres chemins pour éviter des saturations
05:45 Il est donc compliqué pour un opérateur d'avoir une configuration à la fois optimale en temps normal
05:52 et qui puisse absorber les pannes, les coupures en limitant le risque de saturation
06:01 Cette topologie peut vous paraître atypique et vous allez voir pourtant qu'elle est tout à fait courante si l'on y ajoute une carte
06:11 Dans notre exemple, un trafic entre Bordeaux et Marseille passera probablement par Paris et Lyon
06:18 alors même qu'il existe généralement des chemins optiques plus courts avec une meilleure latence mais des débits plus faibles
06:26 Choisir le bon chemin est donc un équilibre entre ces différentes priorités que l'on va se mettre en oeuvre
06:37 Proposer des chemins optimisés pour chaque type de trafic est finalement l'un des objectifs, sinon le principal, du segment routing
06:51 L'idée de base est d'apporter la liste complète des nodes à traverser dans une entête
06:58 et de laisser les routeurs intermédiaires traiter les paquets à grande vitesse comme ils le font avec la commutation sur la Belle de MPLS
07:06 Cette technologie était initialement basée sur MPLS avec SRMPLS et dès 2013 il y a eu une proposition de faire de même avec IPv6
07:22 en utilisant l'entête IPv6 et ses longues adresses pour stocker un chemin, ainsi naquit SRV6
07:31 Premier avantage évident, on va exploiter IPv6 en data plane et un IGP qui sera généralement ISAS
07:40 La stack technique est donc beaucoup plus simple que les autres protocoles, on quitte là les millefeuilles classiques que l'on peut voir avec MPLS
07:51 Si certains se demandent pourquoi on privilégie ISAS, c'est notamment car il supporte l'ajout de TLV
07:58 et ces variables, vous allez le voir plus tard, vont être très importantes pour proposer certaines options et optimisations
08:06 Deuxième avantage d'utiliser une encapsulation SRV6 en data plane, il est possible de traverser des nodes qui ne sont pas encore configurés
08:16 pour faire du segment routing SRV6 tant qu'ils savent router de l'IPv6
08:23 A ce jour, les efforts de l'ITF et des constructeurs portent plutôt sur SRV6
08:30 Dans la suite de cette vidéo, nous allons d'ailleurs nous concentrer, comme le titre l'indiquait, sur SRV6
08:38 Prenons une topologie simple, afin de pouvoir identifier les segments, nous allons devoir leur apposer des numéros
08:48 Imaginons ce qu'il va se passer en sortie de la node 34 pour aller vers les serveurs qui sont à droite
08:55 On va recopier les numéros de segments à traverser et leur mettre un numéro d'ordre en partant de la dernière node à traverser
09:07 Le principe est de recopier le numéro d'ordre de la prochaine node dans un champ, le "side_left"
09:19 Puis d'aller lire la valeur correspondant à cette node et de la recopier comme étant notre prochain saut
09:31 Arrivé à la suivante, pour aller de la 67 à la 29, on va donc chercher la numéro d'ordre 2, qui est la 29, et le recopier
09:43 Et ainsi de suite, jusqu'à la fin, la note de sortie qui sera la 0 en ordre, et donc ici la numéro 48
09:53 Si l'on s'intéresse à l'entête SRH, on recopie donc nos SID traversés dans l'entête
10:06 Et on va finalement changer à chaque saut simplement en gris le nombre de sauts restants, donc le numéro d'ordre en cours
10:16 Et les adresses de source et de destination, exemple ici de l'état du paquet entre la 87 et la 48
10:29 Rajoutons un intrus sur ce chemin, un routeur qui ne fait pas d'SRV6 mais qui sait faire de l'IPv6 tout simple via l'IGP
10:41 Le SID 48 étant finalement lisible comme une simple adresse IPv6 de destination, le paquet SRV6 pourra traverser cette node ne faisant pas de SRV6
10:57 C'est un élément intéressant pour faciliter les déploiements de façon progressive
11:03 Abordons maintenant les différents modes de fonctionnement d'SRV6
11:13 Tout d'abord un mode dit "best effort", assez semblable à ce que vous pouvez connaître
11:20 Dans un PLS classique on monte son IGP, une signalisation LDP, on forme des chemins LSP entre les PE
11:27 Et on regroupe les routes destinées aux mêmes PE via la notion de classe équivalente, les FEC
11:35 Ce faisant on limite la taille des tables des routeurs P pendant que les PE échangent en BGP avec un routeur effecteur
11:44 Côté datacenter, pour ceux qui font du VPN VXLAN, on a aussi des systèmes d'échange entre VTEP
11:52 Et on peut tout à fait traverser entre différentes fabriques des réseaux qui n'ont pas du tout conscience des adresses clients mais uniquement des VTEP
12:01 Il existe même d'ailleurs depuis peu des systèmes de masquerade pour faire apparaître un datacenter comme un seul élément vis-à-vis du reste
12:12 Des choses qui sont d'ailleurs fraîchement normalisées en RFC
12:14 Revenons-en à SRV6, ce fonctionnement de base va nous faire transporter les paquets avec simplement un suivi de ce que connaît l'IGP
12:27 Mais on va retrouver déjà quelques options et fonctionnalités intéressantes que l'on a également en PLS évidemment
12:37 Le TI-LF qui va nous permettre de pré-calculer des chemins, du reroutage rapide, généralement en moins de 50ms
12:50 Et des systèmes permettant d'éviter les boucles qui fonctionnent notamment avec le TI-LF d'une part
13:00 Mais aussi spécifiquement dans le segment routing avec des politiques, des stratégies de segment routing temporaires
13:08 Le principe, pour rappel, étant d'éviter pendant que les machines convergent lors d'un incident, d'une coupure de lien, d'envoyer des paquets qui reviendraient et boucleraient
13:20 On applique donc une sorte de haro sur les mises à jour de routage le temps d'être sûr que tout le monde ait à converger
13:29 Dans ce mode on n'a pas forcément besoin de SRH finalement, pourquoi ? Parce qu'on va simplement cibler la dernière note
13:41 Voyons un exemple à la prochaine
13:46 Voici une topologie simple avec des liens ayant le même coût dans l'IGP, les mêmes caractéristiques
13:56 Un paquet best-effort va donc simplement le traverser en se basant sur ce que connaît l'IGP
14:06 Si on veut complexifier la chose, nous allons commencer à regarder les différentes options
14:15 La première est donc de faire le traffic engineering de segment routing
14:19 On va descendre des stratégies manuellement dans les équipements qu'on peut orchestrer
14:26 Afin d'identifier du trafic par couleur et de leur marquer à chaque fois la note suivante à traverser en fonction de cette couleur
14:36 Le tout se regroupe sous une politique, une stratégie, chaque règle est certique correspond à cette concordance entre une couleur et le prochain saut
14:48 Reprenons cette topologie et essayons de regarder comment ajouter une autre topologie virtuelle basée sur la même topologie physique
15:09 Cette fois non plus basée sur des liens Iso-coût mais sur la latence des chemins
15:19 En regardant le schéma, on va rapidement identifier visuellement le chemin le plus rapide entre la source à gauche et la destination à droite
15:33 Nous allons voir les différentes solutions qui vont permettre de calculer ces chemins
15:41 On va parler du côté application de topologie de slice
15:46 Ici nous avons en haut une slice noire qui est classique, le best effort, et une basée sur la latence en vert
15:58 Reprenons cette topologie et ajoutons des identifiants
16:04 Nous avons ici du B1, B3, etc. sur la ligne du haut et 2, 4, 6 sur la ligne du bas
16:13 Le chemin va donc logiquement, une fois B1 atteint, traverser B3, B5, B7
16:23 Je vous l'ai dit tout à l'heure, l'adresse de la node est finalement lisible comme une simple adresse de destination IPv6
16:33 On peut donc directement suivre B7, après tout on n'a pas besoin de spécifier B3, B5
16:42 Le chemin en indiquant qu'il cherche à router vers B7 va pouvoir l'atteindre de la même façon via les connaissances de topologie qu'à l'IGP
16:57 Côté latence, le chemin est plus spécifique dans cette slice puisqu'on va indiquer B2, B4, B5, B7
17:07 Il peut exister des façons d'optimiser cette suite mais c'est un usage un peu plus avancé qu'on ne verra pas là
17:17 Forcément, il peut être fastidieux de descendre ces configurations node par node pour chaque couleur, préciser le sceau, etc.
17:26 et de les mettre à jour si les conditions de transport changent
17:30 Notamment parce qu'on traverse soi-même d'autres réseaux sur ces liens en étant souvent encapsulés
17:37 et qu'on ne maîtrise pas forcément les changements de ces réseaux qui peuvent occasionner des pertes, des augmentations de latence, etc.
17:44 On a donc la possibilité d'avoir un calculateur central, que vous pouvez appeler PCEP ou SRPCE
17:56 et qui va nous mettre à jour en temps réel les politiques sur les équipements
18:01 et on va calculer les meilleurs chemins se basant sur des retours de télémétrie
18:07 On remonte donc de la télémétrie, généralement via BGPLS, avec la latence, la perte, la saturation
18:13 Il existe également plusieurs méthodes de télémétrie, point à point, ou de bout en bout, source-destination
18:23 On n'apportera pas tout ce qui existe sur le marché actuellement
18:30 Un avantage également du contrôleur est de pouvoir prévisualiser des changements de stratégie
18:34 puisqu'on peut voir ce qui va se passer sur les réseaux en termes de charges avec son travic actuel
18:40 si l'on force à faire des choix d'autres chemins, etc.
18:44 si on change les règles du jeu avant même de l'appliquer, bien sûr, pour valider que tout corrobore
18:51 Reprenons notre topologie et ses identifiants, commençant par B
19:00 Envoyons de la télémétrie vers notre contrôleur et sans lui calculer les chemins
19:07 En BEST-EFFORT, on l'a vu, il est relativement simple en sortant de la note 1, nous allons aller à la 3, à la 5, à la 7
19:14 et pouvoir résumer ça via une atteinte directe de la 7
19:19 Pour la latence, nous allons laisser le contrôleur pousser le meilleur chemin qui dans notre cas était 2, 4, 5 et 7
19:32 Il va donc créer une route qu'il va pousser sur le routeur de gauche, le B1, afin de lui dire comment joindre avec la meilleure latence, B7
19:43 Évidemment, si un changement apparaît sur un lien, le contrôleur va pouvoir mettre à jour et choisir un autre chemin
19:54 Une autre méthode, cette fois sans contrôleur, est de calculer différentes topologies directement au sein de l'IGP
20:04 C'est ce qu'on va appeler "FlexAlgo"
20:07 On va par exemple pouvoir calculer une topologie avec la latence la plus faible et faire augmenter les coûts au fur et à mesure du temps de traversée d'un lien
20:17 ou encore une autre basée sur la perte de paquets pour augmenter le coût, cette fois, des liens les moins fiables
20:29 On va également pouvoir colorer manuellement des liens, par exemple pour identifier un opérateur ou un autre, ou identifier des liens avec un chiffrement MACSEC
20:39 La conjonction entre les algorithmes de calcul différenciés au sein de l'IGP et les couleurs de groupe de liens que l'on peut faire
20:53 va nous permettre de créer des topologies, des slices, répondant à divers besoins
21:00 On va donc garder une baseté forte basée sur le coût, on va pouvoir créer une simple topologie qui correspond à la meilleure latence, comme on en parlait précédemment
21:08 Mais également des choses plus compliquées, exemple une topologie avec la meilleure latence mais qui exclut les liens du fournisseur X
21:15 ou encore une topologie avec les liens qui ont le moins de pertes et qui sont chiffrés
21:22 Vous pouvez aisément y transposer des besoins courants en entreprise, par exemple pour appliquer des stratégies différentes à certains trafics classés et sensibles
21:36 D'autant qu'à la base, on ne va pas simplement marquer les flux d'un client, on peut beaucoup plus loin marquer une application et donc appliquer des stratégies de façon plus fine
21:50 FlexAlgo nous offre plus d'une centaine de possibilités qui doivent être configurées avec le même algorithme pour chaque numéro sur toutes les nodes
22:05 A défaut on s'exposerait à des risques de boucle de routage
22:09 Et cette coordination est à peu près la seule limite et contrainte que vous avez, puisque vous pouvez construire d'autres topologies avec les autres numéros, les tester, les qualifier avant de commencer à les utiliser
22:22 Cette solution est donc décentralisée
22:31 D'autre part, comme on se base sur le préfixe IPv6, on va pouvoir simplement cibler la note de sortie
22:52 Reprenons encore une fois notre topologie
23:01 Rappelez-vous en best effort, on peut atteindre le B7 directement
23:05 Avec FlexAlgo, c'est la même chose puisque finalement les routers vont avoir conscience de la topologie cette fois, ils ont donc plus d'intelligence que dans le cas de l'utilisation de SRTE
23:21 Au lieu d'envoyer toute la liste de nodes, on va simplement lui dire "va à E7"
23:33 "E" signifiant qu'on est dans la slice express
23:35 Vous noterez bien qu'on ne réutilise plus des B quelque chose mais qu'on a bien ici des E quelque chose
23:45 La faible longueur de l'entête, qui peut finalement se résumer dans certains cas à sa destination finale, fait qu'elle va pouvoir tenir dans le champ de destination IPv6
23:55 C'est ce qui rend SRH optionnel
24:00 En situation réelle, on se rend compte chez les opérateurs qui ont déjà déployé qu'on a sur beaucoup de trafic pas de SRH du tout et rarement plus de 2 chemins ajoutés dans une entête SRH sur toute ou partie du chemin
24:21 On va donc devoir choisir entre différentes options
24:25 Un réseau opérant de façon distribuée, c'est ce qu'on vient de voir avec FlexAlgo
24:30 qui nécessite simplement de garder une configuration cohérente entre les nodes sur les choix des algorithmes utilisés par les différentes slices que va provisionner l'IGP sur les nodes
24:44 Cette solution va aussi imposer de regarder quel outil d'administration et de troubleshooting on va utiliser pour tracer du trafic entre les nodes
24:54 puisqu'on n'a plus de visibilité intégrale, sauf à faire du monitoring évidemment, de ce qui se passe
25:06 Si l'on reprend le contrôleur central, le SRPC ou le PCEP, on a une visibilité intégrale, une dépendance forte à cette entité centrale qui peut inquiéter
25:16 mais finalement est-elle plus inquiétante que ce qu'on fait aujourd'hui avec des routes réflectors ou des routes serveurs ? Pas forcément
25:26 Sur un très grand réseau on va tout de même avoir quelques problèmes de mise à l'échelle et devoir choisir entre un grand contrôleur ou découper, faire des plaques et trouver des moyens d'échanger les informations entre ces contrôleurs
25:40 De même, on a toujours besoin de qualifier de façon fine et de bout en bout des routes
25:51 Nous avons pu voir que dans certains cas on peut se satisfaire d'écrire simplement la destination ou un faible nombre de noeuds à traverser
25:59 ce qui permet d'ailleurs de se passer de SRH comme je l'indiquais précédemment, puisque ça tient dans l'entête IPv6 et dans le champ de destination
26:12 On peut également toujours marquer des routes de bout en bout pour des besoins très précis
26:19 Ce ne sont pas les seuls modes de calcul, il est également possible pour le client de demander à la volée, à son équipement, une topologie, un chemin répondant à des critères particuliers
26:36 Si le réseau utilise FlexAlgo, c'est son PE qui va lire les informations de l'IGP et essayer de calculer le meilleur chemin
26:45 Et puis si on a un contrôleur central, il va simplement faire une requête au contrôleur et lui dire "provisionne-moi la stratégie pour atteindre cette destination avec ces contraintes-là"
26:56 "Envoie-moi la liste de toutes les noeuds à traverser et je vais l'écrire dans l'entête"
27:04 On peut également attraper à la volée du trafic client et changer son cheminement
27:14 On va là établir des règles avec la couleur du trafic client et puis il aura effecté une stratégie de segment routing, une stratégie de traffic engineering
27:27 Cela ressemble un petit peu dans le fonctionnement à ce qu'on peut faire avec un BGP FlowSpec
27:33 Cela permet pour un contrôleur central de descendre à la volée une règle
27:40 La programmabilité ne se situe pas seulement dans le cheminement du trafic au travers des routeurs
27:51 Mais on peut également demander par exemple à traverser une sonde ou un autre équipement sur le chemin
28:01 Au-delà des traitements hardware qui vont utiliser des SID avec des longueurs définies qui satisfont au pipeline de traitement des ASIC
28:12 Le SRH permet d'ajouter des marquages plutôt orientés pour des traitements logiciels
28:16 Typiquement des métadonnées puisqu'on va avoir des TLV modulables dans lesquels on va pouvoir stocker un petit peu ce que l'on veut
28:24 On peut par exemple stocker un groupe d'utilisateurs, des applications en les identifiant par le numéro ou n'importe quel autre marquage qui peut être utile à un traitement
28:33 Cela amène à ce que SRV6 est un très bon candidat pour interagir directement avec les systèmes
28:41 Là où MPLS n'est quasiment jamais entré dans le datacenter et encore moins dans les autres
28:49 Ce que VxLAN a réussi à faire dans certains cas en entrant dans les hyperviseurs ou dans les smartnicks
28:55 Eh bien SRV6 pourrait être le premier protocole à faire du bout en bout intelligent
29:00 Allant même jusqu'à avoir un marquage directement fait sur un téléphone portable, un OS de bureau permettant de fournir des informations
29:10 On peut donc envisager de marquer et d'identifier quel processus a envoyé un paquet sur le réseau, quel utilisateur
29:20 Et puis d'établir des règles, par exemple faire traverser dans une sonde n'importe quel paquet provenant de telle station de travail, d'un processus non identifié
29:30 Ou encore orienter des flux de façon beaucoup plus fine qu'avec le DSCP et ce qu'on fait aujourd'hui en qualité de service selon l'application
29:41 La SRV6 supporte un très grand nombre de services, on retrouve évidemment les L3 VPN courants par VRF ou par CE
29:53 Capable de transporter évidemment de l'IPv4 et de l'IPv6, du transport de VLAN, de la virtualisation de switch
30:04 Tout ce qu'on a communément sous la dénomination VPLS, avec le support de multi-homing, la fourniture de points à points type X-Connect
30:14 Des points de handover pour faire des correspondances entre du SRV6 et du SRMPLS, etc.
30:22 On a de très nombreux marquages qui sont d'ailleurs pour une partie toujours en cours de rédaction côté RFC
30:33 Là j'espère que cette vidéo d'introduction qui touche à sa fin vous aura permis d'en apprendre plus sur ce protocole
30:44 Et je vous laisse regarder d'autres éléments disponibles sur internet et je veillerai probablement à poster d'autres vidéos sur ce sujet plus tard