要約

  • RFC 7911はprefixに四octetのlocal Path Identifierを加え、同一prefixの複数広告を、協議した一方向で同時に扱えるようにする。
  • senderは見せる集合を選び、receiverはimport、best path、multipath、FIBの権限を保つ。Path Identifierは順位でも永続global IDでも、多様性の証明でもない。
  • 安全性はAFI/SAFIごとの実効方向、送受信された集合、state上限、個別withdraw、FIBとtrafficで検証する。見える本数だけでは冗長性を証明できない。

route reflectionは情報を要約する仕組みである。full-mesh iBGPなら各speakerが候補を直接受け取る。reflectorはsession数を減らし、通常は自らbestと判断した経路をclientへ渡す。clientが受け取るのは結論であり、その結論を生んだすべての候補ではない。

この取引は多くのnetworkで合理的だ。しかし隠れた候補がclientのpolicyなら受け入れられる経路、障害後に残るbackup、またはclientのIGP位置から自然な出口である場合、要約は選択肢を奪う。BGP sessionが健全でも、物理networkに存在する可能性がclientへ届いているとは限らない。

通常のBGPはその圧縮をさらに強める。同じneighborから同じNLRIが再広告されると、後の広告が前の広告を暗黙に置換する。routeのkeyはprefixである。基本protocolだけでは、同じsessionから同じprefixの二経路を保持し、別々にwithdrawできない。

RFC 7911はNLRIの前に四octetのPath Identifierを置く。wire上のkeyはprefixとidentifierの組になる。同じ組の新しい広告はその一経路だけを置換し、withdrawはその組だけを除く。未受信identifierのwithdrawは無視し、prefixの全候補を消してはならない。

identifierの意味は意図的に狭い。広告speakerがそのsessionのためにlocalに割り当てる。経路を再広告するspeakerは自分の番号を作り、上流の値をend-to-end labelとして運ばない。control plane restart後に番号が変わってもよい。数値から優先度、由来、年齢、品質を推測できない。

したがって、Path Identifierはprotocolの帳簿には適するが、資産IDにはならない。複数reflectorの「path 8」を一つの経路として結ぶmonitorは誤った関係を作る。restart後に同じ番号を要求する検査も、local tokenの連続性を機能の連続性と混同している。比較すべきはattribute、役割、next hop、forwardingである。

ADD-PATH capability code 69はsession全体の単純なon/offではない。tupleごとにAFI、SAFIとreceive、send、bothの方向を示す。同一AFI/SAFIについてsenderがsendを、receiverがreceiveを広告したときだけ、その方向でmultiple-path encodingが有効になる。

そのためIPv4 unicastの片方向だけがADD-PATHで、逆方向や別familyは従来方式というsessionも正しい。reflectorはclientへ複数経路を送りながら、clientからは一経路だけを受け取れる。「有効」とだけ書いたchange recordは、実際の権限を示していない。

capabilityは運搬を許すだけで、集合を選ばない。RFC 7911は、同じneighborから学んだ経路でない限りsenderのbest routeを含めるべきだとするが、全経路の送信は要求しない。実装はall、N-best、neighbor ASごとのbest、multipath eligible、またはpolicy subsetを採用できる。

この選択が価値を決める。同じnext hop、site、line card、provider、conduitを共有する二経路はstateを二倍にしても逃げ道を二つにしない。ASごとのbestは商流の多様性を増しても、同じfiberを通るかもしれない。identifier数はcontrol object数であり、独立failure domain数ではない。

RFC 7964はMEDによるpersistent oscillationという限定問題で、このtrade-offを示す。all available pathsはfull meshに近い情報整合性を与えるがstateが大きい。Group Bestは一定のtopology条件でneighbor ASごとのbestに縮める。後者は特定の振動原因に対する解であり、すべてのADD-PATH設計に適用できない。

複数経路を受けてもreceiverの決定権は残る。import policyで拒否し、一つをbestにし、multipath groupを選び、または候補をFIBへ入れず保持できる。RFC 7911はRFC 4271のDecision Processを書き換えず、ECMPもhardware installも強制しない。

従って「四経路を受信」と「四つの独立出口」は別の主張である。一つはfilterされ、一つはnext hop unresolvedで、二つは同じrecursive adjacencyへ収束するかもしれない。Loc-RIBの選択数をhardwareが削る場合もある。Adj-RIB-Inからpolicy、decision、recursion、FIB、packetまでを追って初めて利用可能性が分かる。

IXP route serverのpath hidingは可視性不足を具体化する。RFC 7947では、serverが選んだ経路を特定clientのpolicyが拒否する一方、server上の別候補なら受け入れられる場合がある。選択済み一経路しか送らなければ、clientはrouteを失う。client policyは正しくても、入力世界が不必要に狭い。

ADD-PATHは候補を増やせるが、trust boundaryが重要である。RFC 7947はroute serverが双方向で複数経路を扱うと、clientのinactive、invalid、suboptimalな経路を広げる恐れを指摘する。この用途ではserver send-only、client receive-onlyを推奨する。trafficを自ら転送しないIXP設備向けの分権であり、社内reflectorへ無条件に移す規則ではない。

一つのASでもclientごとに異なる集合はあり得る。大きなedge routerは多様な出口を必要とし、小型装置には小さい上限が必要かもしれない。ただしrole、family、algorithm、maximum、期待するconvergenceを記録しなければ、障害時にどのclientが何を見る権利を持っていたか説明できない。

追加stateには実費がある。RFC 7911は多数prefixのmultiple pathsがmemoryを枯渇させ、network-wide instabilityを招き得ると述べる。各経路はRIB、attribute、policy evaluation、update処理、telemetryを増やす。平常時に静かな予備集合も、障害時には大量の再選択とwithdrawになる。

RFC 6774も別のpath distribution方式から同じ境界を示す。path starvationを減らし、障害前にbackupを知るにはcopyと処理が増える。可視性は無料の機能ではなく、budgetとadmission ruleを伴う資源配分である。

実装はpolicy層を分けている。Ciscoはcapability、additional path selection、advertisementを別にする。Junosはsend/receive設定とnegotiated effective stateを区別する。FRRoutingはall、per-AS-best、N-bestやreceive limitを持つ。製品例はprotocolの保証ではないが、承認時に記録すべき項目を明らかにする。

最初の証拠はneighbor、AFI/SAFI、方向のentitlement matrixである。localが広告したmode、remoteから受け取ったmode、そこから導く実効方向を記録する。続いてsender selection、最大本数、export filter、通常bestを含める規則、client間差分を明示する。

baselineはcountではなく集合を保存する。Adj-RIB-Outでprefix、local Path Identifier、next hop、AS_PATH、origin、MED、community、eligibility reasonを記録する。receiverではAdj-RIB-In、import結果、best reason、multipath eligibility、Loc-RIB、FIBを捕捉する。異なるspeakerのidentifierをglobal keyにしてはならない。

置換とwithdrawは完全なkeyで試す。同じidentifierでattributeを変えればその経路だけが変わる。一つをwithdrawしてもsiblingsは残る。未知identifierのwithdrawは何も消さない。この試験は、prefix-only identityへ戻ってしまうcollectorやautomationを発見する。

restart試験では番号の維持を求めない。古いidentifierが消え、想定attributeの候補が時間内に戻り、orphanがFIBに残らないことを確かめる。安定した証拠は経路と利用可能なforwardingの関係であり、番号ではない。

多様性はfailure domainで測る。next hop、neighbor AS、site、line card、link、provider、conduit、policy domainの重なりを確認する。情報がない層はunknownと記す。二つのtokenがunknownをredundancyに変えることはない。

最後にpreferred egressを実際に失わせる。既に受信済みの候補がremote explorationを待たずbestになるか、update量、decision時間、next-hop resolution、FIB programming、packet lossを測る。filterされる候補、resolution不能な候補、同じ故障を共有する候補も試す。

capacityはadmission contractである。neighbor、family、prefixごとの上限、memory ceiling、update rate、telemetry retention、超過時の挙動を先に決める。受信側が任意の候補を黙って捨てれば、capability成功表示の裏でpath hidingを再生産する。

rollbackはcommand削除だけではない。集合を従来形へ縮め、古いidentifierとFIB residueを除き、capability renegotiationを検証する。session resetが必要なら、そのreachability riskは最初の決裁に含めるべきである。

衡路のminimum initial specificationは境界を説明する。共有するのは小さなdirectional capabilityとlocal discriminatorである。何を見せ、いくつ受け、何をFIBへ入れるかは各者に残る。相互運用は将来policyの中央集権化を要求しない。

running-code primacyは証拠の順序を与える。configurationは意図である。negotiated capability、送信tuple、受信route、best理由、programmed next hop、packet観測がより強い事実になる。候補がこの鎖を通らなければ、実運用の選択肢ではない。

data sovereigntyは可視性の支配として現れる。senderは公開集合を、receiverは利用集合を支配し、物理networkが結果を制約する。「複数経路を共有した」という一言でこの三つの権限を消してはならない。

ADD-PATHは全経路送信命令でも、resilience保証でもない。prefixだけのidentityが一つのsessionで代替候補を消し続けることを止める仕組みである。意図した集合が有限で、意味を説明でき、preferred route消失後に実際のforwardingへ変わるときに価値を持つ。

出典