要約

  • RFC 3020はMFR bundleのactivationを、1本以上、全link、指定本数、実装固有という4種類のruleで定義した。
  • bundleのifOperStatus=upは、そのruleが成立したというreceiptであり、全linkの健全性、予定容量、frameの完全性、遠端applicationの受信を証明するものではなかった。

欠けた番号は二つ、counterの増分は一つだった。

RFC 3020はmfrBundleResequencingErrorsの説明で具体例を示した。sequence 56、59、60を受け取り、57と58が失われたと判断した場合、counterは二つではなく一つ増える。数えているのは失われたframeではなく、再順序化error eventだからである。

この小さな差が、MIBを証拠として読む際の核心になる。値は正しくても、観察者が勝手に別の単位へ変換すれば結論は誤る。同じことがbundleのup/downにも当てはまった。upは「すべて正常」の別名ではなく、設定されたactivation条件の評価結果だった。

2000年12月に公開されたRFC 3020は、FRF.16のUNI/NNI Multilink Frame Relayを監視・制御するmanaged objectを定義した。複数のphysical linkを一つの論理bundleとして扱い、Q.922からは単一の物理interfaceのように見せながら、異なるlinkを通ったframeの順序を復元する仕組みである。

古いFrame Relayの文書でありながら、aggregationを運用する現在にも通じる原則を明示した。aggregateの状態はcomponentの自然な総和ではない。誰かが選んだrule、対象となる母集団、agentの評価によって作られるprojectionである。

bundleとmemberは別の管理対象だった

各bundle linkはInterface MIBに現れ、それぞれifIndexを持った。bundleも上位から見れば一つのinterfaceなので、別のifIndexを持った。一方、MFR固有tableではmfrBundleIndexが使われた。

managerはbundle rowを作るときにMFR側のindexを選び、agentはgenericなifIndexを割り当てた。RFC 3020は双方向のmapping tableを用意した。二つの番号が違うことは、二つのbundleがある証拠ではない。異なる権限で管理されるnamespaceから同じ論理interfaceを参照している可能性がある。

作成receiptも運用状態とは別だった。mfrBundleRowStatusへcreateAndGoをSETするとbundleが作られ、agentはifTableにもinterfaceを生成した。実装はcreateAndWaitを支援できた。member rowはphysical interfaceのifIndexを使い、mfrBundleLinkConfigBundleIndexで既存bundleを指定した。有効な指定がなければrowはnotReadyのままだった。

rowの存在はconfiguration objectの存在を示す。member protocolがupであること、activation条件が成立したこと、frameが届いたことまでは示さない。

同じupに四つの成立条件があった

mfrBundleActivationClassはbundleをactiveにする条件を選んだ。

Class Aは少なくとも1本のlinkがupならよい。Class Bは全linkを要求する。Class CはmfrBundleThresholdで指定した本数を要求する。Class Dはcustomでimplementation-specificだった。defaultはclass Aである。

Class Cではactive link数がthresholdに達するとbundleがoperational up/activeになり、下回るとinactiveになった。thresholdを使わないclassでは値は-1を返した。Class Dでthresholdが意味を持つかどうかは実装に依存した。

bundleのlinkUp/linkDown notificationもこのpolicy判定に従った。classとthresholdが定める十分な本数がupになるとgeneric interfaceのifOperStatusがupへ変わり、逆に不足するとdownへ変わった。

4本構成を考える。Class Aなら1本で緑になる。Class Bなら3本でも赤い。Threshold 2のclass Cでは2本目がbinary stateを変え、3本目と4本目はcapacityだけを変える。Class Dでは、code versionと独自ruleを知らなければ理由を再現できない。

notificationだけを保存し、class、threshold、configured link数、active link数を捨てれば、後から「なぜupだったか」を説明できない。policyはstatusの注釈ではなく、statusの生成元だった。

bandwidthは別の値、throughputはさらに別の観測だった

RFC 3020はconfigured link数とactive link数を別々に公開し、bundleのavailable bandwidthも独立に報告した。

そのため、本来はbundle-upから全member復旧を推論する必要はなかった。Class Aの4本bundleは1本だけで正しくupになり得る。available bandwidthは劣化を表せるが、それもagentが表現するresource stateである。application throughputの測定ではない。

値にはoffered load、測定時間、congestion、retransmission、remote receipt、transaction完了が含まれない。設計capacityと利用可能capacity、観測throughput、useful outcomeは別々のreceiptを要する。

MIBはfragmentation、最大fragment size、sequence number size、最大differential delayも扱った。各memberはround-trip delayを報告できた。複数経路へ分ける仕組みでは、linkがupかどうかに加えて、到着差と順序回復が重要だったからである。

minimum connectivityを示すalarmとcommitted capacityを示すalarmを一つにすれば、技術的に正しい緑がservice上の誤解を生む。

counterは因果記録の一部にすぎなかった

再順序化counterの増分1は、少なくとも一つのerror eventをagentが記録した証拠になる。しかし失われたframe数には直結しない。counterが増えないことも完全配送の証明ではない。polling gap、wrap、reset、agent restart、対象外のfailureを考える必要がある。

link tableにはinvalid control frame、timer expiry、loopback suspected、unexpected sequence、bundle-name mismatchのcounterもあった。memberのstateはFRF.16 state machineの現在位置であり、単純な電気的carrierの複製ではなかった。

mismatch trapはlocalに設定したbundle name、以前に報告されたfar-end name、現在memberから報告されたfar-end bundle nameを並べた。RFC 3020は、configured itemも自動設定された可能性があると注意した。

trapが証明するのはviewの不一致である。local operator、remote peer、automation、stale stateのどれが原因かは、その通知だけでは決まらない。aggregateがupのままでも、これらのcomponent evidenceは劣化を示し得た。

threshold変更は次のrecoveryの意味を変えた

Activation class、threshold、timer、fragmentation、sequence sizeはread-createと定義された。managerはbundleやmember rowを作成・変更・削除し、memberの所属bundleを選べる場合があった。

ただしMIBのmaximum accessは、全実装がwriteを提供するという意味ではない。Complianceは多くのobjectについてminimum accessをread-onlyにできるとし、実際に使う値の報告を求めた。Schema capability、running agentのcapability、principalのauthorizationは別の事実である。

Writeが可能なら、physical linkを直さずにthresholdを3から2へ下げ、bundleをupにできた。Class BからAへの変更も同様である。新しいstateは新しいruleに対して正しい。それを「回線が復旧した」と呼ぶなら、policy relaxationをinfrastructure repairへ変換してしまう。

Security Considerationsは、保護されないSETがnetwork operationへ悪影響を与えると述べた。SNMPv1だけでは、たとえnetworkをIPsecで守っても、そのnetwork上の誰がどのobjectをGET/SETできるかを制御できない。RFCはSNMPv3のUSMとVACMを推奨し、正しい権限設定をoperatorの責任とした。

Authenticationは変更者を示す。Authorizationは変更可能範囲を示す。どちらも、そのpolicyがservice objectiveに十分かを証明しない。

Proposed Standardは稼働実績ではない

RFC 3020はProposed Standardとして公開された。RFC 9141による後年のupdateは、廃止されたIETF FTP serviceへのreferenceを置き換えたもので、MFRのactivation semanticsを変更していない。

資料から証明できるのは仕様と系譜である。特定vendorの実装、carrierのdeployment、実測availability、incident、customer deliveryは証明できない。本稿はそれらを主張しない。

Lu HengのReality Layersは、row作成、activation policy、member state、aggregate interface、integrity counter、receiver outcomeを分ける。Running-Code Primacyはimplementation-specificなclass Dで不可欠である。Minimum Initial Specificationは、限定されたMIBが有用であってもend-to-end monitorを装う必要がない理由を示す。

これらは明示した分析lensであり、Lu HengはRFC 3020の著者でもendorserでもない。

緑のbitを正しく読むには、文章を補う必要がある。「この時点のmember集合に、このversionのruleを適用すると、設定されたminimumを満たした」。容量、完全性、結果は、その後に別の証拠で問うべきだった。

出典