JANOG - /home/pochi/ChangeLog

■ JANOG 宴会 [JANOG]

新橋に移動。
エロネタに参戦させてもらえることになったのかな。

■ JANOG staff meeting [JANOG]

汐留にて。

Skype が活躍。
Polycom のマイク、やっぱり良いわー。

Polycom Skype 専用ハンズフリースピーカーフォン

■ Internet Week JANOG枠のBoF [JANOG]

やっぱり出席できず。むむぅ。
聞きたかったんだけどなあ。

■ 経路爆発が起こるとなぜ困るのか [computer][JANOG]

http://itpro.nikkeibp.co.jp/article/COLUMN/20061121/254222/

近藤さんのコラム。
つい最近20万経路を超えたわけなんだけど、
経路が溢れるとどうなるか、という話。

- 経路がルータのメモリの上限を超えてしまう
- メモリの上限を超えると、経路情報を受けとれなったり、
  ルータが再起動しちゃうことも。
- 経路フラップが発生

対策は

- ルータの切り替え
- 頑張ってアグリゲート

しかない。

IPv6 は、経路集約に配慮して設計、運用されてるんだけど、
マルチホームがあたりまえ、AS の数も増えまくり、
という現状を見ると IPv6 化されたとしても、
経路爆発は収まらないよなあ。
むしろ悪化する気も。

新ルーティングアーキテクチャが欲しい気も。
インターネットがここまで大きくなってくると、
アーキテクチャ再構築なんていう話は、
実際の実装がないと話にならないわけで、
そういうことができる立場にいるのは、
CISCO、Microsoft、Google、Intel ぐらいかのう。
そのへんで何かやってないのかしら？

■ MEDの落とし穴の相談 [JANOG]

九段下にて。

BGP では、ルータが

- local Preference
- AS Path
- Origin
- MED

これらを上から順番に比較していって、
経路を選択している。
(実際はもうちょっと階層はあるけどね)

ルータエンジニアのお仕事の一つは、
トラフィックをうまくさばくためにこれらの値をうまく調整する、
ということなんだけど、、、、

その調整パラメータの1つである MED は曲者だよねえ、
というお話。

■ 経路情報付きパケットでのルーティングの話 [JANOG][computer]

JANOGの宴会で、イーサネット駄目すぎ、捨てたい!、と言ってたら、
それを言ったら BGP だって、という話になった。

IP の世界では、遠くのノードと通信をしたいときには、
自分が持っている経路表を参照し、近くにあるルータに投げる。
そのパケットを受けとったルータも、それぞれが持っている
経路表を元に隣のルータに渡してやる。
それを繰り返して最終的な目的地までパケットが渡される。
ちゃんと届くためには、経路表がちゃんとしてなきゃいけなくて、
それを正しく保持するための仕組みがルーティングプロトコル。
インターネットにおいては BGP が主に使われている。

ところが、今の BGP には

- 経路情報が膨大になってきた。
  20万経路を超えて、ルータも処理するのが大変。
- ルータを適切に設定してないと、偽経路情報を流されたときに
  経路乗っとり等が発生する可能性がある
- トラフィックコントロールをちゃんとしたいけど、
  意図したようにパケットが流れてくれないことがある

というような問題がある。
そういう問題に対しては、今のところは、
仕様だよねえ、ある程度は我慢して、
でも現状でできる最善の努力をしよう、
というふうにオペレーションで対応をしている。
IRR で頑張ろう、フィルターをちゃんとしようよ、
MEDで頑張ろう、とかとか。


でも IETF や IRTF 等では、もっと根本的に BGP に代わる
ルーティングアルゴリズムも沢山検討されてて、
良さげなものも結構あるらしい。
たとえば、パケットに経路情報を持たせりゃ良いじゃん、
という提案とか。

具体的には、制御情報を除くと、IP パケットヘッダは

- 発信元
- 宛先

の2つの情報しか持ってないけど、これを拡張して

- 発信元
- 宛先
- 途中経路1,途中経路2,途中経路3,途中経路4,,,,

みたいに経路情報をパケットに持たす、という提案。

もし経路情報がパケットに含まれていれば、
ルータは、書いてある経路に従って、転送してやるだけ。
経路情報はエンド側で作ってやる。
経路情報を作る元ネタには、IRRみたいなものを拡張した
経路情報サービスを利用する。

経路情報がパケットが入ってなかったら、
今までどおりの通信を行なうだけ。
むしろほとんどの通信は、今までの方法のままで、
あくまでも、イレギュラーな経路で通信したい、という場合だけ、
経路情報付きパケットだけ、を使う、と。

そもそも経路情報が爆発的に増えたのは、
マルチホーム等のイレギュラーな経路を実現するための、
パンチングホールが主な原因なんだよね。
そういうわがままな人達のためのコストをインターネット全体で、
払うのはやっぱり不自然な気がする。
基本サービスとして、綺麗にアグリゲートされるツリー型の
経路を用意しておいて、今までどおりの通信をする。
でもイレギュラーな経路を使いたいユーザは、
それぞれが経路情報をパケットに付ける、というようにする。
わがままなユーザは、わがままの代償として、経路情報を付ける、
という、コストを負担することになる、と。

実装もわりとシンプルにできそうだし、ルータの負荷も軽そう。
届かない場合は、経路情報なしで再送すれば、済むだけ。
アプリケーション毎に経路を選ぶことができる。
経路情報サービスは、複数の会社がそれぞれに立ちあげることが可能で、
競争によってコストも削減できそう。
  
将来のモデルとしては、なかなか良いアイディアな気がするね。

ひょっとするとこういう考え方は、IP ではなく、
オーバレイネットワークみたいなものの上で最初に
実装されるのかもなあ。

勉強しなきゃ、とか思った。

■ JANOG 宴会 [JANOG][宴会]

新橋にて。
主に今井さんの話を聞いてた。

■ JANOG 19 Staff Meeting [JANOG]

汐留にて。
追加募集したスタッフも揃った。
大人数。

MT の使い方説明をしたり。

■ JANOG 19 プログラムミーティング 高速切替 [JANOG]

新橋にて。

SONET なんかだと、障害があったとき 50 ms 以内に
うまいこと対応できたりする。
でも、IP で構築された経路で同等のクオリティを実現するのは
かなり大変。
でも要望はあるので、、、という話。

BFD を使っていこう、という結論にできるかしら。

■ JANOG Web 整備 [JANOG]

テンプレートいじり等々。
MT は楽。

■ JANOG PC ミーティング [JANOG]

神保町にて。
発表者の顔合わせと、内容についてのプレゼン。
沖縄も面白いプログラムが沢山出てきそう。
わくわくするね。

■ JANOG ML へのアナウンス [JANOG]

ウェブがリニューアルされたよ、とアナウンス。
レジストが開始されたよ、とアナウンス。
みなさまお疲れさまでした。
って本番まではまだまだだけどな。

■ JANOG 19 ウェブリニューアル [JANOG]

だーやまさんが格好良いテンプレートを作ってくれたよ。
ということでリニューアル!

JANOG19 Meeting
http://www.janog.gr.jp/meeting/janog19/

■ JANOG 19 下見ツアー [JANOG]

大人数で沖縄へ!!!

でもでも仕事の都合で東京でお留守番。。。。
明日、職場の総会なの。。。。
かなしすぎ。。。。

■ JANOG19 キックオフ宴会 [JANOG][宴会]

歩道橋を乗りついで銀座の沖縄料理屋へ。
プロデューサーの喋り方等を勉強。

■ JANOG19 スタッフミーティング [JANOG]

汐留にて。
Skype で沖縄と大阪を繋いでみる。

LA が Wiki にパワポを上げているのを発見したので、
速攻で Pub のパワポ作成。どたばた。

まずは自己紹介。

次は分科会。
Pub は10人体制をもくろんでたけど5人しか集まらなかったので、
やりくりがちょと大変。
場合によっては再募集するかも。

最後に全体でもう一度打ち合わせ。

いろいろやること山積み。
がんばろー。

■ JANOGのプログラム公開 [JANOG]

公開したよ。

http://www.janog.gr.jp/meeting/janog19/2006/10/post_23.html

発表者やプログラム委員はまだ伏せてあります。
小出しにしていく予定。

■ JANOG プログラム面接 [JANOG]

金曜日に続いて2日目。夜だけ参加。大手町にて。

面接終了後にどのプログラムを採用するか検討検討。

■ JANOG プログラム面接 [JANOG]

夜だけ参加。大手町にて。
タイトルを決めるために変態とか猥褻とかを一生懸命検索。
BGPの話なんだけどね。

■ 電気通信事業法第七条の翻訳 [JANOG][computer]

http://ya.maya.st/d/200610a.html#s20061007_1

（基礎的電気通信役務の提供）
第七条　基礎的電気通信役務（国民生活に不可欠であるため
あまねく日本全国における提供が確保されるべきものとして
総務省令で定める電気通信役務をいう。以下同じ。）を
提供する電気通信事業者は、その適切、公平かつ安定的な
提供に努めなければならない。

これを今風に翻訳すると

（ユニバーサルサービスの提供）
第七条 NTT 東西は加入電話とか公衆電話とか110番とか
119番とかを日本全国格差なく不採算だろうが
なんだろうがやらなきゃダメ。

こうなる、と。
なるほど。

インターネットは総務省令で定められていないし、
義務を負うのも提供事業者として指定されている NTT 東西だけ。

NTT 東西って大変なんだねえ。

法律をやさしく翻訳するプロジェクトみたいなものって
あったら嬉しい気がするな。
wikipedia 財団でやらないかな、そういうの。
法律家も楽になると思うし、法律家不足の問題も
解消できると思うのだが。

でも税金使ってやるのはなんか違う気もする。