要約

  • RFC 5332では、multicast IP宛てGREの0x8847はdownstream-assigned top label、0x8848はupstream-assigned top labelを示す。別の契約がupstream assignmentを要求するときだけ、0x8847はdiscard対象になる。
  • discard規則はreceiverの判断を定義するが、実装が実行したこと、別経路がなかったこと、packet lossやservice impactが起きたことまでは証明しない。

同じ四桁が正常にもerrorにもなる

外側のIP destinationがunicastなら、MPLS-in-GREは常に0x8847を使う。destinationがmulticastなら、top labelのassignment directionによって0x8847と0x8848を使い分ける。

さらにRFC 5332は、外部の手続きにより「このmulticast GRE tunnelではtop labelがupstream-assignedである」と既知の場合を定める。そのtunnelで0x8847が現れればerrorとしてdiscardしなければならない。

packetのbyteだけに違反属性が埋まっているわけではない。outer destination、tunnel identity、assignment contractとそのepoch、observed codepointを合わせて初めて判定できる。契約を収集しない監視は、正常をerrorにするかerrorを正常にする。

旧multicast codepointは役割を変えた

RFC 3032は二つのdata-link codepointをMPLS unicastとmulticastの区別として示した。RFC 5332は、そのmulticast用法が導入されず、後の設計では別の区別が必要になったと説明する。旧用法はdeprecatedになった。

Ethernet multicast frameでも0x8847は使われる。top labelがupstream-assignedの場合だけ0x8848を使う。従って二つの値はunicast/multicastの排他的な分類ではない。

multicast labelかどうかは、特定contextでのNHLFEがreplication semanticsを持つかで決まる。next-hop setが一つでも、全メンバーへcopyする意図を持つentryなら定義上multicastである。名前ではなくlookupが意味を作る。

assignment directionはtableの入口でしかない

downstream assignmentではreceiverがlabel-FEC bindingを作ってsenderへ知らせる。upstream assignmentではsenderまたは第三者がbindingを作る。後者は通常のdownstream label spaceと同じである必要がない。

RFC 5331はcontext-specific label spaceを解決する手順を担う。RFC 5332のcodepointは「upstreamの文脈が必要だ」と伝えるが、root、interface、tunnelなど完全なcontext keyを自動的に供給しない。

そのため0x8848が正しくても、wrong tableを引けばforwardingは正しくない。逆にcodepoint anomalyを見つけても、実際のlookup resultなしにmisrouting先は決められない。隣接する二つのRFCは連続したreceiptであり、同一の証明ではない。

supportの「既知」は別の状態である

upstream-assigned labelはoptionalで、downstream LSRがsupportすると分かっていなければ使ってはならない。RFC 5332は、その知識を得る方法をscope外に置く。

ローカル装置のfeature flagはpeer knowledgeではない。過去のcapability recordも、peer交換、software rollback、link移設の後まで自動的に有効ではない。support receiptは相手、関係、source、version、観測時刻と失効条件を持つ必要がある。

contractが正しくてもsupportが古い場合、wire valueだけを見たdashboardは緑になる。ここで監視すべきなのはcodepointだけではなく、判断を支える関係証拠のfreshnessである。

PPPとnative IPは同じ区別を運ばない

PPP frameがMPLSを運ぶときProtocol fieldは常に0x0281である。point-to-point方向ごとにassignment modeは統一され、別の情報がなければdownstreamがdefaultになる。

native IP encapsulationではIPv4 Protocol NumberまたはIPv6 Next Headerは常に137であり、内部MPLS packetがmulticastかどうかで変わらない。multicast IP tunnelではassignment directionが一貫していなければならないが、その決め方はRFCの外にある。

全mediaを一つのBoolean schemaへ押し込むと、GREにあるbitをPPPやIPにもあると仮定してしまう。observed、contract-derived、defaulted、unknownを分離しなければ、欠けた情報が事実へ変換される。

MAC DAのsuffixは二つの正解を許す

Ethernet multicast MPLSのdestinationは01-00-5e-8v-wx-yzである。20-bitのvwxyzはzeroでもよく、label stackの一つの値でもよい。複数labelならsecond labelがdefaultだが設定で別のlabelを選べる。一つならそのlabelを使う。

zero方式とlabel-derived方式は相互運用しなければならない。zeroを全部捨てることも、non-zeroを一律に捨てることも許されない。suffixからLSP-specific informationを得てfilterへ使う可能性はあるが、その用途はscope外である。

従ってsuffixはreceiver identityでもgroup membershipでもない。どのlabelを投影したか、filterが何をしたか、その後に誰が受信したかを別々に残さなければならない。

discardはoutcomeではない

規格が「MUST discard」と書くと、運用reportはすぐに「packet lost」と書きたくなる。しかし規則、実装、観測結果は三層である。packetが対象receiverへ到達したか、software versionが規則を実装したか、counterが増えたか、alternate pathがあったか、serviceがdeadlineを外したかは別のreceiptである。

同じ慎重さはsecurity considerationにも必要だ。codepointの悪意ある変更はlossやmisroutingを起こし得るが、labelを変えずcodepointだけ変えた効果はpredictableではない。MAC DAの変更は第三者へ届く可能性を作るが、実際の受信を証明しない。

anomalyは重要である。ただし重要であることと、結果が確定したことは同じではない。

判定を再生できる形で残す

必要なのはframe ingress、outer addresses、GRE field、raw label stack、tunnel contract、peer support、context selector、NHLFE result、MAC derivation、filter、replication、egress、receiver observation、service resultである。

さらにparserはsemantic versionを持つべきだ。RFC 3032時代の「multicast codepoint」とRFC 5332の「upstream-assigned label」は同じ番号に異なる命題を結びつける。raw evidenceを保持すれば後から再解釈できる。

共通規格は相互運用に必要な最小限を決める。tunnel ownerはlocal contractを決める。running systemはdecisionを行う。analysisはreceiptをjoinする。どの層も次の層のauthorityを借りてはならない。

情報源