要約

  • RFC 9107はreflector自身の物理位置ではなく、client、client group、またはreflector全体を表すconfigured IGP locationから内部costを計算できるようにする。
  • 「optimal」は同じeligible candidatesとpolicyからその視点が選ぶrouteという限定概念であり、最低latency、費用、混雑を保証しない。
  • 安全な運用はroot assignment、topology epoch、candidate completeness、compute capacity、backup動作、client受信route、FIB egressを証明する。

中央data centreのvirtual reflectorが三都市のrouterを担当するとする。二つのborderが同じprefixを広告し、local preferenceやAS_PATHが並び、decisionがIGP costへ進む。東のclientには東のexitが近く、西のreflectorには西が近い。

reflectorは「私に近いnext hop」を正しく選び、西のrouteを全clientへ渡す。東のclientは別candidateを見ない。そのpacketはforwardingしないcontrol machineだけに最適な出口へbackboneを横断する。

部品は壊れていない。IGP metricは正しく、BGP Decision Processもsessionも正常である。誤りは視点にある。正確なalgorithmでも、依頼者と異なる場所から実行すれば安定して不適切な答えを作る。

RFC 4456はこのscaling trade-offを認める。route reflectionは情報を要約し、通常は自分のbest pathだけを反射する。IGP costはrouterごとに異なるため、あるtopologyではfull meshと同じ選択にならない。従来はreflection topologyをforwarding topologyへ近づけた。

reflectorがforwarding path外へ移り、仮想化・集中化されると対応関係は弱くなる。computeに便利な場所のIGP座標が、偶然traffic engineeringの入力になる。vRRを移すだけでexternal UPDATEなしにegressが変わり得る。

RFC 9107はlogical IGP rootを導入する。operatorはlink-state topology内のnodeをloopback等のIP addressで指定する。reflectorはそこをrootとするshortest-path treeを作り、candidate BGP next hopまでのcostを内部cost比較に使う。

rootはviewpointでありwaypointではない。packetがrootを通る必要はなく、reflectorもforwarderにならない。選択されたBGP next hop、clientのrecursive resolution、FIBがtraffic pathを作る。logical rootを物理hopと説明してはいけない。

granularityはreflector単位、client group単位、client単位から選べる。RFC 9107準拠には少なくとも一つのgrouping categoryのsupportで足りる。準拠という表示はper-client precisionを意味しない。

一つのrootは安価だが従来biasを残す。regional groupは中心には近くても端にはずれる。per-client rootは位置をよく表すが、SPFとBGP decisionを増やす。精度とcapacityは別の問題ではなく、一つの選択である。

optimalの範囲も狭い。基本ORRはRFC 4271 Phase 2 step eのIGP costをselected rootからのcostへ置き換える。先に適用されたpolicyは残る。高いlocal preferenceなら遠いexitが選ばれる。

IGP costはlatency、congestion、loss、transit price、maintenance riskを直接測らない。ORRが助けるhot-potatoとは、prior policyが許したcandidateの中でtopology metric上近いexitを選ぶことである。

client setsに異なるBGP policyが必要なら、RFC 9107はDecision Processのより大きな部分、最大で全体を複数回実行できる。group assignmentはtopological perspectiveだけでなくcommercial perspectiveも委任し得る。

client-to-root mapはproduction policyである。clientを別groupへ移すだけで、外部routeやIGP linkが変わらなくても何千ものAdj-RIB-Outが変化する。version、review、bounded rollout、exact diff、rollbackが必要になる。

計算前にcandidate setが完全でなければならない。reflectorが学ばなかったrouteをclientの代わりに選ぶことはできない。RFC 9107はeligible pathsをすべてreflectorsが学ぶ必要を述べ、cluster間ではADD-PATHを必要とする。

capability lineだけでは完全性を証明しない。AFI/SAFIと方向、sender path-set、import policy、実際のAdj-RIB-Inを確認する。完全なSPFを不完全なroute setへ適用しても、clientの答えにはならない。

ORRはstate配置を変える。edgeまでADD-PATHを送ればlocal decisionができるが、edge RIBとupdate loadが増える。ORRはrich candidatesをreflector側に置き、perspective別に選択して小さい結果を配る。distributed stateの節約は中央computeとtrustの集中になる。

topology inputも証拠が必要である。RFC 9107はIS-IS、OSPF、BGP-LSを挙げる。databaseが存在しても、stale、wrong area、missing root、またはredundant reflector間不一致かもしれない。

BGP-LSは計算点へlink-stateを運べるが、consumer viewを保証しない。topology epoch、node/link coverage、source session health、forwarding routerのIGPとの比較を記録する。RFC 7752はRFC 9552に置き換えられたため、現行実装が使う仕様も確認する。

recursive next hopには別の限界がある。BGP next hop自体をBGP routeでresolveする場合、最終的なIGP costが必要になる。RFC 9107はそれをBGPへ渡せない実装に、metric比較ではそのpathをleast preferredとしながらPhase 2ではvalidに保つことを求める。valid pathがvisibility不足で負け続ける場合がある。

platform restrictionはprotocol ruleではない。JunosはMPLS protocolがprimary resolutionを担うserviceで制約を示す。CiscoはIGP-learned rSPF、BGP-LU、multiple IGP topologies等の制限を文書化する。deployed releaseとAFI/SAFIごとに検証する。

vendorの「bestを保証」もsystem proofではない。configured rootに対する計算が正しくても、root assignment、topology freshness、candidate set、client installのどこかが誤り得る。product correctnessは一段にすぎない。

backup rootは視点のfailure lifecycleである。RFC 9107はbackup locationを推奨し、Junosはprimaryとoptional backupを持つ。primary消失時はobserverが変わり、reachabilityが続いても多くのexitが変化する。

backupにはexpected route-set diffとforwarding testが要る。限定範囲でprimaryを失わせ、SPF切替、group別advertisement、client FIB、trafficを確認する。「backup configured」はcontinuity evidenceではない。

hop-by-hop forwardingではloopにも注意する。RFC 9107はtunneled環境でも使えるが、encapsulationなしのmultiple reflector topologyは慎重な設計を求める。一つのrootから合理的な選択がsystem全体で安全とは限らない。

computeはcontrol contractの一部である。多くのrootは多くのSPF treeとBGP evaluationを要する。fine granularityはCPU、memory、queue、convergenceを悪化させ、topology failure時に最も遅くなる可能性がある。

capacity testはroute、client、root、IGP node、failure fan-outをまとめて扱う。steady state、full recalculation、incremental event、IGP changeからclient advertisementまでの時間を測る。静かなlabでのみ正しいdesignはfailure controlにならない。

最初のartefactはclient、AFI/SAFI、primary、backup、group、policy、owner、許容approximationを結ぶperspective registryである。次にADD-PATH方向とAdj-RIB-Inでcandidate completenessを示す。さらにtopology epoch、root-to-next-hop cost、prior attributes、winning stepを残す。

最後はclient側でreceived route、import、best reason、recursion、FIB egress、packet pathを検証する。別のsourceから学んだrouteをclientが選ぶなら、そのrunning factを説明する。

scenarioにはgroup move、root failure、backup、hidden candidate、stale topology、recursive next hop、higher policy、compute saturationを含める。各々にexpected diffとtime envelopeを持たせる。

rollbackはsyntaxではなくperspectiveを戻す。ORRを外してreflector自身の位置へ戻っても、reverse updatesがclientとFIBへ届く必要がある。途中でtopologyやcandidateが変われば完全復元はできない。

authorityは分ける。IGP ownerがrootを、BGP ownerがgroupとpolicyを、reflector operatorがcapacityを、traffic ownerがegressを検証する。rootがclientを代表するというclaimをindependent reviewerが拒否できなければならない。

衡路のminimum initial specificationは小さなcommon mechanismを支持する。logical pointとdecision stageを標準化し、centralization、granularity、adoptionはlocalに残す。running-code primacyはlearned topologyからpacketまでを要求し、data sovereigntyはgraphの所有ではなくdecisionを検証・異議申立てできることを意味する。

ORRはcentralizationの欠点を、より制御されたcentralizationで直す。reflectorを物理都市から解放する代わりに、root mapを新しいrouting authorityにする。「optimal」という名前ではなく、誰の目で計算し、packetが同意したかが結論である。

出典