Summary

  • RFC 9793 defines optional-transitive BGP path attribute 41 so BFR-prefix advertisements can carry sub-domain, BFR-ID, encapsulation and BIER-next-hop information used in BIFT calculation.
  • The specification assumes one BIER domain aligned with one administrative domain, even if that administrative domain contains several autonomous systems. A supporting boundary router must deny the attribute on an EBGP session or group by default.
  • When disallowed, an outbound BIER attribute must not be sent; an inbound one must be quietly ignored and not propagated. Receipt proves only that bytes arrived, not that the neighbor was authorized, namespaces agree, forwarding was installed or multicast service worked.

A valid attribute can still be inadmissible

The interesting packet is not malformed. Its BGP UPDATE can carry a syntactically correct BIER path attribute, the right type code, a host prefix, plausible lengths and recognizable TLVs. A border router can parse all of it and still be required to refuse it as BIER input.

That is the operational clarity in RFC 9793. The document defines the BIER attribute as optional and transitive. Within its intended scope, that choice lets BGP carry BIER-specific information through speakers that may not themselves perform BIER forwarding. A non-BFR can re-advertise a route with the attribute unchanged. A BFR can use or update BIER-next-hop and encapsulation information under detailed rules. Yet Section 7 says the signaling is for a single Administrative Domain and places a different disposition at its edge.

For a boundary router that supports the attribute, policy must be configurable per EBGP session or group. The default is that the BIER attribute is not allowed. When that policy says no, the router must not export the attribute to the peer. If the peer sends one anyway, the router must treat it exactly as an unrecognized optional non-transitive attribute: ignore it quietly and do not pass it to other BGP peers.

The rule is easy to misread. RFC 9793 does not redefine type 41 as non-transitive. RFC 4271 still supplies the ordinary distinction: an unknown optional-transitive attribute may be retained and propagated with the Partial bit, whereas an unknown optional non-transitive attribute is ignored. RFC 9793 borrows the latter handling result at a disallowing boundary. The attribute remains transitive for its designed intra-domain use; administrative admission overrides what the generic flag might otherwise encourage at the edge.

What type 41 actually declares

The IANA BGP Parameters registry assigns code 41 to BIER and maintains the related TLV and sub-TLV registry. In RFC 9793, the attribute is attached to an IPv4 /32 or IPv6 /128 host-prefix NLRI for AFI 1 or 2 and SAFI 1, 2 or 4. The host prefix identifies a BFR; the BIER TLV associates a sub-domain with a BFR-ID and encapsulation data. MPLS forms carry a label range; non-MPLS forms carry a BIFT-id range; either can carry a BIER Nexthop.

These fields are potent because they feed a calculation. For each sub-domain, a receiving BFR examines BFR-prefixes with a matching BIER TLV. A non-zero BFR-ID can produce or update a BIFT entry. The BIER Nexthop, or a defined fallback when it is absent, supplies the BFR neighbor. The advertised label or BIFT-id range supplies encapsulation input. The result is joined to the unicast forwarding information from the routing underlay.

But each verb has a boundary. The UPDATE declares values. Parsing establishes that a particular receiver accepted their syntax. Policy establishes whether they may be used across this particular border. Calculation derives candidate BIFT state. None of those facts alone proves that hardware or software installed the intended entry, that a tunnel selected outside the RFC's scope exists, that a BIER packet followed it, or that the intended receivers obtained a usable multicast service.

RFC 7606 helps keep error handling separate from admission. If RFC 9793's TLV length checks fail, the required response is attribute discard. Semantic contradictions have their own scoped rules: duplicate sub-domain TLVs can invalidate the whole attribute; repeated bit-string lengths or overlapping ranges can invalidate particular encapsulation information; two prefixes declaring the same non-zero BFR-ID in one sub-domain must not be used for BIFT calculation. A clean parse does not answer the policy question, and a policy exception does not erase the semantic checks.

An administrative domain is not necessarily one AS

The border in RFC 9793 is not simply every line between two autonomous-system numbers. The document assumes the BIER domain is aligned with an Administrative Domain, and it expressly says that the Administrative Domain may contain multiple Autonomous Systems. EBGP may therefore appear inside the intended domain, just as the BIER architecture allows EBGP to act as a routing underlay in some scenarios.

That detail explains why the policy is attached to an EBGP session or group rather than hard-wired to “all EBGP”. An operator needs to identify which external sessions remain inside the same administrative authority and which cross into a separately controlled domain. The default still fails closed. The exception is local and explicit because the architecture cannot infer governance from an AS boundary, a route's presence or a neighbor's ability to encode type 41.

This is also why “we received it” is such weak evidence. It might show that a peer exported an attribute. It does not show who approved that export, whether the receiving side enabled the matching exception, whether both ends meant the same sub-domain number, whether BFR-IDs are unique across the intended scope, or whether label and BIFT-id allocations collide. The UPDATE carries data; it does not carry the contract that makes two operational namespaces compatible.

The wrong join is a configuration problem before it is a traffic story

RFC 9793 states the risk carefully. BFR-prefixes are typically loopbacks distributed through the Administrative Domain and are not needed outside it for BIER purposes. If they leave with the BIER attribute attached, and the neighboring administrative domain also deploys BIER, two domains intended to be independent may be incorrectly joined. Their configurations are likely to conflict, creating security risks and operational trouble.

The RFC does not report that this happened in a particular network. It does not identify a vendor, attack, outage, packet loss or customer impact. The useful conclusion is structural: the same field values can be locally valid and globally ambiguous. Sub-domain 0 is a domain-local designation, not a worldwide membership list. A BFR-ID is unique within its sub-domain, not universally. A label or BIFT-id range is meaningful under a particular encapsulation and allocation context. A BIER Nexthop says where a calculation points; it does not authenticate the organization behind the peer.

The data-plane boundary in RFC 8279 reinforces that separation. A BIER-encapsulated packet cannot pass directly from one BIER domain into another. At the boundary it is decapsulated and handed to the multicast flow overlay; a router can act as BFER for the first domain and BFIR for the next. That is a deliberate handoff between two forwarding contexts, not evidence that their control-plane identifiers should be fused.

Preservation inside, containment at the edge

RFC 9793 also distinguishes extensibility from indiscriminate reach. Unknown or unsupported TLV types inside a BIER attribute must be preserved and propagated, and their mere presence must not make the attribute malformed. That rule protects future extension through a compatible BIER signaling environment. It does not cancel the outer administrative filter. A domain can preserve information it does not yet understand while still refusing to import the whole BIER assertion from an unauthorized neighboring domain.

The verified RFC 9793 erratum illustrates the need for exact reading. Erratum 8463 changes one Section 6 example so BFR2 uses BFER1's BFR-prefix, not BFR1's, when the route from BFER1 contains no BIER Nexthop. The correction matters to that example, but it does not change the Section 7 default-deny rule. Operations should track both the published text and verified errata without converting either into evidence that a network has implemented the corrected behavior.

The RFC Editor information page and IETF Datatracker record establish the document's Standards Track status and history. Status tells readers what the document is. It does not tell them who deployed it, which policies are active, or what happened to traffic.