IETF 99 (プラハ) 報告会
RTG Area トピックス

2017/9/1
栃尾 祐治(富士通研究所)
IETF 99報告会 (2017/9/1)

[RTG Area]現在の構成
Area Directors: Alvaro Retana, Alia Atlas, Deborah Brungard

 BABEL BESS
 BFD
 BIER CCAMP DETNET I2RS
 IDR

 ISIS
 L2TPEXT LISP
 MANET MPLS NVO3
 OSPF PALS

青: 今回参加、黒: 時間があえば参加、
斜体: 関与薄、灰色: 今回未開催

 PCE
 PIM
 ROLL RTGWG
 SFC
 SIDR SPRING TEAS TRILL

参考https://trac.ietf.org/trac/rtg/wiki/IETF99summary
2

IETF 92報告会 (2015/04/24)

今回の報告事項
RTG中心に出席した最近の話題を紹介
 MPLS WG などにみる最近のMPLS
MPLS over UDP with SR
 RTG WG (, SPRING WG) も含む
 さらに DC routing & VPN+ も含む

 DetNet WG
Encapsulation, Security…
 Psuedowire control word に関わる問題
• 一部PALS WGにも関連

 IDEAS (BoF)

Identifier vs Identity
 LISP and HIP 参考までに、先週から話題(!?)のBGPを扱うIDRの状況は…


Route Leak Prevention, BGP Tunnel attributes , FlowSpec(rfc5575bis)の継続議論
BGP extended communityでのcongestion status 定義、LLDP peer discovery の議論が中心のようで、例の件でMLが盛り上がった形跡もなし…

3

IETF 99報告会 (2017/9/1)

先に OPS Area すこしだけ…
 NETCONF/YANG(NETMOD)
 NETCONF/YANGに関しての大きな進展は、前回合意された

NMDA/Datastore更新(operationalサポート)に伴うYANG更新が中心• draft-ietf-netmod-revised-datastores• 前回報告した、Old Train  Train 1/2 の件
 YANG pushのソリューションの進展は思ったほどなし他:• Yang-mount ドラフトがカムバック• Notification for UDP(TCP)について議論(反応そこそこあり)

 ANIMA
 基本となるプロトコル(GRASPなど)はかなり熟したので今後について議論
 professionally-managedをベースにしたネットワーク自動構築技術を検討するというコンセプト中、(1) 現在のANI (Autonomic Networking
Infrastructure) をてこ入れする、(2) ANIをさらに拡張する (3) ASA(Autonomic Service Agent)を掘り下げるという3案が示された

 SUPA, LIME, L2SM
 開催されず…
4

IETF 99報告会 (2017/9/1)

MPLS WG
(RTGWG含む)

5

IETF 99報告会 (2017/9/1)

はじめに(または前回の振り返り) ここ(MPLS WG)で話す内容は、前回IETF98報告会での宮坂さん
パートの続きとなります。

https://www.isoc.jp/wiki.cgi?file=20170512%5Fietf98%2Dupdate%5FTakuyaMiyasaka%2Epdf&page=IETF98Update&action=ATTACH
6

IETF 99報告会 (2017/9/1)

MPLS WG Unified Source Routing Instruction using MPLS Label Stack (再掲)
draft-xu-mpls-unified-source-routing-instruction
 MPLS Segment routing(SR)ならびにMPLS over UDP (RFC7510)の組み合わせ
で、IP SRとの相互接続を実現し、Unified Source Routing 実現するもの
 adj-SIDによるSRも可能であることを明記すると共に、overlay でも TE ができることをアピール

https://datatracker.ietf.org/meeting/99/materials/slides-99-mpls-sessa-02draft-xu-mpls-unified-source-routing-instruction-ietf99



応用例としてService Chaining への適用(右)• draft-xu-mpls-service-chaining
7

IETF 99報告会 (2017/9/1)

MPLS WG A Unified Approach to IP Segment Routingdraft-bryant-mpls-unified-ip-sr

 いっそのこと(?)、 IPv6 + MPLS によるUnified Segment Routing Protocolを定義してしまおうという提案。このことによりMPLS SR over IPv6を実現
IPv6網ではSR capable でもnon capable でも転送可能
 すでに J 社系では展開中?
https://datatracker.ietf.org/meeting/99/materials/slides-99-mpls-sessb-07-draft-bryant-mpls-unified-ip-sr

8

IETF 99報告会 (2017/9/1)

VPN+
 Enhanced Virtual Private Networks (VPN+) draft-bryant-rtgwg-enhanced-vpn

 Segment routing + IP & MPLS underlay
 SID を多彩に組み合わせることで Isolation を提供し柔軟なVPNを構築可能
 SRの制御/設定(instruction)にて、TEないしはLatency supportも可能

https://datatracker.ietf.org/meeting/99/materials/slide
s-99-rtgwg-sessb-enhanced-virtual-networks-vpn

9

IETF 99報告会 (2017/9/1)

Routing in the DC
 VPN+ の話が出たところで RTG WGで進めているData centerにおけるルーティング拡張の今後について
 IETF 100 にて BoF を開催


ML: https://www.ietf.org/mailman/listinfo/dcrouting この場で、Problem statement と solution を検討する 1st stepとする予定
 以前開催されなかったSCALE BoF(VPN拡張)の二の舞にならないこと祈りつつ..

 参考までにこまで議論された主なドラフト draft-keyupate-idr-bgp-spf
 draft-shen-isis-spine-leaf-ext
 draft-przygienda-rift draft-sl-rtgwg-far-dcn

10

IETF 99報告会 (2017/9/1)

DETNET WG

11

IETF 99報告会 (2017/9/1)

DetNet WG とは Deterministic Networking
L2, L3 networkにおいて、低遅延、低ジッタ(delay variation)を実現するためのネット
ワーキングを検討• 5G networking の要求沿ったネットワーク検討とも
 IEEE 802.1 TSN (Time sensitive networking) と連携
 IETFのWGなのでL3観点(IP, MPLS)で検討

 現在の状況

ユースケースならびにアーキテクチャは WG I-Dにて検討• draft-ietf-detnet-use-cases• draft-ietf-detnet-architecture

目下の話題はEncapsulation(draft-dt-detnet-dp-sol)• 2段構えのWG adaptation(問題を修正し合意→WG ID poll)も

今回の会合ではSecurity関連(draft-sdt-detnet-security)も議論• WG I-Dになる見込み

 個人的に思う課題

Data plane(Encapsulation)は、おおよその解決はついたと思われるが、DetNet でめざすNetworkのキモである低遅延、低ジッタ、同期について、IETFとしてどれだけ
contributeできるのかまだ議論の余地も(つまりIEEE802.1 TSNにかなり依存)
12

IETF 99報告会 (2017/9/1)

DetNet Encapsulation (draft-dt-detnet-dp-sol) これまでの検討では、IEEE802.1TSN over DetNet 、ならびに、PW(Peusdowire)-based DetNetをusecaseとして想定
 いずれにしてもDetNet service にはMPLS/PWを適用する前提
IEEE802.1TSNとは(参考/個人見解)：http://www.ieee802.org/1/pages/tsn.html••

IEEE802.1における主に低遅延伝送特性を定義する Task group
特に積極的に活動している項目はBounded low latency 規定
•
•
•
•
•

•

Credit Based Shaper (.1Qat)
Frame Preemption (.3br & .1Qbu)
Scheduled Traffic (.1Qbv)
Cyclic Queueing &Forwarding(.1QCh)
Asynchronous Traffic
Shaping(.1Qcr)

並びに、Reliability 実現に以下検討••

Frame Replication & Elimination(.1CB),Per Stream Filtering and Policing(.1Qci)https://datatracker.ietf.org/meeting/99/materials/slides-99-detnet-detnet-data-plane-encapsulation

13

•
•

他 Time & Sync, Resource mgmt を検討
参考: IETF99向けTutorial
IETF 99報告会 (2017/9/1)

DetNet Encapsulation
 MPLS/PW での Encapsulation は、RFC 3985 (PWE3 architecture) 課題は”DetNet Control Word(CW)”. Ethernet CW (RFC 4448) を想定しているが、Ethernet CW は option. たとえ使用したとしても、内部に定義の16 bit Sequence
Number もまたoption なので、実際に使用する場合に問題が発生するとの懸念が…
DetNet では冗長提供(packet by packetで提供)のためSequence Number の使用を想定
 なお、今回の PALS WG では、Option だった Ethernet CW をマンダトリにしようという提案があり RFC 4448 が更新される可能性が大 (当初問題でないと思っていた 0x4, 0x6 で始まる
non IＰ packetへの対応として)


14

IETF 99報告会 (2017/9/1)

DetNet Encapsulation
 今回の会合(正しくはdraft-dt-detnet-dp-sol-01)にてnative IPv6 の追加


よさげに見えるが、IPv6 は PWサポートがないので、これまた懸念も…

15

IETF 99報告会 (2017/9/1)

DetNet Security Consideration
 draft-sdt-detnet-security
 Attacker type (RFC7364)に応じて要素を分析の上、impact/mitigationを考察+-----------------------------------------+----+----+----+----+| Attack|
Attacker Type||+---------+---------+||Internal |External |||MITM|Inj.|MITM|Inj.|+-----------------------------------------+----+----+----+----+|Delay attack
| + |
| + |
|
+-----------------------------------------+----+----+----+----+|DetNet Flow Modification or Spoofing| + | + |||+-----------------------------------------+----+----+----+----+|Inter-segment Attack| + | + |||+-----------------------------------------+----+----+----+----+|Replication: Increased Attack Surface| + | + | + | + |+-----------------------------------------+----+----+----+----+|Replication-related Header Manipulation | + ||||+-----------------------------------------+----+----+----+----+|Path Manipulation| + | + |||+-----------------------------------------+----+----+----+----+|Path Choice: Increased Attack Surface| + | + | + | + |+-----------------------------------------+----+----+----+----+|Control or Signaling Packet Modification | + ||||+-----------------------------------------+----+----+----+----+|Control or Signaling Packet Injection
|
| + |
|
|
+-----------------------------------------+----+----+----+----+|Reconnaissance
| + |
| + |
|
+-----------------------------------------+----+----+----+----+|Attacks on Time Sync Mechanisms| + | + | + | + |+-----------------------------------------+----+----+----+----+

16+----------------------+---------------------+---------------------+| Attack|
Impact|Mitigations|+----------------------+---------------------+---------------------+|Delay Attack|-Non-deterministic|-Path redundancy||| delay|-Performance|||-Data disruption| analytics|||-Increased resource |||| consumption||+----------------------+---------------------+---------------------+|DetNet Flow Modificat-|-Increased resource |-Path redundancy||ion or Spoofing| consumption|-Integrity protection|||-Data disruption|-DetNet Node|||
| authentication|+----------------------+---------------------+---------------------+|Inter-Segment Attack |-Increased resource |-Path redundancy||| consumption|-Performance|||-Data disruption| analytics|+----------------------+---------------------+---------------------+|Replication: Increased|-All impacts of other|-Integrity protection||attack surface| attacks|-DetNet Node|||
| authentication|+----------------------+---------------------+---------------------+|Replication-related|-Non-deterministic|-Integrity protection||Header Manipulation| delay|-DetNet Node|||-Data disruption| authentication|+----------------------+---------------------+---------------------+|Path Manipulation|-Enabler for other|-Control message||| attacks| protection|+----------------------+---------------------+---------------------+|Path Choice: Increased|-All impacts of other|-Control message||Attack Surface| attacks| protection|+----------------------+---------------------+---------------------+|Control or Signaling |-Increased resource |-Control message||Packet Modification| consumption| protection|||-Non-deterministic|||| delay||||-Data disruption||+----------------------+---------------------+---------------------+|Control or Signaling |-Increased resource |-Control message||Packet Injection| consumption| protection|||-Non-deterministic|||| delay||||-Data disruption||+----------------------+---------------------+---------------------+|Reconnaissance|-Enabler for other|-Encryption||| attacks||+----------------------+---------------------+---------------------+|Attacks on Time Sync |-Non-deterministic|-Path redundancy||Mechanisms| delay|-Control message|||-Increased resource | protection||| consumption|-Performance|||-Data disruption| analytics|+----------------------+---------------------+---------------------+IETF 99報告会 (2017/9/1)

IDEAS BOF

17

IETF 99報告会 (2017/9/1)

IDEAS BoF
 IDentity EnAbled networkS
前回はSide meeting。今回はBoFになっての議論。RTG area配下での開催。
 前からも紹介された、Generic Identity Service (GRIDS)を導入するための基本的な課題の明確化と既存WGとの課題を明確した内容
 ポイントとしては、LISPで、Entityに対してIdentifier(とlocator)の定義を導入したが、Identifier (Idf)のライフタイムをどう考えるかを突き止めると、Identity (who)という概念が必要でそのIdentityとIdentifier(where)間でライフタイム管理を行うことで、Idfを意味あるものかつプライバシーを考慮しつつ管理を行い、IDベースのサービス提供を行う枠組みを規定ISP以外にもすでにHIP (Host Identity Protocol) WGでなんとかな
るのではという紹介もあり(認証が重くDiscoveryが課題らしい)

https://datatracker.ietf.org/me
eting/99/materials/slides-99ideas-ideas-problemstatement

18

IETF 99報告会 (2017/9/1)

IDEAS 目指すものまたは実現したいもの – GRIDS

Identity(who)
Encrypted

Identifier(where)Service by GRIDS

19

IETF 99報告会 (2017/9/1)

IDEAS (proposed charter) Network solutions based on the concept of Identifier-Locator separation are
increasingly considered to support mobility and multi-homing acrossheterogeneous access networks. Identifier-locator separation protocols
require infrastructure that allows nodes to discover the network topologicallocation(s) of its peer(s) for packet delivery.
 However,additional infrastructure and new protocol extensions are neededto address new requirements that go well beyond the traditional discovery
service and mapping of identifier-to-location for packet delivery.
 In addition,identity-enabled networks introduce the concept of identityidentifier split. <…> Examples of the problem space are:Privacy: <…>The endpoint communications should be able to change their identifier while
retainingtheir identity and associated policies.<…> Access control :<…>Therefore, it is desirable to have a certain degree of control over who
canlook up the identifier-locator binding information for example.
 Common infrastructure and Primitives: The application of common and consistent basic
networking policies that can apply at the level of entity reduces operational complexity
associated with managing services for individual endpoints.<…>

20

IETF 99報告会 (2017/9/1)

IDEAS 所感※あくまで個人の見解なので今後の展開はMLなどを参照のこと
https://www.ietf.org/mailman/listinfo/ideas IDf(Identifier)の定義を明確にしないと発散しかねない？
LISP の延長としているが、解釈次第ではどうでも拡大できるかも draft-padma-ideas-req-gridsを読んでも明確に落とせない IDy(Identity)とは実は新手のSDN controller定義?
draft-padma-ideas-req-grids には以下の記載あり
Identity-Enabled Networks are enabled by a set of core services that areprovided by common control infrastructure 他WGとの重複は?
Dataplane: NVO3やSFC との違いは?
• Charter議論で、 Identity and Identifier だけでなく identifier 間interactionを考えるべきという声も Netconf/Restconf (NETCONF/NETCONF)との違いは？
• Identifier と Data model(metadata)に共通点


21

IETF 99報告会 (2017/9/1)

まとめ

22

IETF 99報告会 (2017/9/1)

まとめ
RTG中心に最近の話題を紹介
 MPLS WG などにみる最近のMPLSの動向
 RTG WGも含む• さらにDC routing & VPN+ も含む

 DetNet WG
 PALS WG も含む
 Encapsulation, Security…

 IDEAS (BoF) ID based network の新たな形の模索？

 折に触れて紹介したとおり、IP(v6) と MPLS のこれからの付き合い方について変化が生じているようなドラフトがいくつか見られ、今後のNetworking(Dataplane構成)にも影響がでるかもしれない、というのが今回の所感

23

IETF 99報告会 (2017/9/1)

ありがとうございました

IETF 99報告会 (2017/9/1)