MPLS  Japan  2015

キャリアサービスへのEVPN
適⽤用の検討と課題
横⼭山 　博基NTTコミュニケーションズ株式会社
ネットワークサービス部

Copyright © NTT Communications Corporation. All right reserved.

EVPN評価の⽬目的n 通信事業者の置かれている状況• WANサービスは市場が成熟し、回線単価が下落落、収益は伸び悩み• ⼀一⽅方利利⽤用帯域は着実に増えており、設備増強は必要
n 必要な対応• 新規サービス開発（SDN/NFV…）• CAPEXを抑えつつもNWを⼤大容量量化• 徹底的なOPEXの削減
複数のサービスNWをMPLS上の⼤大容量量装置に集約、NWそのものとサービス提供にかかるプロセスの双⽅方をシンプル化することで実現

広域イーサネットの集約における、VPLSよりもより効果的な実現⽅方式として、EVPNの適⽤用を検討
Copyright © NTT Communications Corporation. All right reserved.

EVPN（Ethernet  VPN）とはn MPLSでのLayer2  VPNの新しい実現⽅方式• RFC  7432  :  BGP  MPLS-‐‑‒Based  Ethernet  VPN	 
• RFC  7623  :  PBB-‐‑‒EVPN	 	 	 +---------------------------------------+	 n C-‐‑‒plane（mp-‐‑‒BGP）でのMAC学習• L3のIPアドレスプレフィックスのように、MACアドレスをBGPで広告する• D-‐‑‒planeで学習する従来技術と異異なり、網全体でMACアドレスの学習状態が同期n Multihoming• Ethernet  Segmentという概念念の導⼊入•ü CEが接続されたBridged  NWの識識別⼦子	 	 	 |	 	 RD	 (8	 octets)	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 	 |Ethernet	 Segment	 Identifier	 (10	 octets)|	 	 	 	 +---------------------------------------+	 	 	 	 |	 	 Ethernet	 Tag	 ID	 (4	 octets)	 	 	 	 	 	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 	 |	 	 MAC	 Address	 Length	 (1	 octet)	 	 	 	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 	 |	 	 MAC	 Address	 (6	 octets)	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 	 |	 	 IP	 Address	 Length	 (1	 octet)	 	 	 	 	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 	 |	 	 IP	 Address	 (0,	 4,	 or	 16	 octets)	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 	 |	 	 MPLS	 Label1	 (3	 octets)	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 	 |	 	 MPLS	 Label2	 (0	 or	 3	 octets)	 	 	 	 	 	 	 	 	 	 |	 	 	 	 +---------------------------------------+	 	 	 [RFC  7432  7.2.  MAC/IP  Advertisement  Route]

複数のPEが同⼀一ESに接続する場合、remote  PEがこれを認識識し、ロードバランスやACT/SBY運⽤用が可能

Copyright © NTT Communications Corporation. All right reserved.

EVPNのメリット 　－VPLSとの⽐比較－
n Scalability
VPLS

論論理理IF数の増⼤大VPN1• 対地数×Broadcast  Domain数のPseudowireを1本1本線として装置内で管理理(論論理理IFのattach)  • Pseudowire数の増⼤大がメモリリソー
スを圧迫したり、障害時のfailover速度度に影響を与える傾向
EVPN

VPN1

VPN3

VPN2
VPN3

VPN1
VPN2
VPN3

per <ESI, Ethernet tag>

• 経路路情報としてラベルを管理理するのみ
で、論論理理IFを持たないことによる負荷の軽減• ES単位、MAC単位等、ラベルアサイン単位の最適化により、ラベル数やMPLSからの受信側PEでのLookup負荷per MACを最適化できる可能性
Copyright © NTT Communications Corporation. All right reserved.

VPN2

per MAC-VRF

EVI1
VPN1
VPN2

EVI1

VPN3

VPN1
VPN2
VPN3

EVI1
VPN1
VPN2
VPN3

per <MAC-VRF, Ethernet tag>

EVPNのメリット 　－VPLSとの⽐比較－
n オペレーション
VPLS• NWは統合されてもオペレーションの統⼀一化が難しいü D-‐‑‒plane中⼼心とC-‐‑‒plane中⼼心の考え⽅方の違い
ü 結局両⽅方のリソースを維持することに…
受信フレームを⾒見見て学習?
Flooding?

BGP?
MPLS?
L2系のオペレータ

L3系のオペレータ
1つのNWを別々にオペレーション

EVPN• C-‐‑‒plane中⼼心の考え⽅方に統⼀一されることで、L3系のオペレーションへの統⼀一に期待

L3系のオペレーションへ統⼀一、
L2系のオペレーションはアクセス設備等に限定化

Copyright © NTT Communications Corporation. All right reserved.

EVPNのメリット 　－VPLSとの⽐比較－n マイグレーション

遅延⼤大幅増VPLS

旧来の広域イーサ網• 冗⻑⾧長接続の実現に課題ü STP
ユーザ回線をü G.8032
順次移⾏行行  →  E-‐‑‒OAMの実装差分により接続できない事例例
ü VPLS-‐‑‒Multihoming  →  独⾃自実装に頼る⽅方式、PW数が2倍に冗⻑⾧長化したい

VPLS• 結果single接続による遅延の増加

EVPN側の機能で冗⻑⾧長化

EVPN

旧来の広域イーサ網• EVPNのMultihoming(single-‐‑‒active)
を使⽤用する場合ならNW間のネゴシエーションは不不要• MAC毎にprimary  PEを選択できれば、遅延最適化も可能かEVPN

経路路の最適化
Copyright © NTT Communications Corporation. All right reserved.

EVPNのメリット 　－新サービスの可能性－n L2VPN上でのサービスチェイニング
• 特定の条件にマッチするフレームのnext-‐‑‒hop  PEを変更更して経路路変更更することで、サービスチェイニングの実現
サービス機能群

対向PEの先にあるMACやES向けのトラフィックを⼀一旦経路路変更更EVPNn DC連携• DCにおいてVXLANのC-‐‑‒planeとして利利⽤用されるEVPNと連携することで、クラウド・DC内のL2NWとの⾃自動接続の実現
DC内のNWの変更更をリアルタイムにFDBに反映可能

Controller
auto provisioning

Cloud/DCVXLAN over IP

WAN
Ethenet over MPLS

EVPN-VXLAN

EVPN-MPLS

Copyright © NTT Communications Corporation. All right reserved.

EVPN実⽤用に向けた課題n 実装状況• 各社の実装範囲にも差異異があり、⽐比較が難しい状況
ü

EVPNのみ、PBB-‐‑‒EVPNのみn トラフィックエンジニアリングに係る機能は現状では未定義• 期待する機能üü

•

PBRに相当するような経路路変更更BGPによる経路路制御（Local  Preference等）

並⾏行行してサービスとしてどこまでが求められるのか？については検討が必要n C-‐‑‒plane負荷の評価が必要• 網内経路路数、BGP  update頻度度の⼤大幅増üü

MACアドレス単位でのBGP  update
実網にどのような影響を与えるのか検証が必要

n D-‐‑‒planeの正常性を確認するためのOAM機能の整備• Ether-‐‑‒OAMよりも簡易易な実現⽅方式が望ましく、EVPN向けLSP-‐‑‒Pingの標準化に期待

Copyright © NTT Communications Corporation. All right reserved.

まとめn MPLS上へのサービスNWの集約によるCAPEX/OPEX削減のため、L2VPNをより効果的に集約する技術として、EVPNを評価
n VPLS等既存のL2VPN技術の弱点を補う各種機能への期待は⾼高く、実装の出揃いが待たれる
n 商⽤用環境への導⼊入においては、トラフィックエンジニアリング機能やOAMを具備し、さらに新たなサービスの実現にも貢献することが望まれる

Copyright © NTT Communications Corporation. All right reserved.

ご清聴ありがとうございました

Copyright © NTT Communications Corporation. All right reserved.

10