要約

  • RFC 9658は{MT-ID, IPA}をmLDP multipoint FECの一部にし、root解決、upstream、downstream interface、wildcard、End-of-LIB、LSP Pingを同じscopeへ置く。
  • scoped probeの成功は問われたbranchを示すが、他のleaf、継続的なreplication、application受信、service outcomeを自動的には証明しない。
  • treeのreceiptにはalgorithm/topology revision、capability、FEC bytes、root lookup、branch集合、label、hardware programming、branch別probeとreceiver observationが要る。

Probeが答えるのは、与えられた質問だけ

RFC 6425はmultipoint LSP Pingを定義し、RFC 8029はMPLS Echoの基盤を与える。RFC 9658はP2MP/MP2MP FEC Stackの既存subtypeを使いながら、address familyをMT IPまたはMT IPv6にし、Root LSR Addressへ{MT-ID, IPA}を加える。

これでprobeは「同じrootらしきもの」ではなく、特定のtopologyとalgorithmに属するtreeを指せる。だが成功のauthorityはbranch、時刻、probe semanticsに限られる。別のleafを通ったpacketも、customer multicastが継続したことも示さない。

tree-wide verdictにはbranch inventoryが必要だ。各leafについてFEC、label、replication entry、probe結果、counter、receiver観測を並べる。一枝の緑を全体へ塗り広げないことが、scopeを付けたRFCの意義を守る。

同じrootでも別のforwarding objectになる

RFC 6388はP2MP、MP2MP-up、MP2MP-downを定義する。RFC 9658ではMT-IDとIPAがFECの一部なので、root addressとopaque valueが同じでもtupleが違えば別のMP LSPになる。

RFC 7307のMT IP/MT IPv6 encodingに対し、RFC 9658は以前reservedだった16 bitsのうち8 bitsをIPAへ割り当てる。残るreserved octetは送信時zero、受信時ignoreである。RFC 9350のFlexible AlgorithmとIANA IGP registryがalgorithm側の意味を支える。

tupleは衝突を防ぐが、definition revisionまでは運ばない。同じIPA値を持つrouterが異なるlink attributeや制約を見ていれば、同名の計算から異なるbranchが生まれる。FEC bytesと同時にalgorithm定義、topology epoch、受理時刻を保存する必要がある。

Rootとbranchでscopeを二度使う

upstream LSRの選択では、signaled tupleが指定するsub-topologyでrootへのbest pathを求め、そのnext hopからLDP peerを選ぶ。default tableを誤用すれば、peer自体が正しくてもtreeは目的を外れる。

downstreamでは、neighborに到達するだけのinterfaceは候補にならない。同じsub-topologyに所属するときだけforwarding interfaceとして選べる。ここではphysical reachability、protocol adjacency、policy eligibilityを分離しなければならない。

receiptはcandidate interface、topology membership、採否理由、local label、replication entry、hardware commitを含む。完全停止より厄介なのはpartial treeである。多数のleafが動くため、欠けたbranchはaggregate counterの陰に隠れる。

Capabilityは実装の約束である

RFC 9658のMT Multipoint CapabilityはIANA LDP Parametersで0x0510である。session initializationで送れるほか、RFC 5561のDynamic Announcementがnegotiatedならsession中にもannounce/withdrawできる。

成功したnegotiationの後、speakerはtopology-scoped FECとforwarding setupをsupportしなければならない。これは有力なinteroperability factだが、特定FECの計算、label installation、replication programmingではない。

peer、session epoch、software build、S bit transitionを記録し、後続のstateへ結びつける。withdraw時には既存labelがどう処理されたかを別に示す。capabilityの時間とforwardingの時間を同一視してはならない。

WildcardとEnd-of-LIBも局所的である

RFC 5918のTyped Wildcard FECにより、特定FEC typeへ一括操作できる。RFC 9658はmultipoint typeについてMT IP/MT IPv6、IPA、MT-IDを含め、別sub-topologyのtreeを誤って巻き込まないようにする。

RFC 5919のEnd-of-LIBはlabel distributionの終端をpeerへ伝える。RFC 9658ではsub-topology単位のconvergenceを表現できる。

それでもEnd-of-LIBが閉じるのは一つのcontrol conversationである。IGP databaseの同一epoch、line card programming、packet forwardingは別のreceiptだ。「converged」と書くなら、peer、session、scope、revisionを同じ文に置くべきである。

PMSIのidentityからreceiverまでは距離がある

RFC 6514のMVPN PMSI Tunnel attributeはmLDP FECを運べる。RFC 9658を使う場合、tunnel identifierはMT-scoped MP FEC formになる。service routeとtransport treeを一つのtupleで相関できる。

しかしadvertisementはreplication stateではなく、receiver acknowledgementでもない。PMSI、FEC、root resolution、label、branch、probe、counter、受信結果を連結して初めてservice claimになる。

RFC 5036はLDPの基礎、RFC 5920はMPLS security frameworkを示す。authenticated peerからのmessageでも、stale topologyを持つ可能性はある。誰が語ったかとpacketがどこへ行ったかは別である。

Tupleを判決ではなくjoin keyとして使う

最小ledgerはalgorithm definitionとtopology revisionから始まる。capabilityとsessionが手続きの前提を示し、FEC bytesが対象を固定する。root lookupとinterface evaluationが計算結果を示し、labelとhardware stateがinstallationを示す。probe、counter、receiverが運用結果を閉じる。

Heng LuのMinimum Initial Specificationはtuple、revision、peer、interface、label、resultという共有可能な最小語彙を支える。reality layersはidentityがforwardingのauthorityを借りることを防ぐ。running-code primacyは実際の複製と受信に最終判断を戻す。

RFC 9658は意図したtreeを正確に指す。だからこそ、一枝のprobeは一枝のreceiptとして扱い、残りの枝に沈黙を強制してはならない。

Sources