IETF 93 (Prague) 報告会

RTG, OPS に見る
ネットワーク制御・管理技術動向(YANGなど…)

2015/8/27
栃尾 祐治(富士通研究所)
IETF 93報告会 (2015/8/27)

はじめに – 自己紹介
n IETF 72 (Dublin, 2008/07) から参加
きっかけは、MPLS-TP の議論の開始 (PWE3, L2VPNなども含む)
n 関わった RFC, I-D (名前があるもの)• RFC 5654: MPLS-TP 要求• RFC 5860: MPLS-TP OAM 要求• RFC 6371: MPLS-TP OAM フレームワーク• RFC 7271: MPLS-TP Linear Protection (ITU-T APS対応)• draft-bhh-mpls-tp-oam-y1731
nn どちらかというと、ITU-T SG15 で標準化活動していますn

担当しているEditor (下線部がMPLS-TP関連)• G.806, G.8112, G.8121 series, G,8151, G.8013/Y.1731

n 最近は、伝送網の制御・管理技術という観点で出席n

MPLSの他、CCAMP, TEAS, PCE, NETMOD, LIME, SDNRG…
n このあたりで Contribute しています• draft-txh-lime-gap-analysis• draft-lam-lime-summary-l0-l2-layer-independent• draft-tissa-lime-yang-oam-model• draft-lam-teas-usage-info-model-net-topology• draft-mansfield-netmod-uml-to-yang
2

IETF 93報告会 (2015/8/27)

はじめに – IETF に おけるSDNn IRTF (SDDRG) で以下の RFC を発行
n RFC 7426 - Software-Defined Networking (SDN): Layers andArchitecture Terminology

http://www.ietf.org/proceedings/88/slides/slides-88-sdnrg-5.pdfn

この中で、ネットワーク制御としてInfo Model/Data Modelの定義が重要に• 更に、SNMP MIB à Netconf/YANG シフトの勧告のため YANG 祭りに• https://www.ietf.org/iesg/statement/writable-mib-module.html

n

加えて、SDNRG などで明確になってきた次の課題(キーワード)• Security, Policy, Scale-out, Resiliency …
3

IETF 93報告会 (2015/8/27)

今回の報告事項
ネットワークの制御・管理技術動向について、RTG・OPA中心に、最近の話題を紹介します
n ネットワークの制御・管理技術動向(1) – 今後のトレンド?
n Security: I2NSF (Bof) (SEC)n Policy: SUPA (BoF), ANIMA (OPS)n ネットワークの制御・管理技術動向(2) – Data model (YANG)
n 関連 WG の動向• OPS Area: NETMOD, LIME
• RTG Area: RTGWG, TEAS, I2RS

4

IETF 93報告会 (2015/8/27)

ネットワークの制御・管理技術動向(1)– 今後のトレンド?

5

IETF 93報告会 (2015/8/27)

[I2NSF](Bof)n Interface to Network Security Functionsn

前々回(IETF 91)にBoF を開催し、前回(IETF 92)はBits-n-Bitesでデモ

n SDN/NFV環境下におけるセキュリティ規定とインタフェースを定める
n すでに5, 6月の中間会合(電話会議)を経て、use case, charter をまとめるとともに、今回BoFに向け、Problem statement, Frameworkを準備するという流れを決定済み
n 簡単に記すと、SDN controller をより secure にするために、Security controllerを規定し、controller と既存NSFの Interface を定めるという流れになる
n さらにNSFの設定、制御などをFlow-based (packet based) で実現することまでを想定
nOpen source で提供あり

n 会場の反応、今後の対応
Flow based でのソリューションへの懸念がいくつかあがったが、支持も大きいためWGとしての成立しそうな感じ
n 他、DOTSとの関係n

6

IETF 93報告会 (2015/8/27)

[I2NSF](Bof)n Problem statement

https://www.ietf.org/proceedings/93/slides/slides-93-i2nsf-2.pdf

7

IETF 93報告会 (2015/8/27)

[I2NSF](Bof)n draft-merged-i2nsf-framework-02
n

基本構成

n

Cluster 対応

Client/AppGW|| Client Facing Interface+-----+---------------+|Service Provider mgmt|+-------------+| Security Controller | < -------- > | Vendor|+---------------------+ Vendor Facing| Sys||
Interface +-------------+|| NSF Facing Interface|+------------------------------------------------+||||+------++------++------++------++ NSF-1+ ------- + NSF-n++NSF-1 + ----- +NSF-m + . . .
+------++------++------++------+
Vendor A
Vendor B+------------------------+| Security Controller|+------------------------+^^||+-----------++------------+||vv+ - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +| NSF-A +--------------+| | NSF-B +--------------+|||Sub Controller|| ||sub Controller|||+--------------+| |+--------------+|| + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + || |+---------++---------+| | | |+---------++---------+| || || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| || |+---------++---------+| | | |+---------++---------+| || |NSF-A cluster| | | |
NSF-B cluster| || + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |+ - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +8https://www.ietf.org/proceedings/93/slides/slides-93-i2nsf-4.pdf など

IETF 93報告会 (2015/8/27)

[Supa](BoF)
n Simplified Use of Policy Abstractions (SUPA)n

Policy Driven (Based) Service Management: PBSMに関して議論、2度目のBoF開催
n 標準化されたPolicyに基づくネットワークの管理手法ならびにそのモデル化

n Charter (Proposed) では以下を規定
nGeneric policy information model (GPIM)• YANG (Data model) だけでなく Information model も対象とする

n“event-condition-action” によるpolicy rule だけでなく、実現すべきものを明確にする
policy rule いわゆる Intent based policy rule も対象

n 今回の議論項目
n

Information model, Data modeln Charter discussionn 他標準化団体・WGとの関係
n Use case (example)

n 会場の反応と次回に向けた対応
nService model, Intent定義で、I2RS, ANIMAとの関係について懸念する意見あり
n WG設立に向けた、Poll (Hum)では、設立に対して懸念 or 反対する声も強く(賛成と同じ程度)、この先は？
9

IETF 93報告会 (2015/8/27)

[Supa](BoF) Use casen VPC (Virtual private cloud)n VM 管理、VPC でのconnection 形成 (OverlayかつFlexible)
n Virtual SP Traffic Enginneringn

DC 間接続のおけるトンネル制御

n VPN 自動生成

https://www.ietf.org/proceedings/93/slides/slides-93-supa-5.pdf
10

IETF 93報告会 (2015/8/27)

[Supa](BoF)
n Framework

https://www.ietf.org/proceedings/93/slides/slides-93-supa-1.pdf

11

IETF 93報告会 (2015/8/27)

[Supa](BoF) GPIMn Data Model の統合

12

IETF 93報告会 (2015/8/27)

[Supa](BoF) GPIM と Data model 等の関係
n Supa Environment

https://www.ietf.org/proceedings/93/slides/slides-93-supa-4.pdf
13

IETF 93報告会 (2015/8/27)

[ANIMA] WG についてn Autonomic Networking Integrated Model and Approachn

SDNの発想と逆を行くWG(但し、SDNとは補間とする)•

RFC 7575: Autonomic Networking: Definitions and Design Goals を実現する WG とも

目玉は、Generic Signaling (DiscoveryとNegotiation) “GRASP”
n Discovery, Negotiation の他にReference Model & Control Planeも議論• Reference Model 文書(draft-behringer-anima-reference-model)では、ACP(Autonomic Control Plane) のモデルがAPI, Agent含め検討(右図)• ACP(draft-behringer-anima-autonomic-control-plane)ではSelf-managing overlay を実現するための機能 (Self-creating/managing/healing/optimiding/protecting)を検討中(右下)n

https://www.ietf.org/proceedings/93/slides/slides-93-anima-4.pdf
https://www.ietf.org/proceedings/93/slides/slides-93-anima-5.pdf
14

IETF 93報告会 (2015/8/27)

[ANIMA] 今回のトピックス
n Intent (An abstract, high level policy used to operate the network [RFC 7575])
n draft-du-anima-an-intent
draft-liu-anima-intent-distributionnIntent 配布も考慮してUniform format 検討やGRASPを拡張提案したが、SUPAとの調整があるためサスペンド

n Using Autonomic Control Plane for Stable Connectivity of Network OAM
ndraft-eckert-anima-stable-connectivity
n AMIMA (CP) にOAMを導入するための検討で、既存 NOC (network operation
controller)を実現するか
n 特に OAM により DP に変更を加える
場合に注目し、どのようにDPのモニタするか検討をはじめた文書 (ITU-T G.7712
DCN の改良とも)• Inband or out-of-band?
n

IPv6 source routing を解に検討?

https://www.ietf.org/proceedings/93/slides/slides-93-anima-10.pdf

15

IETF 93報告会 (2015/8/27)

ネットワークの制御・管理技術動向(2)– DATA MODEL (YANG)

16

IETF 93報告会 (2015/8/27)

Information Model/Data Modeln そもそも Information model (IM) と Data model (DM)とはn RFC 3444 “On the Difference between Information Models and Data Models”n

IM – Conceptual/Abstract model• specify relationships between objects• model managed objects at a conceptual level, independent of any specificimplementations or protocols used to transport the data.

n

DM – Concrete/Detailed model• define managed objects at a lower level of abstraction. They include implementationand protocol-specific details, e.g. rules that explain how to map managed objects
onto lower-level protocol constructs.

n DM は IETFではYANGが主流に。ほか、IEEE, MEFでもYANG model検討。
n しかし IM もまた重要IM を進めている WG: I2RS (RIB info model 検討)
n IMを進めている SDO: ITU-T, ONF, TMF, MEF…
n ご参考• draft-lam-teas-usage-info-model-net-topology• draft-betts-netmod-framework-data-schema-uml• draft-mansfield-netmod-uml-to-yangn

17

IETF 93報告会 (2015/8/27)

[NETMOD] YANG
n YANG (RFC 6020)
nData modeling languageを規定• RFC6087にてガイドラインを規定

n

NETCONFのクライアントとサーバーとの間のAPIを詳細に記述。またNETCONF XML 表記と互換あり。
n YANG の基本構成 (Data modeling 構成)••••

Leaf Nodes
Leaf-List Nodes
Container Nodes
List Nodes
1 list に複数の Leaf を定義することで Configuration data のみならず State Data の定義可能

nTree 構成として簡素化した表記も定義 (RFC 6087bis)n

開発環境としては pyang などが存在• code.google.com/p/pyang•

18

IETF 93報告会 (2015/8/27)

[NETMOD] YANG 状況
n YANG RFCs
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø

n 現在進行中のドラフト(YANGモデル関連)
ØRFC 6020 (YANG)
RFC 6021à6991 (YANG types)
RFC 6087 (YANG usage)
RFC 6110 (Mapping YANG to DSDL)RFC 6244 (Netmod/YANG アーキ)
RFC 6643 (SMIv2 to YANG)
RFC 7223 (YANG for Interface管理)
RFC 7224 (YANG IF type (IANA))
RFC 7277 (YANG IP 管理)
RFC 7317 (YANGシステム管理)
RFC 7407 (YANG SNMP設定)

Ø draft-bogdanovic-netmod-acl-modelØ

SYSLOG YANG modelØ draft-asechoud-netmod-diffserv-modelØCore Routing Data modelØ draft-ietf-netmod-routing-cfg

ØDiffserv
Ø draft-asechoud-netmod-diffserv-modelØPeer Mount (controller – device間
YANGのinterconnect)
Ø draft-voit-netmod-peer-mountrequirements, draft-clemm-netmodmount など

n 現在進行中の主なドラフト(YANG言語関

Ø

連)
Ø

YANG 1.1 - draft-ietf-netmod-rfc6020bis
Ø Guideline更新 - draft-ietf-netmod-

Ø

rfc6087bis
ØNetwork Access Control List Model

YANG model classification
Ø draft-bogdanovic-netmod-yang-modelclassification-01
Operational State Data,
Operational Structure and Organization
Ø draft-openconfig-netmod-{opstate, modelstructure}

YANG to JSON - draft-ietf-netmod-yangjson
Ø

UMLàYANGØ draft-mansfield-netmod-uml-to-yang

19

IETF 93報告会 (2015/8/27)

YANG in RTG Arean YANG (RFC 6020)がData model記述上でIETF公用語化されたことで、RTGの至るWGでYANGに関してのドラフトが大量発生
n RTG Areaでも重複回避のために以下のWiki, MLを創設
n

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoordn rtg-yang-coord@ietf.org

n RTGの中で核となる(であろう)ベースドラフトは以下の通り
nCore Routing (Generic)• draft-ietf-netmod-routing-cfg (NETMOD and RTGWG)
OSPF, ISIS, BGPなどプロトコルSpecificは各WG管理

nTopology• draft-liu-yang-abstract-te-topo (TEAS) or draft-clemm-i2rs-yang-network-topo (I2RS)
I2RSではL1, L2, L3 topoの文書が別途存在nOAM• draft-tissa-lime-yang-oam-model (LIME (OPSArea))
但し、MPLS, BFDなどプロトコル依存なものは各WGで進めることになるが、双方間でOverlapもあり
NVO3, SFC(, TRILL)などサービス規定なアプローチからのYANG文書も存在する

n

他、VPN などサービス設定のもの、プロトコル設定などが存在するが、全体にまだまだ交通整
理が必要

20

IETF 93報告会 (2015/8/27)

各 RTG area でのYANGドラフト
n RTGWGn draft-li-rtgwg-tunnel-policy-yangn draft-acee-rtg-yang-key-chainn draft-chen-rtgwg-key-table-yangn draft-wu-rtgwg-flowspec-cfg
n draft-liu-rtgwg-yang-vrrp
n draft-liu-rtgwg-yang-rip
n draft-chen-rtgwg-qos-yangn BESS & PALS (L2VPN), L3SM (OPS),n draft-zhuang-pals-l2vpn-yangn draft-tsingh-bess-pbb-evpn-yang-cfg
n draft-l3vpn-service-yangn draft-zhuang-bess-l3vpn-yang (n SFC, LISP, NVO3n draft-penno-sfc-yangn draft-ermagan-lisp-yangn draft-zhang-nvo3-yang-active-activecfg
n draft-zhang-nvo3-yang-cfg

n ISIS, OSPF, IDR (BGP)nnnn

draft-ietf-isis-yang-isis-cfg
draft-ietf-ospf-yang
draft-shaikh-idr-bgp-model &draft-zhdankin-idr-bgp-cfg
draft-wu-idr-flowspec-yang-cfg

n BFD
n

draft-zheng-bfd-yangn SPRING
nndraft-hu-spring-yang
draft-litkowski-spring-sr-yangn CCAMP, PCEnnn

draft-dharini-netmod-g-698-2-yang-02
draft-pkd-pce-pcep-yang
draft-lee-ccamp-wson-yangn TRILLn draft-ietf-trill-yangn draft-ietf-trill-yang-pm
n BIERndraft-chh-bier-bier-yangn MPLS, TEAS, I2RS は後述
拾い切れていない可能性もあり…
21

IETF 93報告会 (2015/8/27)

RTGWG における YANG 状況
n RTGWG (Routing Area WG) はそもそも、Routing 一般を扱う WG で最近のメ
イントピック一つは、IPFRR (Fast Reroute)関連
n 今回会合では、以下の２ドラフトが特に注目が集まった
n draft-shaikh-rtgwg-policy-modeln

openconfig (北米のキャリア・SP連合)のRouting policy一般化ドラフト

https://www.ietf.org/proceedings/
93/slides/slides-93-rtgwg-0.pdf

n draft-rtgyangdt-rtgwg-device-modeln

Design TeamによるYANG構造の一般化ドラフト• draft-openconfig-netmod-{model-structure, opstate} を意識し、より内容を深めたもの• 今後、VPN を中心とした Networking 設定に関する YANG に影響大。詳細次ページ
22

IETF 93報告会 (2015/8/27)

RTGWG における YANG 状況
n draft-rtgyangdt-rtgwg-device-modeln

Device (Physical or VM) を Root にした構造。配下に Interface (RFC 7223) コンテナを定義+--rw device+--rw info
| +--rw device-type?
enumeration+--rw hardware+--rw interfaces| +--rw interface* [name]|...
+--rw qos+--rw logical-network-elements• Logical-network-elements (ドメイン)には、例えばnetworking instance (VRF/VSI相当)を定義
networking instanceには、OAM, Control plane, policyなどが定義される+--rw device+--rw logical-network-elements+--rw logical-network-element* [network-element-id]+--rw network-element-id
uint8+--rw network-element-name?
string+--rw default-networking-instance-name?
string+--rw system-management| ...
+--rw ietf-acl+--rw ietf-key-chain+--rw networking-instances
| ...
•
23

IETF 93報告会 (2015/8/27)

RTGWG における YANG 状況
n draft-rtgyangdt-rtgwg-device-model (続き)n

さらに、Device-viewの制御に応じて、 logical-network-element の制御を行い view
= true であればそのlogical-network-elementは、full device view を見ることが可能になるように検討中

https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf

24

IETF 93報告会 (2015/8/27)

[TEAS] WGについて
n TEAS: Traffic Engineering Architecture and Signalingn 2014年12月に正式に設立。(実質はCCAMPからの分離)
n 他WGとの関連は以下の通り。 実質はCCAMPで分離する形• TEASTE Architecture
Generic protocol work for TE
Oversight and coordination of TE protocol work

• CCAMP
Protocols for non-packet data planes
LMP• MPLS
Protocols for MPLS-TE (including MPLS-TP)
All other MPLS work as normal• PCE
Coordination with TEAS on TE architecture involving PCE
All PCE work as currently

25

IETF 93報告会 (2015/8/27)

[I2RS] WGについて
n Interface to The Internet Routing Systemn

めざすもの: Application とRouting (routing system) との間のインタフェース(Configurationor management interfaces) 規定を定め、Applicationに対して柔軟にRouting システムが動作させるような、フレームワークとプロトコルを規定• 現在、NETCONF を拡張(pubsub対応)する方向で検討中

n

特にRIB のモデル化が大きな課題

www.olddog.co.uk/IIR-SDN-Farrel.ppt (IRS は I2RS に修正)

26

IETF 93報告会 (2015/8/27)

TEASにおける YANG 検討
n 議論紹介された I-D (*はMPLSでも紹介)n

参考： MPLS関連のI-D
n draft-chen-mpls-ldp-yang-cfg
n draft-chen-mpls-te-yang-cfg
n draft-gandhi-mpls-te-yang-modeln draft-zhang-mpls-tp-yang-oam

draft-ietf-teas-yang-te-topon draft-saad-teas-yang-te
n draft-saad-teas-yang-rsvp*
n draft-openconfig-mpls-consolidated-model*
n draft-zhang-mpls-lspdb-yang*n あと、IM として draft-lam-teas-usage-info-model-net-topology

n MPLS, RSVP(-TE) に関しては前回紹介したので割愛
nhttp://www.isoc.jp/wiki.cgi?action=ATTACH&file=isocjp%5Fietf92%5Frtg%2Epdf&page=IETF92Updaten 上記以外の話題(課題)として以下のものがあり
nTopology における他 WG (I2RS)との重複検討の解決• draft-ietf-i2rs-yang-network-topo ならびに関連 Topology ドラフトとの調整
draft-clemm-i2rs-yang-l3-topodraft-ietf-i2rs-l2-network-topology
draft-hares-i2rs-info-model-service-topo, draft-wang-i2rs-yang-service-topo-dm
draft-zhang-i2rs-l1-topo-yang-model-01n

IM と DM の関わりについて

27

IETF 93報告会 (2015/8/27)

TEASにおける Topology YANG 検討
module: ietf-te-topology+--rw te-topologies| +--rw topology* [te-topology-id」| | +--rw node* [te-node-id]| | | +--rw te-node-id
te-node-id| | | +--rw te-node-template?
leafref| | | +--rw te-node-attributes| | |+--rw schedules* [schedule-id]
| |
.....
| | |
+--rw underlay-topology?
leafref {tetopology-hierarchy}?
| | |+--rw te-link* [te-link-id]| | || +--rw te-link-id
te-link-id
| | |
.....
| | |
+--rw connectivity-matrix* [id]| | || +--rw id
uint32| | || +--rw from-link
| | |
.....
| | |
| +--rw to-link
| | |
.....
| | |
+--rw ted:.....
| +--rw node-template* [name]|.....
| | +--rw te-node-attributes| |+--rw underlay-topology?
leafref {tetopology-hierarchy}?
:| +--rw link-template* [name]+--ro te-topologies-state:+--ro topology* [te-topology-id]+--ro node* [te-node-id]| +--ro te-node-attributes| | +--ro underlay-topology?
leafref {tetopology-hierarchy}?
:+--ro link* [source-te-node-id source-te-link-id
dest-te-node-id dest-te-link-id]| +--ro is-abstract?
boolean| +--ro underlay! {te-topology-hierarchy}?

n draft-ietf-teas-yang-te-topo
Technology Agonistic な TE
Topology モデルを YANG にて記載したドラフトn ハイレベルに記載すると、Topology
をRootに，Node 属性, TE-link,
matrix を定義
n さらに、マルチレイヤに向けトポロジ
ー抽象化 (ドラフトでは、TE
Topology as a Serviceと銘打っている) も考慮した、
Overlay/Underlay に関するモデルかも含まれるn さらに、現在のドラフトではconfiguration data と operational
state data それぞれを定義しているn

28

IETF 93報告会 (2015/8/27)

I2RS における Topology YANG 検討
n Topology IM/DM• draft-medved-i2rs-topology-im (Expired)• draft-ietf-i2rs-yang-network-topo

https://www.ietf.org/proceedings/93/slides/slides-93-i2rs-1.pdf

module: network-topology+--rw network-topology+--rw topology [topology-id]+--rw topology-id
topology-id+--ro server-provided?
boolean+--rw topology-types+--rw underlay-topology [topology-ref]| +--rw topology-ref
topology-ref+--rw node [node-id]| +--rw node-id
node-id| +--rw supporting-node [node-ref]| | +--rw node-refnode-ref| +--rw termination-point [tp-id]|+--rw tp-id
tp-id|+--ro tp-ref*tp-ref+--rw link [link-id]+--rw link-id
link-id+--rw source| +--rw source-node
node-ref| +--rw source-tp?
tp-ref+--rw destination| +--rw dest-node
node-ref| +--rw dest-tp?
tp-ref+--rw supporting-link [link-ref]+--rw link-reflink-ref29

IETF 93報告会 (2015/8/27)

Topology YANG: TEAS and I2RS
n I2RS における ドラフト体系
•
•
•
•
•
•

draft-ietf-i2rs-yang-network-topodraft-clemm-i2rs-yang-l3-topodraft-ietf-i2rs-l2-network-topology
draft-hares-i2rs-info-model-service-topodraft-wang-i2rs-yang-service-topo-dm
draft-zhang-i2rs-l1-topo-yang-model-01

n TEAS (draft-ietf-teas-yang-te-topo) と,I2RS 間で特別にセッション実施 (7/20 20:00-)
n おおよその合意：

https://www.ietf.org/proceedings/93/slides/slides-93-i2rs-1.pdf (一部加筆)

I2RS は Service Topology のためのモデル化、TEAS は TE Topology
n TE Topology model は、I2RS Topology model をaugment (つまり I2RS をベース)
n L1(/L0) Topology (I2RS) は、TE Topology Model をaugment する形n• à CCAMP へ引越しも検討n

一方、L2, L3 Topologies は、TE Topology Model をaugment は不要•

厳密に言うと、L2 は微妙なのだけど…つまり、Router (L3) 屋と 伝送装置(L0-L2)屋でのtopology モデルの考え方が異なってくる

30

IETF 93報告会 (2015/8/27)

[LIME] WGについて
n Layer Independent OAM Management in the Multi-Layer Environmentn

第91回会合(ハワイ) OPS Area 配下でのWGとして形成

n 目的は、OAM機能(IP, MPLS(-TP), Ethernet, TRILL…)をgeneric (layer independent)にData model (YANG)で定義してOAM管理を簡素化すること (IM は考慮してない)n

注：OAM (Operations, Administration, and Maintenance)とは、IP でいう BFD とか LSPping, ippm にあたる, 障害管理またはパフォーマンス管理(損失、遅延)を提供する機能のこと

n 既存のドラフト
n
n
n
n
n
n

draft-tissa-lime-yang-oam-modeldraft-wang-lime-yang-pm
draft-wang-lime-rpc-yang-oam-management
draft-zhuang-lime-yang-oam-model-applicability
draft-txh-lime-gap-analysis
draft-lam-lime-summary-l0-l2-layer-independentn 当面の課題
Layer independent の妥当性。特に L0-L2 と L3以上でindependent にできるか
n IM なくして DMを進めることの正当性。これも L0-L2 と L3以上でギャップあり (draft-lam)n 他WGで進めるOAM関連のFrameworkとYANG 文書 (NVO3, SFC, TRILL, MPLS)nn

他団体で平行して進めている、YANG 文書との関わり。特に Ethernet (IEEE, MEF)
31

IETF 93報告会 (2015/8/27)

[LIME] Problem statement (@IETF91)
n draft-edprop-opsawg-multi-layer-oam-ps (Problem statement), Expiredn Lacking common architectural OAM management が課題のひとつであり、そのためマルチレイヤの Layer independent の必要性を示している

http://www.ietf.org/proceedings/91/
slides/slides-91-lime-4.pdf

n

しかし Ethernet OAM は、Layering の導入により実現しているが…
Customerequipment
1• MEG(MD), MEL(MA), MEP, MIP, …
[IEEE802.1 or ITU-T G.8013/Y.1731]

2

Operator A
bridges3

Operator B
bridges
4

5

6

7

8

Customerequipment
9

Ca1a

ETH

IPa

Pa1a
Oa1a

IPb

IOa

Ob1a
Ob2a

Ob2b

ETHor
SRV

(G.8013 Appendix IIの図II.1)

G.8013-Y.1731(11)_FII-1

32

IETF 93報告会 (2015/8/27)

[LIME] Generic OAM YANG
rpcs:

n draft-tissa-lime-yang-oam-modeln Overview
n Ietf-gen-oam module では、アーキテクチャ規定
を行い、rpc (Remote Procedure Call) で個別機能を拡張定義 (MEP から augment)
n Notification も規定されてはいる
module: ietf-gen-oam+--rw domains+--rw domain* [technology MD-name-string]+--rw technology
identityref+--rw MD-name-string
MD-name-string+--rw MD-name-format?
identityref+--rw (MD-name)?
| +--:(MD-name-null)|+--rw MD-name-null?
empty+--rw md-level?
MD-level+--rw MAs+--rw MA* [MA-name-string]:+--rw MEP* [mep-name]| +--rw mep-name
MEP-name| +--rw (MEP-ID)?
: :| +--rw priority?
uint8| +--rw session* [session-cookie]: ::+--rw MIP* [interface]| +--rw interface
if:interface-ref+--rw related-oam-layer* [offset]
33+---x continuity-check| +--ro input: : :| +--ro output::+---x continuity-verification| +--ro input: : :| +--ro output::+---x path-discovery| +--ro input: : :| +--ro output::+---x Loss-measurement (to added?)::+---x delay-measurement (to added?)::
notifications:+---n defect-condition-notification+--ro technology+--ro MD-name-string+--ro MA-name-string?
+--ro mep-name?
+--ro defect-type?
+--ro generating-mepid:+--ro (error)?
+--:(error-null)| +--ro error-null?
+--:(error-code)+--ro error-code?
+--ro error-code?
IETF 93報告会 (2015/8/27)

[TEAS], [NETMOD] IM に関してのドラフト
n ここまで(前スライド)は Data Model の話であるが、ここからは Information model の話
n draft-lam-teas-usage-info-model-net-topologyn

ITU-T and/or ONF (Open Networking Foundation ) で進めてきた Core information model の I-D 化••n

ITU-T G.7711 “Generic protocol-neutral information model for transport resources”
ONF TR-512 “Core information model”

この先、ONF で進める Topology IM と、Topology YAMG (draft-liu-teas-yang-te-topo-00) とで整合性をとりながら、進めていきたい旨を宣告
34

IETF 93報告会 (2015/8/27)

[TEAS], [NETMOD] IM に関してのドラフト
n draft-mansfield-netmod-uml-to-yangnGuidelines for Translation of UML Information Model to YANG Data Modeln これもONF で活動中の文書で、タイトル通り、IM(UML)àDM(YANG)変換のガイド文書の I-D
化 (Informational RFC化を目指したもの)

35

IETF 93報告会 (2015/8/27)

まとめに代えてn IETF 93 報告として、RTG・OPS中心にの最近の話題を紹介
n ネットワークの制御・管理技術動向(1) – 今後のトレンド?
n Security: I2NSF (Bof) (SEC)n Policy: SUPA (BoF), ANIMA (OPS)n ネットワークの制御・管理技術動向(2) – Data model (YANG)
n 関連 WG の動向• OPS Area: NETMOD, LIME
• RTG Area: RTGWG, TEAS, I2RS

36

IETF 93報告会 (2015/8/27)

ありがとうございました

IETF 93報告会 (2015/8/27)

37