ナレッジセンター
匠コラム

Segment Routingの美味しい使い方①

匠コラム: 自動化; ネットワーク; データセンター

2022.01.19

ビジネス開発本部
第1応用技術部ネットワークチーム
平河内竜樹

本記事では、昨今取り上げられることが多いSegment Routingを対象に、新たな選択肢の特徴的な機能とその具体的な活用場面を紹介します。（第1回）

連載インデックス
Segment Routingの美味しい使い方① Segment Routingの美味しい使い方②

本ページには、主に下記の情報が含まれています。
また、「おわりに」の項にて全体のまとめを記載しております。
先に概要を把握された方はこちらからご覧いただければと思います。
本ページには、主に下記の情報が含まれています。

contents

前書き
はじめに：FRR (Fast Reroute) のシンプル化
TI-LFA：従来技術との比較
TI-LFA：設計・設定上の留意点
試験の環境と結果
おわりに：FRR (Fast Reroute) のシンプル化

更新履歴

[2022/01/19] 記事公開
[2022/01/24] 誤字修正（情報の追加・削除はありません）

L_1

前書き

SP/DCネットワークでよく挙げられるEVPNやSegment Routingといった技術も、成熟が進み、日本国内でも複数の事例が紹介されるようになりました。

これらの技術は多くの要素を含み非常に多機能です。
一方、構築されたネットワークが提供可能なサービスは従来の技術でも実現可能に見えることも多く、誰に対してどのようなベネフィットをもたらすものであるか分かりづらい状況も発生しているように感じています。
またあまり表立って主張されることは少ないように思えますが、前身となる技術と比較した際には要求に対し完全な後方互換があるとは限らず、「アーキテクチャとして両立しない」「仕様や実装が追い付いていない」といった理由で、実現できない動作も存在しています。
さらに実際の検討では、実装の成熟度も重要な視点となります。これは、単に古くから存在している技術の方が枯れているということに留まらず、ものによってはEVPNやSegment Routingの方が実装は先行しているといったケースも存在します。
これらの経緯から技術選択の際には、対象とするネットワークの重点項目や制約を加味した上で、要求や環境条件への適合性を検討することになります。

本記事では、現存するSP/DCネットワークでよくある要求を実現するための技術選択において、Segment Routingが効果的に作用する構成パターンを紹介したいと思います。
適用場面がこれに限るわけではなく、Segment Routingを検討する際の参考になれば幸いです。

なお本記事のSegment Routingに関しては、SR-MPLSとSRv6、二種類のデータプレーン（図1）をまとめて扱います。
データプレーン間の差異やSegment Routingの基本的な事項については過去の記事（□）及び【補足情報】でも言及しており、必要に応じてご参照いただければと思います。

図１： Segment Routingの典型的な機能とデータプレーン種別

【補足情報】

Segment Routingの位置付けと特徴

SRv6の位置付けと特徴

（正常に表示するため、ページのリロードやフレームの再読み込みが必要になることがあります。）

以降の記述では、データプレーンの全般的な差異については言及せず、また特記が無ければ原則双方に該当する内容となります。
合わせて、項目固有のデータプレーン差分などについては適宜触れていきます。

目次に戻る

はじめに：FRR (Fast Reroute) のシンプル化

まず取り上げるSegment Routing（以下「SR」）の用途は、高可用性に対する要求を、よりシンプルな形で実現する手段として適用するというものです。
これはTI-LFA （Topology Independent Loop-Free Alternate：紹介記事）の利用により、「バックアップパスの設計・設定を省略したFRRを実現可能」という特徴に基づいた用途となります。

図2：トポロジフリーとシンプルさを両立するプロテクション方式（【補足情報】より抜粋）

VXLANなどの進展によってIPネットワーク上でマルチテナント対応のVPNが構成可能になった現在においても、MPLSを利用するモチベーションの一つが、FRRの実現です。
トポロジの選択に自由度がある場合、ECMP・LFA（□）などの利用によって可用性の要求を満たせることも多くあります。
対して、とりわけ制約の発生が多いWAN環境では、そのような技術の適用が困難となります。またパス計算結果に依存せずバックアップとなるネクストホップを保持する手法は、ループフリーが担保されない条件下に適用すれば、マイクロループが発生する余地を残すことになります。
このため、トポロジが制約される環境で高可用性を確保するためには、バックアップパスを別途形成してリンクやノードの障害に備えることが有用となります。

ローカルで発生した障害に反応して通信をバックアップパスに迂回させるテクニックはローカルリペア（□□）と呼ばれ、リンクに対する保護がリンクプロテクション、ノードに対する保護がノードプロテクション（□□）となります。

目次に戻る

TI-LFA：従来技術との比較

上記を実現するため伝統的な手法とも言えるMPLS FRR（□）では、IGPによるパス計算とは別に、バックアップパスとなるLSP（Label Switched Path）を必要とします。
バックアップパスの形成方法にはバリエーションが存在するものの、いずれにせよ保護対象となるTE LSPが確立された上で、迂回用の新たなTE LSPが導出されます。
その結果、ヘッドエンドにおけるEgress PE単位のLSP形成や、各PLR (*1) でのLSP形成に対して、設定が発生することになります。

(*1)：PLR

Point of Local Repairの略で、文字通りローカルリペアが行われる箇所を指します。
障害イベントを直接リンク障害として認識する場所に相当し、バックアップとなるLSPのヘッドエンドとなります。

図3は、あるひとつのノードがヘッドエンドとなるLSPに対してリンクプロテクションを提供する場合、対象のLSP（黒線）と用意されるRSVP-TE LSP（白線）の例を図式化したものです。
このように単純な構成であっても、網羅的にプロテクションを提供しようとすれば、LSPの総数は増加していきます。
試験の段階で設計や設定の誤りが発覚し、修正を余儀なくされた経験をお持ちの方もいらっしゃるのではないでしょうか。

図3：保護されるLSPに対して用意される保護用LSPの例

また、LSP単位で設定が必要となれば、トポロジの拡張が設定の内容に少なからず影響を及ぼすことは想像に難くありません。
この点に関しては、製品によってEgress PE単位や迂回路単位のLSP設定を単純化可能な実装（□□□）も存在しています。
ただその場合も、「LSPに関係する全てのノードでRSVPが必要となる」「各方式で対応可能な範囲が異なる」といった点は残存します。

このようにRSVP-TEによるFRRの導入は、IGPベースのネットワークに対し、相応の複雑さをもたらすものと言えます。

図4：FRRに対する複雑さの課題（IETF87 STATUS BOF資料より抜粋）

対してSR環境でTI-LFAを利用した場合、宛先となる各IGP Prefixに対し、ループフリーを保証された代替パスが自動で算出されます。
ヘッドエンドやPLRで、トポロジに関する要素を指定する必要はありません。
この時、バックアップパスの算出は各SRノードに閉じて行われ、構成されたSegment Listに対し新たな折衝は発生しません。
SRドメインの中でバックアップパスが必要なノード、もしくはTI-LFAを利用可能なノードに限定して有効にすることも可能です。

特にSRv6の場合、コントロールプレーン・データプレーン共にSR非対応のノードを中継に介在させることも可能です。
中継のSR非対応のノードでは、認識できないIGP拡張は無視され（□□）、データプレーン処理は通常のIPv6転送且つ必要なPrefixは通常の方法によって学習できます。
End及びEnd.Xの動作が行えない中継ノードが発生するため、バックアップパスの網羅性を欠く原因にはなり得ますが、ローカルリペアの際に他のノードで付与されたEnd及びEnd.XのSIDを中継することに問題はありません（参考： □）。

またTI-LFAは、TE LSPを保護する用途においても有用であることに加えて、TE LSPの利用を前提とせず有効にできる点が大きな特徴です。
技術としては、Active SegmentとなるSIDに対しバックアップパスが保持されていれば、ローカルリペアが可能となります。
実際には実装上の経緯で対応可能な範囲が制約されることもありますが、ヘッドエンドでのSegment Listの構成方法に依らず、全てのIGP Prefixに対しバックアップパスが自動で算出されます。
状態確認の面でも、経路表のサマリを見てバックアップパスの保持を判断できる実装が目立ちます。

図5は、バックアップパスの形成にRSVP-TE LSPを用いた場合とSRでTI-LFAを用いた場合の、リンク障害に対するサービス停止時間を測定した際の結果です。
この試験ではCisco Systems社のNCS 5500シリーズを用い、プロテクションの有無や、データプレーンの種別に関する差異も確認しています。

図5：通信の復旧に要した時間の比較

RSVP-TE・SR-MPLS・SRv6でそれぞれバックアップパスを形成した場合、それらの間では、結果に差はほとんど表れませんでした。
加えて、ローカルリペアの動作を行うノード以外のすべてのSRノードからTI-LFAを無効にしても、同様の結果が得られることをSR-MPLSおよびSRv6でそれぞれ別途確認しています。

またSRv6の構成では、IGPパラメータとしてSPF delayの値を大きくしたパターンを追加で実施しました。
この時、TI-LFAを有効にしていない場合はサービス停止時間が長引く一方、TI-LFAを有効にした場合は同等の結果が得られることを確認しています。
この点に関しては、今回とは別の環境で実施した試験では、SR-MPLSも同じ結果となっていました（過去の記事）。

上記の結果から、バックアップパスの形成方法およびデータプレーンの違いは障害時のサービス停止時間に対して有意な影響を及ぼす要素ではなく、PLRにおけるバックアップパスの有無が大きな境目になると言えます。

なお観測される障害時のサービス停止時間は、製品やハードウェア構成といった、バックアップパスの有無とは異なる要素の影響も受けます。このため、利用する機能が同一であっても、環境によってその値は異なることがあります。
一方TI-LFAは、高速な障害復旧を実現する技術としては、伝統的なMPLS FRR構成と比較して同等の品質を提供できるものと捉えて差し支えありません。

目次に戻る

TI-LFA：設計・設定上の留意点

補足としてSegment Routingは、RSVP-TEと同様に（□）、unnumbered link上にも適用可能です。
その際には、各リンクに固有のアドレスが設定されていない状態であってもAdj-SIDの割り当てを行うことが可能です。
同様に、対応状況は分かれるかもしれませんが、TI-LFAを有効にすることも可能です。
ただこの場合、unnumberedインタフェースの利用がトポロジや他の機能を利用する上での制約に繋がる可能性はありますし、設定情報からトポロジを特定できなくなるという側面もあります。

またトランスポートネットワークがIPv6で構成される場合、リンクがlink-localアドレスのみで構成された状態においても、TI-LFAは適用可能です。
Segment Routing環境のIPv6は、リンク単位の固有アドレス省略とプロテクションの提供を自然な形で同時に実現できる側面があると言えます。
補足として、IPv6コントロールプレーンは、SRv6だけでなくSR-MPLSでも利用可能です。IPv4で構成した場合との機能差や成熟度といった実装面での差分が発生するためその点は考慮事項となりますが、IPv6適用検討の主眼がコントロールプレーンである場合、SR-MPLS with IPv6はその選択肢となります。

なおSRv6では、Prefix-SIDの役割を果たすEnd だけでなく、Adj-SIDの役割を果たすEnd.X もLocatorとなるPrefixに属するGlobally Uniqueな値となります。
このため、SR-MPLSであればPrefix-SIDとAdj-SIDが組み合わせてスタックされる環境下においても、SRv6の場合End.Xのみのスタックで同様の動作を実現することが可能です。
この動作は、TI-LFAによって自動算出される際にも該当します（□）。
この点の差異に関しては、設定などで意識する機会はありませんが、トポロジやコストが共通であってもデータプレーンのプロトコルによってSIDの段数が異なってくるといった形で違いに表出してきます。

TI-LFAの場合、バックアップパスの形成および利用はRouting Protocolに依存することになるため、「Failbackのタイミングもトポロジ変化に追従する（任意のタイミングで切り戻す要求との相性）」「バックアップパスの算出には計算が必須（PLRのconfigだけで判断する・確定させる要求との相性）」といった側面があります。
実際にはこういった点が要求に挙がらない場面の方が多いかもしれませんが、適用を検討する際には、動作の特性を踏まえた上で総合的に判断することになります。

目次に戻る

試験の環境と結果

以降では、前項で紹介した品質の差異に関する情報に加え、設計・設定のシンプル化に関する検証データを紹介します。
今回は、試験環境にArista Networks社の7280Rシリーズを用いています。
図6は構成図、表1は各ノードにおける設定の抜粋となります。

本環境では、トランスポートにSR-MPLS with IPv4 Control Planeを用いて構成し、サービスにはL3のBGP VPNを利用しています。

表1：設定の抜粋（トランスポート）
R10
interface Ethernet47 no switchport ip address 10.10.15.10/24 isis enable INST1 isis network point-to-point interface Ethernet48 no switchport ip address 10.10.20.10/24 isis enable INST1 isis network point-to-point interface Loopback0 ip address 10.0.0.10/32 node-segment ipv4 index 10 isis enable INST1 ip routing mpls ip router isis INST1 net 49.0001.0000.0000.0010.00 router-id ipv4 10.0.0.10 is-type level-2 address-family ipv4 unicast segment-routing mpls no shutdown
R15
interface Ethernet47 no switchport ip address 10.10.15.15/24 isis enable INST1 isis network point-to-point interface Ethernet48 no switchport ip address 10.15.25.15/24 isis enable INST1 isis network point-to-point interface Loopback0 ip address 10.0.0.15/32 node-segment ipv4 index 15 isis enable INST1 ip routing mpls ip router isis INST1 net 49.0001.0000.0000.0015.00 router-id ipv4 10.0.0.15 is-type level-2 address-family ipv4 unicast segment-routing mpls no shutdown
R20
interface Ethernet47 no switchport ip address 10.20.25.20/24 isis enable INST1 isis network point-to-point interface Ethernet48 no switchport ip address 10.10.20.20/24 isis enable INST1 isis network point-to-point interface Loopback0 ip address 10.0.0.20/32 node-segment ipv4 index 20 isis enable INST1 ip routing mpls ip router isis INST1 net 49.0001.0000.0000.0020.00 router-id ipv4 10.0.0.20 is-type level-2 address-family ipv4 unicast segment-routing mpls no shutdown
R25
interface Ethernet47 no switchport ip address 10.20.25.25/24 isis enable INST1 isis network point-to-point interface Ethernet48 no switchport ip address 10.15.25.25/24 isis enable INST1 isis network point-to-point interface Loopback0 ip address 10.0.0.25/32 node-segment ipv4 index 25 isis enable INST1 ip routing mpls ip router isis INST1 net 49.0001.0000.0000.0025.00 router-id ipv4 10.0.0.25 is-type level-2 address-family ipv4 unicast segment-routing mpls no shutdown

図6：試験の構成図

まず、必要な設定を行った後、図中のVLAN 2からVLAN 3宛の通信が疎通することを確認しました。
また、この片方向通信を印加した状態で、対向機器側のインタフェースに対しシャットダウンの操作を行うことでリンク障害を模擬しました。
R10-R20間のリンクがダウン状態となった際には、一定のサービス停止時間を経て、通信が復旧することをあわせて確認しています。

その後、リンクプロテクションを実現するため、TI-LFAの有効に必要な設定を追加しました。
表2はその時に追加した設定、表3は設定前後の状態情報を比較した結果となります。

表2：設定の抜粋（TI-LFAの追加）
R10 / R15 / R20 / R25
router isis INST1 address-family ipv4 unicast fast-reroute ti-lfa mode link-protection

表3：転送テーブルの状態（左：TI-LFA有効化前、右：TI-LFA有効化後）
R10	R10
Edge-10#show mpls lfib route MPLS forwarding table (Label [metric] Vias) - 6 routes MPLS next-hop resolution allow default route: False Via Type Codes: M - MPLS via, P - Pseudowire via, I - IP lookup via, V - VLAN via, VA - EVPN VLAN aware via, ES - EVPN ethernet segment via, VF - EVPN VLAN flood via, AF - EVPN VLAN aware flood via, NG - Nexthop group via Source Codes: G - gRIBI, S - Static MPLS route, B2 - BGP L2 EVPN, B3 - BGP L3 VPN, R - RSVP, LP - LDP pseudowire, L - LDP, M - MLDP, IP - IS-IS SR prefix segment, IA - IS-IS SR adjacency segment, IL - IS-IS SR segment to LDP, LI - LDP to IS-IS SR segment, BL - BGP LU, ST - SR TE policy, DE - Debug LFIB IA 100000 [1] via M, 10.10.15.15, pop payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet47 IA 100001 [1] via M, 10.10.20.20, pop payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet48 B3 116384 [0] via I, ipv4, vrf VRF1 IP 900015 [1], 10.0.0.15/32 via M, 10.10.15.15, pop payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet47 IP 900020 [1], 10.0.0.20/32 via M, 10.10.20.20, pop payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet48 IP 900025 [1], 10.0.0.25/32 via M, 10.10.15.15, forward payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet47 via M, 10.10.20.20, forward payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet48 Edge-10#	Edge-10#show mpls lfib route MPLS forwarding table (Label [metric] Vias) - 6 routes MPLS next-hop resolution allow default route: False Via Type Codes: M - MPLS via, P - Pseudowire via, I - IP lookup via, V - VLAN via, VA - EVPN VLAN aware via, ES - EVPN ethernet segment via, VF - EVPN VLAN flood via, AF - EVPN VLAN aware flood via, NG - Nexthop group via Source Codes: G - gRIBI, S - Static MPLS route, B2 - BGP L2 EVPN, B3 - BGP L3 VPN, R - RSVP, LP - LDP pseudowire, L - LDP, M - MLDP, IP - IS-IS SR prefix segment, IA - IS-IS SR adjacency segment, IL - IS-IS SR segment to LDP, LI - LDP to IS-IS SR segment, BL - BGP LU, ST - SR TE policy, DE - Debug LFIB IA 100002 [1] via M, 10.10.15.15, pop payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet47 IA 100003 [1] via M, 10.10.20.20, pop payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet48 B3 116384 [0] via I, ipv4, vrf VRF1 IP 900015 [1], 10.0.0.15/32 via TI-LFA tunnel index 1, pop payload autoDecide, ttlMode uniform, apply egress-acl via 10.10.15.15, Ethernet47, label imp-null(3) backup via 10.10.20.20, Ethernet48, label 900025 900015 IP 900020 [1], 10.0.0.20/32 via TI-LFA tunnel index 0, pop payload autoDecide, ttlMode uniform, apply egress-acl via 10.10.20.20, Ethernet48, label imp-null(3) backup via 10.10.15.15, Ethernet47, label 900025 900020 IP 900025 [1], 10.0.0.25/32 via M, 10.10.15.15, forward payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet47 via M, 10.10.20.20, forward payload autoDecide, ttlMode uniform, apply egress-acl interface Ethernet48 Edge-10#

表3：転送テーブルの状態（左：TI-LFA有効化前、右：TI-LFA有効化後）

R10

Edge-10#show mpls lfib route
MPLS forwarding table (Label [metric] Vias) - 6 routes 
MPLS next-hop resolution allow default route: False
Via Type Codes:
          M - MPLS via, P - Pseudowire via,
          I - IP lookup via, V - VLAN via,
          VA - EVPN VLAN aware via, ES - EVPN ethernet segment via,
          VF - EVPN VLAN flood via, AF - EVPN VLAN aware flood via,
          NG - Nexthop group via
Source Codes:
          G - gRIBI, S - Static MPLS route,
          B2 - BGP L2 EVPN, B3 - BGP L3 VPN,
          R - RSVP, LP - LDP pseudowire,
          L - LDP, M - MLDP,
          IP - IS-IS SR prefix segment, IA - IS-IS SR adjacency segment,
          IL - IS-IS SR segment to LDP, LI - LDP to IS-IS SR segment,
          BL - BGP LU, ST - SR TE policy,
          DE - Debug LFIB
 IA  100000   [1]
                via M, 10.10.15.15, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet47
 IA  100001   [1]
                via M, 10.10.20.20, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet48
 B3  116384   [0]
                via I, ipv4, vrf VRF1
 IP  900015   [1], 10.0.0.15/32
                via M, 10.10.15.15, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet47
 IP  900020   [1], 10.0.0.20/32
                via M, 10.10.20.20, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet48
 IP  900025   [1], 10.0.0.25/32
                via M, 10.10.15.15, forward
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet47
                via M, 10.10.20.20, forward
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet48
Edge-10#

Edge-10#show mpls lfib route
MPLS forwarding table (Label [metric] Vias) - 6 routes 
MPLS next-hop resolution allow default route: False
Via Type Codes:
          M - MPLS via, P - Pseudowire via,
          I - IP lookup via, V - VLAN via,
          VA - EVPN VLAN aware via, ES - EVPN ethernet segment via,
          VF - EVPN VLAN flood via, AF - EVPN VLAN aware flood via,
          NG - Nexthop group via
Source Codes:
          G - gRIBI, S - Static MPLS route,
          B2 - BGP L2 EVPN, B3 - BGP L3 VPN,
          R - RSVP, LP - LDP pseudowire,
          L - LDP, M - MLDP,
          IP - IS-IS SR prefix segment, IA - IS-IS SR adjacency segment,
          IL - IS-IS SR segment to LDP, LI - LDP to IS-IS SR segment,
          BL - BGP LU, ST - SR TE policy,
          DE - Debug LFIB
 IA  100002   [1]
                via M, 10.10.15.15, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet47
 IA  100003   [1]
                via M, 10.10.20.20, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet48
 B3  116384   [0]
                via I, ipv4, vrf VRF1
 IP  900015   [1], 10.0.0.15/32
                via TI-LFA tunnel index 1, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                    via 10.10.15.15, Ethernet47, label imp-null(3)
                    backup via 10.10.20.20, Ethernet48, label 900025 900015
 IP  900020   [1], 10.0.0.20/32
                via TI-LFA tunnel index 0, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                    via 10.10.20.20, Ethernet48, label imp-null(3)
                    backup via 10.10.15.15, Ethernet47, label 900025 900020
 IP  900025   [1], 10.0.0.25/32
                via M, 10.10.15.15, forward
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet47
                via M, 10.10.20.20, forward
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet48
Edge-10#

表3を見ると、マルチパスが保持できていなかったPrefixに対し、バックアップパスが形成されていることが窺えます。
これは、TI-LFAを有効にした残りの3ノードでも同様の結果でした。
あわせて、TI-LFA有効化前と同じ試験を実施し、バックアップパスの形成によってサービス停止時間が短縮されることを確認しています。

TI-LFAの有効化で必要になった設定（表2）を見ると、追加されたコマンドは1行であり、またリンクやノードに関連する内容は含まれていませんでした。
この後、トポロジの変化が発生した際も、リンクプロテクションを提供する範囲では設定の編集は発生しないことが窺えます。

上記より、FRRの要件に対しTI-LFAを利用することで、設計・設定・状態確認いずれの面においてもTE LSPに起因した複雑さは排除されていることが確認できました（【ヘッドエンド及びPLRからのTE LSP省略】）。

目次に戻る

おわりに：FRR (Fast Reroute) のシンプル化

Segment Routingの活用により、FRRの要件に対し、以下の要素を提供することができます。

TE LSPの排除
（TE pathが不要な場合、全ての箇所からTE LSPを省略）
TE LSPに関する設計及び設定の簡素化
（TE pathが必要な場合、保護用のTE LSPを省略し、パス選択用にのみTE LSPを利用）

またSRv6やSR-MPLSのIPv6 Control Planeでは、IPv4と同様にFRRを実現可能であることに加えて、IPv6 リンクローカルアドレスの活用が可能となります。

論理レイヤの可用性設計はバックアップパスの保持に掛かってくるため、TE LSPの設計・設定が適切に行える環境であれば、TI-LFAは特段可用性の面で価値に感じられることはないかもしれません。
一方、TE LSPの導入は相応に複雑であり、場合によってはそれがコストや実現可能性へ跳ね返ってくることになります。このような場面では、TE LSPを排してバックアップパスを保持できるTI-LFAの特徴は、特に利点として映ると考えられます。
同様に、従来であればIGPベースで構成されていたネットワークに対し、複雑さを抑えながら付加価値的に可用性を高めるアプローチとしてSegment Routingを活用することができます。

目次に戻る