ししおさん:YANGの構成: ・RFC 7233 ・ツリー構造に →Container、List、Leaf ・RWとROの明確な区別 #janog
2015-07-16 14:13:34ししおさん: ・YANGは拡張性が高い。外部モジュールで定義されたスキーマを組み込むことができる。 ・rangeにより範囲を指定し、設定値を制限することができる ・choice #janog
2015-07-16 14:15:00ししおさん:YANGの特徴まとめ: ・テキストでわかりやすい ・設定データと運用データの区別が明確 ・階層化構造 ・namespaceの活用による拡張性 #janog
2015-07-16 14:16:06ししおさん:YANGの活用性: ・CLI/MIB/独自XMLをYANGで記述 ・YANG→XMLに変更するYIN:Yang-Independent Notation ・RESTConfのためのJSON/HTML変換も可能 #janog
2015-07-16 14:22:27ししおさん:YANG Governamce Model: ・IETF:プロトコルごとに定義 ・IEEE ・OpenConfig:Googleが主導しているようなもの →オペレータが、必要な部分だけ、という視点で #janog
2015-07-16 14:24:47ししおさん:相互接続試験: ・IETF NETCONF Interop Test →IETF85での相互接続試験 ・NETCONF and YANG Interoperability Test →EANTCでのNETCONF1.1およびYANGの相互接続試験 #janog
2015-07-16 14:26:27ししおさん:Tail-f NCSの例: ・抽象化モデルが重要です ・プロトコル全体ではなく、必要部分のみをサービスモデルとして定義 →IPアドレス、AS番号、リンクなどは、ベンダーに依存しない #janog
2015-07-16 14:28:51・依存する部分は、ベンダーごとにYANGモデルを定義 →箱が一緒,YANGモデルが定義できることがメリットに #janog
2015-07-16 14:28:53ししおさん:ConfDの例: ・ConfDはNW機器と共存させることで、外部とはNETCONFで管理が可能 ・内部ではYANGモデルで管理し、OSとはAPIでやりとりする ・ベーシック版はフリーで提供 →Quaggaで netconfd を動かして、というデモが #janog
2015-07-16 14:30:53ししおさん:まとめ: ・NETCONF1.1の実装が進んできた ・現時点でRFC 6022は必須機能といえる →get-schema ・YANGデータモデルは既存のCLI/MIB/XMLスキーマからのコンバートがしやすい #janog
2015-07-16 14:32:16・YANGデータモデルよりRESTConfに必要なJSONなどのフォーマットへの加工もしやすい #janog
2015-07-16 14:32:17たいじさん:NETCONFとYANG、期待して待っているのですが、今、ベンダーさんは、NETCONFはほとんどのベンダーで実装されていて、YANGはしていないところも。実装に時間がかかると思っていて、NETCONFとYANGで、 #janog
2015-07-16 14:33:54ししおさん:僕も、勉強した時に、こんなことを言ってもな、とは思ったのですが、我々の実装状況を見ていると、CLIからYANGモデル化するのは割と簡単みたいです。割と短い期間で開発をやっているようです。XMLのスキーマを出しているところも、 #janog
2015-07-16 14:35:04そこから抜き取ってYANGモデルにしているので、一気に出来ています。やりやすいという印象です。 #janog
2015-07-16 14:35:05川上さん:まだ、YANGを使うまでには達していませんが。運用とか自動化を考えると、サービスごとに情報を持つことに。その時のデータベースの作り方として、YANGを意識したデータベースにした方がいいのかな、とも思ったり。でも、どのくらいでできるかな?というのが見えて #janog
2015-07-16 14:36:48