MPLS Japan 2015
ネットワークモデル化の議論から見た SDN/NFV“YANG 祭の傍らで”2015/11/9
栃尾 祐治(富士通研究所)
tochio<at>jp.fujitsu.com

MPLS Japan 2015

最初に: 祭りの号令
Writable MIB Module IESG Statementn https://www.ietf.org/iesg/statement/writable-mib-module.html

March 2, 2014
The IESG is aware of discussions in the OPS area and in a number of working
groups about the current practice for standards-based approaches toconfiguration. The OPS area has shown strong support for the use of
NETCONF/YANG while many working groups continue to specify MIB
modules for this purpose. The IESG wishes to clarify this situation with thisstatement:l IETF working groups are therefore encouraged to use the
NETCONF/YANG standards for configuration, especially in new charters.
l SNMP MIB modules creating and modifying configuration state should only
be produced by working groups in cases of clear utility and consensus to
use SNMP write operations for configuration, and in consultation with the
OPS ADs/MIB doctors.

2

MPLS Japan 2015

確かに…
n SDN時代において、NETCONF/YANGの重要性は高まっている
n RFC 7426
n Open Daylight•https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:MD-SAL_Document_Review:MD_SAL

n ではこの先、あらゆるネットワークをYANG記述すればいいのか?

→そうでもないです＞特に伝送網レイヤ(L0, L1, L2)
3

MPLS Japan 2015

本日お話しすること
n 各標準化団体におけるネットワークモデルに関する議論
n IETF YANG 関連進捗と課題
n IETF 94 進捗少しだけ含む(かも)n 紹介する YANG トピックス• Device model• OAM• Topology
n IETF での Information model 議論

n ITU-T/ONF
n ITU-T と ONF - 複雑な関係
n Information model そして…

n 伝送網レイヤにおける課題
n ケーススタディ
n 課題

n まとめ
4

MPLS Japan 2015

Information Model/Data Modeln そもそも Information model (IM) と Data model (DM)とはn RFC 3444 “On the Difference between Information Models and Data Models”
n IM• specify relationships between objects• model managed objects at a conceptual level, independent of any specificimplementations or protocols used to transport the data.
n DM• define managed objects at a lower level of abstraction. They include
implementation- and protocol-specific details, e.g. rules that explain how to
map managed objects onto lower-level protocol constructs.

n DM はIETFではYANGが主流に。しかし IM を抑えることが重要で、これが、SDO 間での覇権争いにIM|+----------+---------+
|
|
|
DM
DM
DM

--> conceptual/abstract modelfor designers and operators--> concrete/detailed model
for implementors
5

MPLS Japan 2015

各標準化団体での活動状況(一言で)n IETFn 管理プロトコル規定として NETCONF/YANG – Data Model (DM)規定n SNMP MIB の新規開発はしない、これからは NETCONF/YANGに移行す

る IESG の勧告により、YANG 祭りが始まる• NETCONFはNETCONF WGで、YANG 定義は NETMOD WGnYANG に基づく、各拡張定義 (MPLS, Routing, OAM) は、各 WG で
• MPLS, RTGWG, TEAS, CCAMP,…などほとんどの Routing Area で YANG
検討

n IMも一部WGで検討しているが、DMに比べあまり重要性を感じていない?

n ITU-T/ONF
n ITU-T SG15 では、そもそもNE(Network Equipment)の管理を定義• NE 定義: Q10, Q11 / NE 管理：Q14
n それをベースに Information model (IM) を検討し、さらにその結果を ONFと連携して、同調して伝送系のIMを進めている
n その他、ONF で進めている OF-config は NETCONF
n また、ONF では Transport API を進めている。IM をベースに定義する方向
6

MPLS Japan 2015

各標準化団体での活動状況(一言で)n IEEEn 802.1 関連中心に、MIBモジュールの定義を行ってきたが、SNMP (IETF)の影響を受けてか、YANG module定義を行うことにした
n まず、IEEE802.1Q(MAC), IEEE802.1X(Sec)から• IEEE802.1Q はすでにいくつかドラフトとして出ています
n IEEE802.3 (PHY)は IETF とコラボで作業開始 (Design Team形成)

n MEF
n MEFでは、すでに、OAMなどで、YANG moduleの定義を行っている(MEF38, 39)の他、MEF6.2規定のサービスに対してもYANG化の作業を検討中である。
n Information modelにおいても、MEF 7.2 と呼ばれる文書を発行中、これらはTMF, ITU-Tとも連携を取った内容になっている

n TMF
n ITU-T/ONF同様、Network Function, Network Resource の IM を検討
n Service Management model も進めていて、IETF SUPA WG とも関連

7

MPLS Japan 2015

YANG
n YANG (RFC 6020) – NETMOD WGnData 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
8

MPLS Japan 2015

[NETMOD] YANG 状況
n NETMOD WG での主な議論
n

YANG1.1(rfc6020bis)に関する議論• Issue list で管理 - http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html• YANG to JSON は 1.1に組み入れることは合意したが、一方で1.0との互換性が課題に• I2RS サポートも今後の課題nRouting, ACL, DiffServといったプロトコル一般なYANG定義• draft-ietf-netmod-routing-cfg, draft-bogdanovic-netmod-acl-model,
draft-asechoud-netmod-diffserv-model
DIffServ をもとに QoS YANG も検討開始予定

nInterface (RFC 7277)のL2拡張• draft-wilton-netmod-intf-ext-yang-00, draft-wilton-netmod-intf-vlan-yang-00

n モデルの明確化• draft-bogdanovic-netmod-yang-model-classification
NE向けYANG, Service向けのYANG等、多岐に渡るYANG modelをどう分類/階層化するか

nOperational State Data
• draft-openconfig-netmod-opstate
NETCONF を作る際に、configuration / operational state data の明確な区別を行うことを要求に盛り込んでいたが実際不十分。State のありかたについて議論n

UML (Info model) à YANG (Data model) [後述]
9MPLS Japan 2015

YANG in RTG Arean YANG が IETF公用語化されたことで、RTG (Routing Area) のあらゆるWGでYANGに関してのドラフトが大量発生。しかも、WG間での重複も大n

例えば MPLS の場合、MPLS WG はもちろん、RSVP-TE 関連で TEAS WG も関与

n RTG Areaでも重複回避のために以下のWiki, MLを創設
n

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

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

• draft-rtgyangdt-rtgwg-device-model• draft-ietf-yang-abstract-te-topo (TEAS)
draft-ietf-i2rs-yang-network-topo (I2RS)n OAM ★

• draft-ietf-lime-yang-oam-model ★ (LIME (OPSArea))• MPLS, BFDなどプロトコル依存なものは各WGで進めることになるが、OAM に関しては、
LIME という WG が進めている
10

MPLS Japan 2015

YANG Device model (-00, IETF93)
n draft-rtgyangdt-rtgwg-device-modeln

Design TeamによるYANG構造の一般化ドラフト• draft-openconfig-netmod-model-structure を意識し、より内容を深めたもの
n 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-elementsnLogical-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
| ...
•
11

MPLS Japan 2015

YANG Device model (-01, IETF94)
n 主な更新箇所 ( https://www.ietf.org/proceedings/94/slides/slides-94-netmod-7.pdf )n Top Level の Device 断念、 Network Device (Module)定義にn

同時に Interface を augment として記載し、Logical Network element Network
instance と柔軟に関連付けられるよう変更

n Logical Network Element: Sub LNE, System management を独立定義

n

これでも表記方法はまだ課題ありと、DT では議論継続中
12

MPLS Japan 2015

OAM for YANG [LIME]n Layer Independent OAM Management in the Multi-Layer Environment
第91回会合(ハワイ) OPS Area 配下でのWGとして形成
n 目的は、OAM機能をgeneric (layer independent)にData model (YANG)で定義してOAM管理を簡素化すること (IM は考慮してない)
n 注：OAM (Operations, Administration, and Maintenance)とは、IP でいう BFD とか LSPping, ippm にあたる, 障害管理またはパフォーマンス管理(損失、遅延)を提供する機能のこと
nn 既存のドラフト
n
n
n
n
n
n

draft-ietf-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 当面の課題nLayer independent の妥当性。特に L0-L2とL3以上で generic にできるか• 実際には、IP, MPLS が。。。

n

IMなくしてDMを進めることの正当性。特に、L0-L2 (@ITU-T, ONF)
n 他WGで進めるOAM関連のFrameworkとYANG 文書(NVO3, SFC, TRILL, MPLS)
他団体で平行して進めている、YANG 文書との関わり。特に Ethernet (IEEE, MEF)
n Notification の定義 (後述)n13MPLS Japan 2015

Generic OAM YANG [YANG]
rpcs:

n draft-ietf-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]
14+---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?
MPLS Japan 2015

Topology YANG [TEAS]n TEAS WG:
nmodule: 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}?

IETF 92 に CCAMP から分離する形で独立。TE を主に扱う

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 それぞれを定義している
n15

MPLS Japan 2015

Topology YANG [I2RS]
n I2RS WG: Application - Routing システム間のインタフェース規定。RIB モデル化など規定
n Topology IM/DMndraft-medved-i2rs-topology-im (Expired)n draft-ietf-i2rs-yang-network-topo
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-ref16

MPLS Japan 2015

Topology YANG: TEAS and I2RS (IETF93)
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 間で特別にセッション実施
n おおよその合意：
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 モデルの考え方が異なってくる?

17

MPLS Japan 2015

でも YAMG (DM) だけじゃないのです。。。
IM も IETF では一部議論されていいます(TEASとかNETMODとか)

18

MPLS Japan 2015

IM に関してのドラフト [TEAS]n draft-lam-teas-usage-info-model-net-topologyn

ITU-T/ONF で進めてきた Core information model の I-D 化• 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) とで整合性をとりながら、進めていきたい旨を宣告
n YANG 変換も考慮 - https://www.ietf.org/proceedings/94/slides/slides-94-teas-6.pdf
n19MPLS Japan 2015

IM に関してのドラフト [NETMOD]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化を目指す)

20

MPLS Japan 2015

ということで、話はITU-T/ONFへ

21

MPLS Japan 2015

ITU-T, ONF での IM 活動 (伝送系)
n ITU-Tn ITU-T SG15 では、NE(Network Equipment)の管理を定義• NE 定義: Q10(Packet(L2)), Q11 (OTN(L1), WDM(L0)) / NE 管理：Q14
n それをベースに Q14 にて Information model (IM) を検討• G.874.1 (OTN(WDM含む)), G.8052 (Ethernet), draft G.8152 (MPLS)

n ONF
n 関連する Area, Projectは以下の通り https://www.opennetworking.org/technical-communities
n Services Area > Information Modeling Project (IMP)• Generic (Protocol neutral) な観点で、IM を推進
n Specification Area > Open Transport project (旧Optical Transport WG)• 伝送系レイヤ (L0, L1, L2) を対象に OpenFlow プロトコル拡張、SDNアーキテ
クチャ、Information Model、更に、Transport API (TAPI) の活動を進めている• IM 観点では、OTN, Ethernet, MPLS 向け IM と TAPI に該当

n 複雑な関係n 実は進めているメンバがほぼ同じ
n ITU-T 勧告はONF 文書は公式に参照できない• ONF の IPR ポリシーが A.5 Justification 上 NG
22

MPLS Japan 2015

G.7711 (G.gim) & ONF TR-512 + 513
Generic Protocol-Neutral Information model for transport resources
n G.7711 とは、当初既存勧告 (ITU-T G.874.1, G.8052,
G.8152)を一般的に扱う勧告と scope されたが、ONFの議論もあり、Network Equipment 管理だけでなく
Network Resource (Element) も含める方向で作成された勧告。2014年から作業開始

Figure 1-1/G.7711(若干修正)

n 同じ時期に、ONF で IMP (Information model project)が発足。G.7711 と同様の内容を議論し、TR512: Core Information Model (CIM) + UML として先行発行(2015/3)
n TR-512 を G.7711として直接インプット/同期 (by 寄書提案) し、G.7711 は 2015/08に正式承認 (http://www.itu.int/rec/T-REC-g.7711)
n G.7711 Scope には、TR-513: CIM overview
がインプットされ、ONF/ITU-T で考えるモデル化の進め方を紹介•更に TR-514: UML Modeling Guideline も取り込み予定

n Common Information model を先に固めてその拡張(Technology specific)を展開のあと、
Data Schema (i.e. YANG) への適用を図る流れ

Figure 1-2/G.7711 or Figure1-1/TR-512
23

MPLS Japan 2015

TR514: UML Modeling Guidelines 1.0
n Figure 4.1: ONF Specification Architecture

24

MPLS Japan 2015

G.7711 (G.gim) & ONF TR-512
LTP, LPn G.874.1 (古くはG.852.2)で定義したCTPならびにTTPと定義した参照ポイントをベースに、レイヤ毎の定義であった、CTP, TTP より一般化し、LTP (LogicalTerminationPoint), LP (LayerProtocol) という、Object class を定義
CP = Connection Point
AP = Access Point
TCP =Termination Connection Point
Layer examples
TTP = Trail Termination Point
CTP = Connection Termination PointLR x = MSLR y = VC4 (flexible) PTP = Physical Termination PointLR z = 140 (flexible) LT = Layer Termination
TPE = Termination Point Encapsulation

ITU-T
Expanded G.805
Representation

CP
LR z

Rationalized Representation

Layeredparameter list
used to capture
per-layer detail

Per-layer detail
captured in LT
entities

TMF(G.805 / G.800 terms)

LT

CP

‘

Semi - flexible
SNC / FR

CP

TPE

ITU
TTP

LT
TMF
CTP

ITU
CTP

LR y
AP

LTP
n

AP

TCP
TCP

LP

TPE
n

AP

ONF

LTP
LP

n

n

AP
Fixed (degenerate)

TCP

LT

SNC / FR

LP

TCP
CP

TPE

LTP

LR x

LR w

AP

AP

TCP

TCP

TMF
PTP

LT

LP

LT = LayerTermination
TPE = Termination Point Encapsulation

ITU-T G.774
TTP /CTP

25

MPLS Japan 2015

G.7711 (G.gim) & ONF TR-512
Core Model 定義

Controller for NEn あらかた言って以下の2団体の文書をマージしたモデル定義
n TR225 ”Logical Resource: Network
Function Model”
n ITU-T G.874.1, G.8052, draftG.8152(OTN, Ethernet, MPLS-TP) の一般化
n LTP, LP (前スライド)n 更に SNC(SubNetworkConnection),
SN (SubNetwork) クラスを、
FD (ForwardingDomain),FC (ForwardingConstruct)と名称変更している。
Connection だけでなく Flowにも対応するためn UML 作成環境は Papyrus(Eclipseプラグイン)

Network
Resource

Linear Protection
26

MPLS Japan 2015

G.7711 & ONF TR-512今後の課題
n FD, Linkクラスからは、TopologicalEntity (Topology Subset) を定義している。この中身詳細については、今後エンハンスする予定である
nn さらに、Termination (LTP) Subsetでは、OAM機能(MEP, MIP, 各ツールのJob
class)をこの先定義する予定。この際に、G.8052定義のMEP (source/sink) class などを見直す予定である。(MEP Refactoring)n 更に、ONF UMLàYANG mapping guideline は TR として近々発行予定nn

すでに、draft-mansfield-netmod-uml-to-yang としても議論
27

MPLS Japan 2015

このあたり踏まえて
伝送網レイヤにおけるモデル化を考える

28

MPLS Japan 2015

伝送系技術をNETCONF/YANGにする手順/あり方
n Interface (ポート) に対しての適用であれば、WDM の例で紹介すると。draft-dharininetmod-g-692-2dwdm-if-yang のような発想で設定・規定はできる
n 但し、Data plane 上の動作が規定された伝送網レイヤ(L0-L2)に、 NETCONF/YANG を目指すなら、Data plane での管理規定を直視してモデル化するべき
n 具体的には、{G.874.1/G.8052/draft G.8152} (or ONF OT IM) à “UMLàYANG変換”の方がより標準動作に即した NETCONF/YANG が実現できる

Figure 1-2/G.7711 or Figure1-1/TR-512の初版図をもとに加筆
29

MPLS Japan 2015

実際に…
n https://datatracker.ietf.org/liaison/1433/
n LS: ITU-T Q14/15

à NETMOD, CCAMP, TEAS, MPLSn LS on protocol-specific data modelling work
We would like to inform you that ITU-T Q14/15 has initiatedwork on protocol-specific data modelling for the managementof transport specific technologies, such as OTN, Carrier
Ethernet and MPLS-TP. These protocol-specific data models
will be developed based on the protocol-neutral UML models
that are specified by Q14/15, including ITU-T G.7711/Y.1702(generic information model), ITU-T G.874.1 for OTN, ITU-T
G.8052/Y.1346 for Carrier Ethernet, and ITU-T G.8152/Y.1375(draft) for MPLS-TP.
During the October 2015 Q14/15 interim meeting, we received acontribution for a YANG data model proposal for Ethernet Ring
Protection (ERP) management.
<…>

30

MPLS Japan 2015

ケーススタディ: draft-dharini-netmod-g-692-2dwdm-if-yangn UMLàYAMGは draft-mansfield-netmod-uml-to-yang (pdf) に紹介されています
YANG (Fig 21 & 22)

ITU-T

Figure 12-8 & 10/G.798

Figure 7-4/G.874.1(抜粋)

UML(Fig 23)

31

MPLS Japan 2015

この先の課題(私見)n 装置視点のモデル化と、ネットワークレベルのモデル化
n

すでに、似た議論は、IETF (YANG) で進行中

n L2 (Ethernet)の議論
IEEE, MEF, ITU-T 進むパラレル議論
n (標準化に従うと)基本は IEEE YANG なる(べきである)が、Service 規定 (à MEF)、OAM と Protection (àITU-T)も関与する
RFC 6244
nn Notification (Netconf) 定義+----------------------------+|Server (device)||+--------------------+ |||configuration | |+----+||---------------| ||YANG|+|| m d state data
| ||mods||+|| e a ---------------| |+----+|| -----> | t t notifications | |+----+||| a a ---------------| |+----+||
operations| ||+--------------------+ |
|
^
|
|
|
|
|
v
|
+------+|+-------------+||| -------------> ||||Client| <rpc>|| NETCONF||| (app)|||engine|||| <------------ |||+------+ <rpc-reply>+-------------+
|
|
/
¥
|
|
/
¥
|
|
/
¥
|
| +--------++---------+|| | config ||system|+ || | data- ||software ||+ || |base ||component||| || +--------++---------+|| ||+---------+| ||+---------+ |+----------------------------+nいい例は、 draft-ietf-lime-yang-oam-modelnconfiguration / operational state data も重要だけどこの先 RFC 5277, RFC 6470 を超えた議論も必要かも
32

MPLS Japan 2015

まとめn SDN/NFV 実現に欠かせないネットワークのモデル化(DM, IM)における標準化団体 での活動を紹介
n IETF YANG 祭りの現状
n ITU-T/ONF の IM 活動の現状

n ネットワーク制御・管理機能設計において これらモデル化の議論がどう関わりまたは課題になるのかを、特に伝送網(L0-L2)の観点から紹介
n 伝えたかったこと：『Data Model (YANG, JSON) も重要ですけど、Information
Model も大事です』『Data plane, Network Architeture を直視(目を背けない)したモデ
ル化も大事です』… 共に面倒なこと多いですけど
33

MPLS Japan 2015

ありがとうございました

MPLS Japan 201534