One Prefix Becomes A Decision Set

Session Goal

このセッションで終わらせたいこと

Session 14 のゴールは、best-path selection が単独で走るのではなく、validation と policy を通った candidate 集合の上で走ると説明できるようになることです。

• 1 prefix が複数 peer の decision set になると説明できる
• validation / action / installable candidate を 1 レコードにして読める
• policy rewrite が best path の勝者を変えうると説明できる

Bridge

Session 03 と Session 04/05 を prefix-wide に戻す

Session 03 は pure best-path でした。Session 04/05 は validation と policy を分離しました。Session 14 は、それらを複数 peer の prefix-wide decision として再統合します。

Read The Source

1 prefix を peer ごとの評価結果に展開する

for peer_id, attributes in received_attributes_for_prefix(adj_rib_in, prefix):
    validation_state, action, installed = evaluate_candidate(prefix, attributes, vrps, policies)

重要なのは、best-path に入る前にすでに candidate ごとの評価が終わっていることです。best-path が見るのは installable な残りだけです。ここでは PathCandidate が持っていなかった peer_id を、CandidateDecision で復元しています。

Walkthrough

policy rewrite が勝者を変える

walkthrough では 1 本の invalid route を soft policy で deprioritize し、その結果として別 peer の valid route が best に上がる様子を確認します。

cd protocol-in-code
PYTHONPATH=src python3 examples/bgp/session_14_walkthrough.py

Done Check

Session 14 を終えたと言える条件

• best-path 前に candidate evaluation loop があると説明できる
• validation result と action と installed candidate を分けて話せる
• policy rewrite によって最終 winner が変わると説明できる

Next Session

最後に speaker object と event handlers をまとめる

prefix-wide decision set が見えたので、最後は peer state、RIBs、event handlers、export refresh を 1 つの speaker object にまとめます。