第1回JPIRR BoF 議事録  [次第1-5]

■本議事録について
  - 開催概要、次第は別途公開しています
  - 次第6-7についての議事録は別途公開しています
  - 質疑応答ではJPNIC関係者および発表者の発言のみ、発言者を明記してい
    ます。発言者の記名が無いものは参加者からの発言となります

--------------------------------------------------------------------------
【１】開会のご挨拶 
近藤邦昭(JPNIC IRR企画策定専門家チーム/株式会社インテック・ネットコア) 
--------------------------------------------------------------------------

　+ JPNICでIRRの研究会を初めてから約２年が経過する。JPNICの中でIRRの専
　　門家チームを作って、日本でIRR を今後どのようにしていけばよいかにつ
　　いて、検討を加えてきた。

　+ 実験サービスはすでに始めている。このサービスをどのようにして来年度
　　以降につなげていけばよいかについて、来年５月末ぐらいまでに、専門家
　　チームとしてもある程度の結果を出して、来年度につなげていくことを考
　　えなければならない。

　+ 来年以降も含めて、今後、よりよいサービスを提供できるように皆さんと
　　意見を交換して、その意見を取り入れてうまくやっていこうということで、
　　今回のBoFを開催した。

　+ ２時間の枠の中で、いろいろなご意見をいただいて、次につなげていきた
　　いと考えている。ぜひご意見をたくさんいただければと思う。



--------------------------------------------------------------------------
【２】JPIRR Update 
吉田友哉(JPNIC IRR企画策定専門家チーム/NTTコミュニケーションズ株式会社) 
--------------------------------------------------------------------------
　+ 資料に基づき、現在のJPIRRの説明と企画策定専門家チームの活動紹介を行った

[質疑応答]
    特になし



--------------------------------------------------------------------------
【３】JPIRRに関する統計情報のご紹介 
長橋賢吾(JPNIC IRR企画策定専門家チーム/東京大学大学院) 
--------------------------------------------------------------------------
　+ 資料に基づき、JPIRRに関する現在の統計情報の報告を行った

[質疑応答]
Q:登録率の説明で、歴史的な経緯を持つ割り振りブロックと/28～/32のアドレ
　スブロックに関しては、参考になる情報ではないということだったが、その
　理由を教えて欲しい。

A:歴史的な経緯を持つ割り振りブロックには、下記のような背景がある。

　　- 歴史的な経緯を持つ割り振りブロックをIRR で検索してみると、1995年
　　　や1997年といった比較的古い情報が登録されている。

　　- /8単位で割り振り/割り当てを受けていても、実際のBGPのルーティング
　　　テーブルでは、細かくスプリットした単位(例:/14)で経路が登録されて
　　　いる。これらを集計すると、Best Match が多くなり、Exact Matchが少
　　　なくなる傾向にある。

　　- 歴史的な経緯を持つ割り振りブロックのPrefix数自体は少ない。

  つまり、/24単位では５万～６万程度のPrefix が登録されているのに対して、
  /8単位ではPrefix数が非常に少ない。単純に比較しただけではパーセンテー
  ジとして意味合いが変わってしまう、と考えたので、参考になる情報ではな
  い、という説明を行った(IRR企画策定専門家チーム 長橋)

Q:統計情報的に母集団が少ないので誤差が大きいと考えてよいか。

A:そのように考えてよい(長橋)

A:歴史的な経緯を持つ割り振りブロックと/28～/32のアドレスブロックについ
　ては、この部分がどれだけの意味を持つか、我々でも議論を行った。以下が
　その議論の結論である。(IRR企画策定専門家チーム 近藤)

    - 両者は母数が余りにも違っていて、しかも、/8 と/24では実際のインタ
　　　ーネットの運用方法が違うのではないという点もある。なので、CIDR以降
　　　の、レジストリから割り振られ、管理が行き届いているアドレスブロック
　　　について検討を進めている。

    - RIRから割り振るようになったのは、CIDRが導入された頃である。

    - RIRから割り振られるものは、Prefix Length が長くて/15 か/14程度で
      あるので、/15か/14から短いものに関しては意味がないのではなく、デ
      ータの一つ一つを細かく調べないと、その実態がわからないのではない
　　　か、という結論になった。


Q:実際にIRRを利用してフィルタする際に、長いPrefix Lengthと短いPrefix 
  Lengthをフィルタしなくて良いという結論を言ったのか、単に統計上の問題
  であり、運用上は全てフィルタをかけなければいけない、と言っているのか
  がわからない。

A:単に統計上の問題である。実際の運用ではフィルタをかけないと、フラッ
  プするなど問題である。(近藤)


Q:Best match/Exact Matchと言っているのは、IRRのデータベースの中にエン
　トリがあるということなのか。あるいは、IRRのデータベースからデータを
　抽出してpathを生成しうるという意味なのか。

A:前者の意味で用いている。単純にデータベースにおけるオブジェクトの有無
　で判断している。(IRR企画策定専門家チーム 吉田)


Q:Exact Match の概念はよく理解できるし、実際の運用に利用しているISP も
　ある。しかしながら、Best Matchの概念があまりわからない。分析上は便利
  な概念かもしれないが、実用上どのように役に立つマッチングと考えている
  か。

A:/16を/17*2として経路広告している場合、Exact Matchでは無視されるが、
  Best Matchではカウントされ、/16に対するcoverage が上がるという利点が
  あると思われる。(長橋)

Q:実際にはISP が分割して経路情報を流すということもあるのだが、分割する
  のはルーティングポリシを変えたいときであると考えている。
　specificなルーティングポリシはあまりよくわからない、というのが正解で
  はないか。

A:運用上の話にフォーカスされているが、一度フィルタをかけた経験があった。
  当時はIRR への登録率が良くなかったので、フィルタリングされてしまって
  全部落ちてしまい、Exact Match は使えないという経験があった。
　　突発的にアドレスブロックを分割して、longer Prefix を経路広告して、
  そちらに吸い込んでもらうという運用がしたい時には、相手にExact Match 
  をやめてもらうように連絡しなければいけない。
　　つまり、運用上ではExact Matchは非常に強力でよいのだが、Best Match 
  を許さないと運用が厳しくなる、と考えている。(近藤)

Q:私たちが運用しているのネットワークの上流は、厳格なExact Match しか受
  け入れないポリシである。

A:そのようなケースもあるので、ASの運用ポリシに依存してくる可能性もある。
  (近藤)


Q:AS 番号については同様な統計はないのか。BGPの経路表を比べたときに、デ
  ータベースに登録されている情報と合致するかどうかについては調査してい
  ないのか。

A:OriginASに関しては調査していないが、今後調査する予定である。(長橋)



Q:登録されている情報が正しくないと思われるいわゆる"ごみオブジェクト"が
  増えていく問題に対してはどのように取り組んでいるのか。JPIRR に限らず
  RADBなどではどのように対応しているのか。

A:RADBにもごみオブジェクト問題があると聞いている。実例としては、以下の
　ようなものがあげられる。

    - 実際に経路広告しているものより短いPrefix Length を登録する
    - /16を登録していて、予備として/17*2をさらに登録する

　運用上、登録しているので、管理者からは不要かどうか判断できない。JPIRR
　は運用を開始してから新しいので、ごみ問題に対しては特に取り組んでいない。
　RADBは、ごみ問題に対しても何らかのアクションをすると言っている。(近藤)

A:RADBでは先月ぐらいから、個々のASに対して実際に広告されている経路とデータ
　ベースに登録されている経路の差分を公開するようなサービスを始めた。また、
　sprintでは、経路が広告された段階で、いきなり登録されるような話を聞いてい
　る。(吉田)



--------------------------------------------------------------------------
【４】IRRとルートサーバによる経路情報確認 
川上隆行(日本インターネットエクスチェンジ株式会社(JPIX)) 
--------------------------------------------------------------------------
　+ 資料に基づき、プレゼンテーションを行った

[質疑応答]
Q:データベースのソースはどこから持ってきているのか。

A:例えば、RIPEなどのRADBがミラーをしている先のデータベースは、ほとんど
　持ってきている。RADBのデータベースとRADB以外のデータベースを比較する
　ことによって、データベースの登録内容に重複があった際などには、検出で
　きるような仕組みにしている。(JPIX 川上)


Q:データが分散してしまっているのでかき集めている、という認識でよいか。

A:その認識でよい。また、不要と思われるオブジェクトは消してもらっている。
　上流のISP に対して削除を依頼する等ができるとよいのでは、と考えている。
　(川上)



--------------------------------------------------------------------------
【５】IRR企画策定専門家チームの研究・調査のご報告 
長橋賢吾(JPNIC IRR企画策定専門家チーム/東京大学大学院)
衛藤将史(JPNIC IRR企画策定専門家チーム/奈良先端科学技術大学院大学) 
--------------------------------------------------------------------------
　+ 資料に基づき、IRR企画策定専門家チームの研究調活動の報告を行った

[質疑応答]

Q:IRRにデータを登録する立場からすると、as-in/outの登録には力を入れてい
  ない。ピアリングしている相手側ASのaut-num オブジェクトでさえも登録さ
  れていないという客観的状況もあるが、そもそも as-in/outを登録するモチ
  ベーションがあまりない。

  prefixとas-macroについては、登録を行ってきちんとメンテナンスをすると
  いうモチベーションはある。それに対して、どのASの経路を受け取るかやど
  のASの経路をアナウンスするかについての情報は、参考情報として我々は提
  供しているが、きちんとメンテナンスをするモチベーションはない。

A:ポリシの登録は自由であり、メンテナの間でRtConfigを利用して、ルータの
　設定が自動化できれば楽になるのではないかと考えている。ピアリング間で
　設定の約束がある場合は、この方法が利用できるではないだろうか。義務で
　あるとはいえないが、普及すればよいのでは、と考えている。
　(IRR企画策定専門家チーム 衛藤)


Q:RPSL自体は非常に高い理想を持っていろんな機能が組み込まれているのだが。

A:ASオブジェクトを見てみると、ほとんどのインポートポリシがANY だが、こ
　のチェッカーを利用するとANYは acceptされる。そういう意味では不整合は
　ないと見えてくる。 ANYと書くか詳細に記入するかは運用上の問題ではない
　だろうか。(IRR企画策定専門家チーム 近藤)

Q:RPSLの表現能力を厳密に評価をしたことはないが、RPSL でas-in/outのポリ
　シを 100％表現することはできないと思っていて、その思いが、登録するモ
　チベーションを下げている要因になっていると考えているのだが。

A:基本的にRPSLで表現しようとすると、かなり高度なことを表現できると考え
　ているが、そのためだけに技術者を一人雇えるぐらい難しいので、そこまで
　厳密に行うモチベーションはISPにはないとは思う。(近藤)

(コメントとして)
C:ビジネスサイドで考えると、中規模以上のISP では、ルーティングポリシが
　ピアリングの交渉と絡んでくるようなケースもある。誰が顧客で、誰に対し
　てどのような経路を広告しているか、という話にもなるので、そのような人
　達は、as-in/ outの登録を積極的にやりたくない気持ちになると思う。

C:as-in/out を登録することは、現実のインターネットではうまくワークしな
  いのではないか、と懐疑的な見方をしている。prefixは、インターネットの
  運用の保全上、非常に重要であると考えていて、皆さんがprefixを何とかし
  たいと考えている。考えているが、手を回せていない状況となっている。
--------------------------------------------------------------------------

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上