inSPire は、シスコがサービス プロバイダー向けに厳選した、シスコの高度な技術と最新のニュースをお届けするニュースマガジンです。

ネットワーク変革の源泉となるオープン コミュニティ
Cisco EPN イノベーション セミナー セッション概要

2015年 11 月、東京ミッドタウンにおいて「Cisco EPN イノベーション セミナー」が開催された。今回のメイン テーマはオープン コミュニティ。イノベーションを実現する最新テクノロジーの動向が、シスコも積極的に関与するオープン コミュニティの活動を軸として紹介されたのである。ここではセミナーで行われた 3 つのセッションと、日本のネットワーク業界をリードするパネリストが参加した 2 つのパネルディスカッションの概要を紹介する。

基調講演
オープン イノベーションと IETF
フレッド・ベイカー (Fred Baker)
Cisco Fellow, Engineering, CTAO

 このセッションでは IETF(Internet Engineering Task Force)における標準化の話をします。標準というのは合意です。IETF の活動の本質は、この合意を作り上げるため、問題を議論、検討し、ソリューションにしていくことにあります。その過程では RFC(Request For Comment)を含む様々なドキュメントが書かれますが、IETF は RFC を書くためのコミュニティではなく、目的はあくまでも問題解決策の提示です。

 いくつかの例を挙げると、理解しやすいかもしれません。まず一例として挙げたいのが SSH です。SSH はフィンランドの開発者である Tatu Ylonen 氏が自分自身のために、1995 年初頭に開発したものです。これを知人にも提供し、同年 7 月にはオープンソースとして公開、同年 11 月にドラフトが書かれますが、最終的に RFC にはなりませんでした。その後彼は SSH の改善とサポートのために会社を立ち上げ、IETF でも SSH のためのワーキング グループが発足します。その結果、RFC 2693 や 4251 - 4254 が書かれ、SSH2 が広く使われるようになりました。標準化にはトップダウン型とボトムアップ型がありますが、これはボトムアップ型の一例です。

 John Nagle 氏の TCP Nagle アルゴリズムも興味深いケースです。彼は 1980 年代に TCP/IP の QoS に関する問題を予見し、それを解決するアルゴリズムを考案、そこから TCP Congestion Control に関する様々な RFC が生まれています。ここで注目していただきたいのは、たった 1 つの問題提起から、標準化につながる多様な議論が生まれたことです。

 3 つ目に挙げたいのは、IPv6 のマルチホーム問題です。IPv6 ではサービス プロバイダーが利用者に対して IPv6 プリフィックスを割り当て、ブロードバンド ルータがそのアドレス範囲の中から、配下の機器に IPv6 アドレスを自動的に割り当てます。ルータが複数のサービス プロバイダーに接続されている場合には、状況によってサービス プロバイダーが割り当てた範囲外のソース アドレスが選択され、サービス プロバイダーがセキュリティ確保のため、そのパケットをドロップすることがあります。この解決策については IETF で長い間議論が行われており、推奨策も提示されていますが、IPv6 のルーティング等の振る舞いに関しては、現在も複数のワーキング グループで議論、検討が進められています。この議論には競合となる複数のベンダーと、通信事業者等のユーザも参加しています。

 それでは IETF とは、どのような組織なのでしょうか。セオリーと実際とを比較しながらお話しましょう。まずはセオリーです。組織構造はこのようになっています。

 IETF は IESG(Internet Engineering Steering Group) の下にあり、ここには複数のワーキング グループがあります。私もその中の 1 つの議長を勤めています。ワーキング グループは 125 ありますが、シスコはこのうち 80 のワーキング グループと関わっており、非常に積極的にドラフトを提出しています。ワーキング グループ間のコラボレーションも、驚くべきレベルで行われています。

 ワーキング グループでの取り組みは、常に解決すべき問題の明確化から始まります。解決に向けた議論は公開されており、メーリング リストや Web サイトで発信されています。このプロセスの中で様々な提案が生まれ、これらの取捨選択や融合等を行い、関係者の合意を取っていきます。

 当初の IETF には理念が存在しませんでしたが、1992 年に MIT 教授の David Clark 氏が「Rough Consensus and Running Code」という発言を行い、これが IETF の理念になっています。その意味は、政治的な要素を排除し、機能するソリューションを追求するということです。

 ワーキング グループが選択した提案は、RFC にするよう IESG に申請され、承認されると RFC になります。RFC の内容は新たな標準であるケースもありますし、既存の標準に対するアップデートや、現在使われているソリューション、あるいはすでに使われなくなったソリューションのケースもあります。RFC とはコミュニティのアーカイブです。良いことも悪いことも、記録すべきことが RFC として残されるのです。

 次に私の IETF における 26 年間の個人的な経験にもとづき、IETF の現実についてお話します。

 IETF のプロセスは、参加者の良心、判断力、計画力、一貫した参加意識等に依存しています。しかし必ずしもこれらが保証されるわけではありません。問題が発生した場合には議論を行います。IETF のサイトにはその議論の記録も残っています。

 IETF は公式な組織ではなく、単なる「人の集まり」に過ぎません。「Old Boy Network(参加の敷居が高い排他的な集団)」と言われることもありますが、これは誤解です。古くから参加している人もいれば、新しい人もいます。ここで重要なのは、解決すべき問題をきちんと理解し、その解決に向けて建設的な協力を行うことです。このような人が最終的に、大きな発言力を持って貢献することになるのです。

ネットワーク変革の源泉となるオープン コミュニティ
Cisco EPN イノベーション セミナー セッション概要

バックナンバー
Issue 22(2016年1月) Issue 21(2015年10月) Issue 20(2015年6月)Issue 19(2015年4月) Issue 18(2015年1月)Issue 17(2014年5月) Issue 16(2014年7月)Issue 15(2014年5月) Issue 14(2014年1月) Issue 13(2013年10月) Issue 12(2013年7月) Issue 11(2013年5月) Issue 10(2013年1月) Issue 09(2012年11月) Issue 08(2012年7月) Issue 07(2012年5月) Issue 06(2012年2月) Issue 05(2011年11月) Issue 04(2011年7月) Issue 03(2011年5月) 2011春の特別号(2011年3月) Issue 02(2011年2月) 創刊号(2010年10月) 創刊準備号(2010年7月)