今回のIETF(第66回)は少しためらっていたのだが、結局いくつか社内、社外を含めてミーティングをすることになったので（社内であっても、開発メンバーが各国、各地域に分散しているため、一堂に会してface to face meetingをするには、実際非常によい機会だったりする）、参加してきた。
少し前までは、インターネット技術の標準化の現場を目の当たりにし、雰囲気を肌で感じ、また既にその分野で「大物」になっている人と、意見を交わしたりするだけで、大感動であった。マイクに立って質問やコメントをすることができた時（言葉の壁もさることながら、的をはずしたり空気を読んでいなかったりすると、黙殺されたり、高圧的な反応をされたりするので結構怖いのだ）、素直に、嬉しかった。
でも今はちょっと違った感覚を持っている。
IETFにおける標準化の主な参加主体は、開発者、研究者、そして実際に技術を展開、運用し、サーヴィスを提供するSP/ISPの設計・運用者である。それぞれに期待役割がある。しかし、私はメーカーに在籍しているものの、今は実際にコードを書いている訳ではなくて、顧客(SP/ISP)に近いConsulting Engineerという立場にある。立ち位置が多少微妙なので、よほどしっかりした考えを持っていないと、何のために何をやっているのがわからなくなる。顧客の声を代弁しているのか。メーカーとしての意見なのか。技術者としての個人的な興味なのか。
また、Routing Areaにおけるある種の行き詰まりを感じている、ということもある。IP技術のState of Artの一つはRoutingだ。それぞれのノードがRouting情報をやりとりし合い、自律分散的に動作する。しかしその根本原理である最短経路発見アルゴリズムなどはとうの昔に完成しており（Dijkstra, Bellmanford)、今議論されているのは、付加機能のための拡張機能である。付加機能には、QoSやSecurityを実現するためのもの、MPLSや各種Overlay技術、Domain/Area分割のように階層化や抽象化を実現するためのもの、新サーヴィスのためのシグナリング、マルチキャストの拡張等、山ほどの事項がある。そして、それが複数のレイヤにて繰り返される。さらに、それら機能拡張の結果必要になるコンポーネントのための"discovery"や"最適化"、そして"管理運用"機能が必要になり...、とどんどん機能要求が膨れ上がる。でも、それらが「何のために」必要か、というところを突き詰めるとどうか。いろいろ考え、またいろいろな方のご意見を聞くと、要するに、"Transport"、"Path"が欲しい、ということに収斂されるのではないか、と思えてきた。
求められているのは"Routing"でなく"Path"なのではないか。品質管理可能な"Path"。拡張性の高い"Path"。このきわめてシンプルな要求に対して、山ほどの機能てんこ盛りで解決しようとしているところに違和感があるのかな。
コメント