Session Goal
このセッションで終わらせたいこと
Session 11 のゴールは、UPDATE を受け取る前提条件が route logic の外側にあることを説明できるようになることです。Session 10 の pipeline は「受け取った route から先」を読んでいましたが、ここではその前にある session gate を切り出します。
Establishedが write permission だと説明できる- peer state と route state を混ぜずに話せる
- Adj-RIB-In に入る前の gate を指差せる
Bridge
Session 01 の state machine を route flow に戻す
Session 01 では neighbor formation の state machine を見ました。Session 11 はその state machine が、実際には UPDATE を受け入れる条件として control plane に戻ってくることを示します。
Read Order
この順番で読むと迷いにくい
PeerSessionを読むopen_peer_session()がestablish_neighbor()を包むことを確認するsession_accepts_updates()の boolean gate を読むreceive_update_if_established()で store が条件付きになることを確認する
Read The Source
Adj-RIB-In に書く前に 1 つ if がある
if not session_accepts_updates(peer):
return False
store_received_path(adj_rib_in, peer.peer_id, prefix, attributes)
return Trueこのセッションの核心は、route attribute の中身ではなく、この gate の存在です。peer がまだ立ち上がっていないなら、その route は candidate set にさえ入りません。
Toy Model Boundary
ここでは session-state gate だけを切り出しています
この lesson は Established を first gate として見せるためのものです。real implementation では address-family activation や negotiated capabilities のような追加 gate もありえますが、ここではその前段だけを明示しています。
Walkthrough
Established でない peer は UPDATE を落とす
walkthrough では 1 本は未成立 peer、もう 1 本は成立済み peer にして、どちらが Adj-RIB-In に入るかを確認します。
cd protocol-in-code PYTHONPATH=src python3 examples/bgp/session_11_walkthrough.py
Done Check
Session 11 を終えたと言える条件
- route pipeline が始まる前に session gate があると説明できる
Establishedでない peer の UPDATE が無視される理由を説明できる- Adj-RIB-In は「届いたもの全部」ではないと説明できる
Next Session
次は Loc-RIB の変化を Adj-RIB-Out に反映する
route を受け入れる前提条件は見えました。次は、best path が変わったあとに各 peer 向け広告がどう更新されるかを export refresh として読みます。