要約

  • RFC 6198は、予定された停止をmake-before-breakの機会として扱う。通常経路を消す前に、影響を受けるrouterが代替経路を学習し、利用できる状態にすることが目標である。
  • RFC 8326はGRACEFUL_SHUTDOWN communityと低いLOCAL_PREFでその意図を伝える。ただし、代替経路の可視性、容量、実装、収束時間までcommunityが保証するわけではない。

「止める」という動詞の前にある仕事

突然の障害なら、転送資源を失った後にwithdrawと再収束を始めるしかない。計画保守では事情が違う。どのsession、link、routerをいつ外すのか分かっている。にもかかわらず最初にsessionを閉じると、正常だった経路を先に消し、その後で代替を探すことになる。

その短い間にpacket lossが起きる。ASBRが受信していてもbestでない経路を外へ見せていないことがある。route reflectorが候補を隠していることもある。routerごとにFIB更新の時刻がずれれば、一時的なloopも生じ得る。冗長linkが存在するだけでは足りない。代替が見え、選ばれ、FIBに入り、増えたtrafficを受け止められる必要がある。

IETF DatatrackerのBruno Decraeneプロフィールは、この問題に関する二つのRFCへの関与を記録している。2011年のRFC 6198はInformational文書として要件を整理した。2018年のRFC 8326はStandards Trackとして、well-known BGP communityとEBGP停止手順を示した。

功績は共同のものだ。RFC 6198にはDecraeneのほかPierre Francois、Cristel Pelsser、Zubair Ahmad、Antonio Jose Elizondo Armengol、Tomonori Takedaが署名する。RFC 8326はPierre Francois、Decraene、Pelsser、Keyur Patel、Clarence Filsfilsによる。IETFのreview、implementer、operatorの仕事も結果を支える。ここで確認できるのはDecraeneの共同執筆記録であり、BGPの単独発明や一方的な標準支配ではない。

要件は「ゼロ損失」という広告ではない

RFC 6198は、BGPが最終的に収束するという説明だけでは保守中の損失を正当化できないと考える。音声、online game、VPNは短い断でも影響を受ける。予定を知っているなら、先に収束を開始し、別経路をinstallしてから通常経路を外すべきだ。

理想はpacket lossをゼロに近づけることだが、文書は条件を隠さない。影響を受けるrouterに保守を知らせる仕組みが要る。複数の既知障害や同時期の保守を含めて代替経路を選ぶ。部分導入でも改善が得られ、neighbor側の導入費用は低い方がよい。保守するASとpeerでは利益が対称とは限らないからだ。

代替経路には十分な残容量が必要である。古い経路は新しい経路が分かる前に消してはいけない。安全に閉じるまでの時間は、固定timer、収束完了を示すmessage、あるいは対象interfaceのtraffic監視で決められる。loop回避は評価対象だが、単純な仕組みがすべてのtopologyを覆うとは書かれていない。

先に成功条件を定義したことで、「graceful」という製品名と、実際に安全な移行が起きたという証拠を分けられる。

communityは通知であって命令ではない

RFC 8326の共有単位はGRACEFUL_SHUTDOWNである。停止を始める側は、対象sessionで既に広告しているactive routeをcommunity付きで再広告する。受信側は、すべての該当EBGP sessionに事前設定したimport policyでcommunityをmatchし、そのrouteのLOCAL_PREFを低くする。推奨値は0だ。

ここでLOCAL_PREFは相手ASから送り込まれる値ではない。受信ASの内部判断である。communityは「このpathは計画的に退出する」と伝える。相手networkは、その情報をどうrankingに反映するかを自分で決める。共通の言葉はあるが、制御権はlocalに残る。

trafficは双方向に移す必要がある。initiatorは送信routeにmarkしてneighbor側のinbound trafficを別経路へ促す。同時に、そのsessionから受けたrouteをlocalで低い優先度にし、自分のoutbound trafficも移す。再広告と両ASBRの収束を待ち、最後にEBGP sessionを閉じる。必要なら別のshutdown messageで理由を伝えるが、理由の文字列はdrainの代わりにならない。

BGP Graceful Restartとの違いも明確だ。RFC 8326は保守がforwarding planeに影響する場合を扱う。古いrouterが転送を続けると仮定せず、外す前に依存を移す。

見えない代替経路は選べない

communityは帯域を増やさず、隠れたrouteを自動的に公開しない。代替linkが過負荷なら、RIBの移行がきれいでもserviceは悪化する。receiver policyが一部のedgeだけにあり、route reflectorやFIBが期待どおりでなければ、initiatorから見えない場所でdrainが止まる。

RFC 8326自身も適用範囲を限定する。manual EBGP shutdownでalternative pathが隠れていたため一時的にrouteを失う問題には対応するが、すべてのFIB不整合やloopを解決しない。IBGP shutdownとEBGP establishmentは主手順の範囲外である。router全体を外す場合は、そのrouterが生成・redistributeするrouteにもcommunityと低い優先度が必要になる。

さらに、markは善意を認証しない。peerが一部prefixだけを保守扱いにし、別linkへinbound trafficを動かそうとすることもできる。RFC 8326は、その利用を許容しないISPにcommunityの監視を勧める。prefix、session、時刻、継続時間、実際のcloseを関連づけなければならない。

RFCの存在とproduction supportも別だ。appendixのconfiguration例は機構の表現可能性を示すが、現在のsoftware version、default、実装範囲、特定operatorの結果は証明しない。

小さな合意をrunning networkで検証する

Lu Hengが後に示したMinimum Initial Specification, Localized Future Decision, and Voluntary Adoptionの視点では、二つのASが共有すべきものは最小限でよい。退出予定を表す識別可能なsignalと、withdraw前に優先度を下げる時間である。topology、capacity、ranking、timer、rollbackは各networkが決める。

communityを相手が自networkを支配する権利として扱えば越権になる。receiverが何も反応しなければsignalは空になる。自発的な導入、明示的なlocal policy、観測できる効果の三つが揃って初めて機能する。

Running-Code Primacyを適用するなら、試験対象はRFC番号ではない。全edgeのpolicy、再広告されたroute、best-path変更、FIB、interface counter、代替pathのlossとcapacityを確認する。固定時間が過ぎたことではなく、依存が移った証拠をclose条件にする。この後世の論点はSofia Renの分析枠であり、Decraeneや当時のIETF文書に逆向きに帰属させるものではない。

graceful shutdownの本質は礼儀ではなく順序である。古いpathは新規trafficを引き寄せる力を先に失い、残るpacketを運ぶ能力は少しだけ保つ。別pathが引き受けたことを確かめてから、sessionを消す。

出典