要約

  • RFC 9793は、BFRのホストプレフィックスにサブドメイン、BFR-ID、カプセル化、BIER Nexthopを載せ、BIFT計算に使うoptional transitiveなBGP Path Attribute 41を定義する。
  • 想定範囲は、複数ASを含み得る一つのAdministrative Domainと整合したBIER domainである。対応する境界ルータは、EBGP session/group単位の許可ポリシーを備え、既定値を不許可にしなければならない。
  • 不許可なら送信してはならず、受信した属性は静かに無視して他peerへ渡さない。到着した属性だけでは、越境権限、識別子の整合、BIFT/FIB実装、packet forwarding、service outcomeのどれも証明できない。

境界が拒むのは「壊れた属性」だけではない

RFC 9793の境界規則を理解するには、正しく符号化されたUPDATEを考えるとよい。IPv4 /32のBFR-prefixがあり、type code 41があり、Lengthが合い、BIER TLVのSub-domainとBFR-IDを読み取れる。構文上の異常はない。それでも管理境界では採用してはならない場合がある。

RFC 9793が定義するBIER属性はoptional transitiveである。IANAのBGP Parameters registryはcode 41をBIERとして登録し、関連するTLV/Sub-TLV registryを管理する。属性はAFI 1または2、SAFI 1、2または4のIPv4 /32、IPv6 /128ホストプレフィックスに付けられる。RFCは非ホストプレフィックスや他のAFI/SAFIへの適用を定義していない。

属性内の情報は単なる飾りではない。BFERは、参加する各BIER sub-domainについてTLVを広告し、BFR-IDとMPLSまたはnon-MPLSのカプセル化情報を示す。Label rangeまたはBIFT-id range、必要に応じてBIER Nexthopが入る。受信BFRは、その値とunicast FIBを合わせてBIFT entryを導く。

また、拡張性のための保存規則がある。未知または未対応のBIER TLV typeは保存・伝播され、未知であることだけを理由にNLRI全体をmalformed扱いしてはならない。non-BFRのBGP speakerも、BIER処理をせず属性付きrouteを再広告できる。この性質は、同じ管理範囲で新旧実装が共存するときに意味を持つ。

しかし、保存する能力は越境の権利ではない。Section 7は、BIER属性を理解するAD境界ルータに、EBGP sessionまたはgroupごとのallow policyを要求する。既定はNOT allowedである。不許可の場合、属性をそのpeerへ送ってはならない。peerから届いた場合は、unrecognized non-transitive attributeと同じように静かに無視し、他のBGP peerへ伝播しない。

transitiveは行政上の委任状ではない

RFC 4271では、未知のoptional transitive attributeは受理され、さらに渡されるときPartial bitを立てて保持され得る。未知のoptional non-transitive attributeは無視され、先へ送られない。RFC 9793は、BIER属性そのもののフラグを変えるのではなく、不許可の管理境界で後者の処理結果を指定している。

ここには重要な権限分離がある。送信側は属性を付けられる。BGPはそのbytesを運べる。受信側のparserは内容を理解できる。それでも、境界を開く決定は受信・送信それぞれのlocal policyに残る。Partial bitは意味の保管が不完全であることを表せても、誰が越境を承認したかは表さない。

さらに、Administrative DomainとAutonomous Systemは一対一とは限らない。RFC 9793はADが複数ASから構成され得ると明記する。RFC 8279も、特定のシナリオでEBGPをrouting underlayとして使えるとしている。したがってEBGP sessionは、同一運用権限内のAS間にも、別の管理主体との間にも存在し得る。

その違いをAS番号だけから推測できないからこそ、policyはsession/groupに結び付く。既定拒否は安全側の初期値であり、明示allowは運用者の分類結果である。ただしallowの設定それ自体は、分類が正しいことや両側の設計が整合していることを証明しない。

同じ数字が同じドメインを作るわけではない

BIER sub-domain IDは8 bitだが、世界共通の会員番号ではない。BFR-IDの一意性も、そのsub-domainの中で求められる。LabelやBIFT-id rangeは個別のカプセル化・割当文脈に属する。BIER Nexthopは計算先を示すが、peerの組織、契約、管理責任を認証しない。

RFC 9793は、通常loopbackであるBFR-prefixをBIERのためにAD外へ配布する必要はないと説明する。それがBIER属性付きで外へ出て、隣のADもBIERを使っていると、本来独立すべき二つのBIER domainが誤って結合され、相反するconfigurationによるsecurity riskとoperational troubleが生じ得る。

これは事故報告ではない。特定vendor、deployment、attack、outage、packet loss、誤配信を立証してはいない。文書が示すのは、ローカルに有効な名前が別の権限範囲へ出たとき、同じ値でも同じ意味を保証できないというfailure mechanismである。

data planeの境界も同じ方向を示す。RFC 8279では、BIER-encapsulated packetは一つのBIER domainから別のdomainへ直接通過できない。境界でdecapsulateしてmulticast flow overlayへ渡し、必要なら一方のBFERと他方のBFIRとして再び処理する。これは二つの文脈を明示的に受け渡す設計であり、control-plane namespaceを暗黙に融合する設計ではない。

計算結果までの証拠を一段ずつ残す

第一にdeclared stateがある。UPDATEに何が載っていたか。第二にparsed stateがある。どのTLVが構文・意味検査を通ったか。第三にauthorized stateがある。どのEBGP policyが何を許可したか。第四にcalculated stateがある。BFRがどのrouteとunicast FIBからどのBIFT候補を作ったか。その後にinstalled state、packet observation、receiver/service outcomeが続く。

RFC 9793は前半の処理を定義するが、後半を自動的に証明しない。非直結のBIER Nexthopへ使うtunnelの設定と選択はscope外である。control-plane entryはhardware programmingの証拠ではない。FIBはpacket pathの観測ではない。packet counterは期待するreceiverやapplication resultの証明ではない。

エラー処理も別問題だ。TLVのLength関係が壊れていれば、RFC 7606のattribute discardを行う。同じSub-domainのBIER TLVが複数あれば属性全体を無視する。同じBitStringLengthの重複やrange overlapは関連するencapsulation情報を無効にする。同一sub-domainで二つのprefixが同じnon-zero BFR-IDを名乗ればBIFT計算に使わない。border allowはこれらを正当化しない。

RFC 9793のverified erratum 8463は、Section 6の例でBFR2が使うべきものをBFR1のBFR-prefixからBFER1のBFR-prefixへ訂正した。この訂正は例のnexthopを正確にするが、Section 7の境界規則は変えない。RFC Editorの情報ページとIETF Datatrackerは文書のstatusを示すが、running configurationを示すものではない。