Path Attribute Outbound Route Filter (PA-ORF) for BGP-4

The Outbound Route Filtering framework defined in allows a BGP speaker to install route filtering information on a peer so that the peer can constrain its outbound route advertisements. Existing ORF types primarily operate on NLRI. They answer the question of whether a route should be advertised to a peer. Modern BGP deployments increasingly use Path Attributes to carry information whose semantics are more specific than the reachability information itself. Examples include tunnel information, Segment Routing information, service-specific metadata, and other attributes that are meaningful only within a particular domain or deployment context. When such attributes are Optional Transitive, they may propagate beyond their intended scope. This document defines a family of Path Attribute ORF (PA-ORF). PA-ORF extends the ORF model so that a receiving speaker can express preferences about the Path Attributes included in outbound UPDATE messages sent by its peer. The purpose is not to change the semantics of existing attributes, but to provide a dynamic and interoperable mechanism for limiting undesired attribute propagation.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The following terms are used in This document: AFI: Address Family Identifier, defined in BGP: Border Gateway Protocol, defined in ORF: Outbound Route Filter, defined in SAFI: Subsequent Address Family Identifier, defined in

BGP Path Attributes may carry information that is useful only inside a limited operational context. If such attributes are propagated outside that context, the receiving speaker may not need them, may not understand them, or may interpret them in a different context from that intended by the originator. This behavior is one form of Attribute Escape, which is described in detail in Operators can deploy local export policies to remove undesired attributes at administrative boundaries. However, those policies are locally configured, difficult to coordinate dynamically, and often vendor-specific. There is no standard mechanism by which a receiving speaker can request that a peer avoid sending a selected class of Path Attributes while continuing to advertise the associated NLRI.

PA-ORF follows the architectural model of . A speaker that does not want to receive certain attributes sends PA-ORF entries to its peer. The peer installs those entries as part of its outbound processing for that neighbor. When constructing UPDATE messages, the peer applies local export policy first and then applies PA-ORF before encoding the UPDATE. The default and preferred PA-ORF disposition is attribute stripping. Under this disposition, the route remains advertised, but the selected Path Attribute or selected component of a Path Attribute is omitted. Route suppression is also defined for cases where removing the attribute would make the advertisement semantically invalid.

PA-ORF support is advertised using the BGP Capability mechanism. The capability indicates, for each AFI/SAFI, whether the speaker is able to send PA-ORF entries, receive PA-ORF entries, or both. The capability is intentionally aligned with the ORF capability structure defined by so that an implementation can treat PA-ORF as a new ORF type rather than as a separate control protocol. A speaker MUST NOT send PA-ORF entries for an AFI/SAFI unless the peer has advertised that it is willing to receive PA-ORF entries for that AFI/SAFI. A speaker that has not negotiated PA-ORF for a given AFI/SAFI MUST ignore PA-ORF information received for that AFI/SAFI. The PA-ORF capability value is encoded as follows:

The Send/Receive field uses the same model as :

A PA-ORF Type identifies a specific kind of attribute filter. This document defines four initial PA-ORF Types:

Although the capability permits per-type negotiation, an implementation that supports this specification SHOULD support Type TBD1. Support for Types TBD2, TBD3, and TBD4 is OPTIONAL unless required by a deployment profile or a future specification.

PA-ORF entries are carried in the ROUTE-REFRESH message using the ORF extension model defined by . The ROUTE-REFRESH message identifies the AFI/SAFI to which the PA-ORF information applies and contains one or more PA-ORF entries. The PA-ORF information is scoped to the BGP session and to the AFI/SAFI indicated in the ROUTE-REFRESH message. A PA-ORF entry for one AFI/SAFI MUST NOT affect UPDATE messages for another AFI/SAFI. The high-level encoding is:

The When-to-refresh field follows the . A value of IMMEDIATE requests that the advertising speaker apply the new PA-ORF state and refresh the affected outbound advertisements. A value of DEFER allows the advertising speaker to install the PA-ORF state without immediately refreshing the affected routes.

Each PA-ORF entry begins with a common header followed by type-specific information. The common header provides the operation to perform, the match semantics, the disposition to apply, and a sequence number used for ordering.

The Action(2bits) field defines how the receiving speaker wants the entry to affect the peer's PA-ORF state:

The Match(1bit) field defines whether the type-specific information describes attributes to permit or deny: ADD . REMOVE REMOVE-ALL

The Disposition(2 bits) field defines the behavior applied to matching attributes:

ATTRIBUTE-STRIP is the default disposition and SHOULD be used unless the sender determines that removing the attribute would make the UPDATE invalid or would create misleading semantics. If a selected sub-component is removed and the containing attribute becomes empty or invalid according to the attribute specification, the containing attribute MUST be removed. If removing the containing attribute would make the route advertisement semantically invalid, local policy determines whether the route is suppressed. The Sequence field is used to order PA-ORF entries of the same PA-ORF Type within the same AFI/SAFI. Lower sequence values are evaluated before higher sequence values unless local policy specifies otherwise. Sequence values are significant only within the PA-ORF state installed by the same peer for the same AFI/SAFI and PA-ORF Type.

The Path Attribute Type Filter ORF provides coarse-grained control over complete BGP Path Attributes. It is used when the receiving speaker wants to suppress or strip an entire attribute identified by its BGP Path Attribute Type Code. The type-specific information for an Attribute Type Filter is:

The Attribute Type Code is the value assigned by IANA in the BGP Path Attributes registry. A DENY entry with ATTRIBUTE-STRIP disposition requests that the advertising speaker omit the specified attribute from outbound UPDATE messages for the relevant AFI/SAFI. This filter is suitable for attributes whose presence is entirely unwanted by the receiving speaker. For example, a receiving speaker at an inter-domain boundary may want to receive the reachability information but not receive a domain-specific Segment Routing attribute. Attribute Type Filter allows the NLRI to remain visible while removing the attribute semantics that should not cross the boundary. If the specified attribute is mandatory for the route advertisement or cannot be safely removed according to the attribute specification, the advertising speaker MUST NOT generate an invalid UPDATE. In that case, the advertising speaker SHOULD either suppress the route to the peer or apply local policy. The decision is local because the advertising speaker remains authoritative for its outbound routing behavior.

Some BGP Path Attributes are containers for more specific semantic elements. Examples include attributes that carry TLVs, tunnel types, community structures, encapsulation information, or service-specific sub-elements. Removing the entire attribute may be too coarse, because the receiving speaker may want to suppress only one sub-element while preserving other information carried by the same attribute. The Path Attribute Subtype Filter ORF provides this finer granularity. The type-specific information is:

The Attribute Type Code identifies the parent BGP Path Attribute. The Selector Type identifies the namespace in which the selector is interpreted. The Selector Length gives the length of the Selector Value. The Selector Value identifies the sub-element to match. This document defines the following initial Selector Types:

When a subtype selector matches a sub-component, ATTRIBUTE-STRIP removes only the matching sub-component. The advertising speaker then validates the resulting attribute. If the parent attribute remains valid, it may be advertised with the remaining sub-components. If the parent attribute becomes empty or invalid, the parent attribute MUST be removed. If the route would become invalid or misleading without the parent attribute, the advertising speaker applies local policy or suppresses the route. Attribute Subtype Filter is especially useful for attributes such as Tunnel Encapsulation, where the receiving speaker may accept one encapsulation type but reject another. It avoids unnecessary loss of useful attribute information while still limiting propagation of unwanted semantics.

Unknown Optional Transitive attributes present a specific operational problem. BGP is designed so that a speaker that does not recognize an Optional Transitive attribute can propagate it. This behavior supports incremental deployment, but it also means that unknown attributes may cross administrative boundaries without any speaker on the path understanding their semantics. The Unknown Path Attribute Filter ORF allows a receiving speaker to request that the advertising speaker remove unknown attributes that match selected flag conditions. The type-specific information is:

The Attribute Flags Mask identifies which bits in the BGP Attribute Flags field are significant. The Attribute Flags Value identifies the required values for those bits. A common use is to match attributes whose Optional and Transitive bits are both set. This filter applies only to attributes unknown to the advertising speaker at the point of outbound processing. If the advertising speaker recognizes the attribute, then Attribute Type Filter or Attribute Subtype Filter is more precise and SHOULD be used. The advertising speaker MUST NOT corrupt the Partial bit semantics of an attribute that it continues to propagate. If an unknown attribute is stripped, it is simply omitted from the outbound UPDATE to the requesting peer. If local policy requires preservation of unknown transitive attributes, local policy overrides the PA-ORF request. This ORF type is intended for administrative boundaries, route servers, inter-domain route reflection designs, and other locations where operators want to reduce propagation of attributes whose semantics are not explicitly supported.

The Path Attribute Propagation Scope Filter ORF provides a mechanism for a speaker to associate a propagation constraint with a specific Path Attribute or a specific component of a Path Attribute that it sends to a peer. Unlike the Attribute Type Filter, which is used by a receiving speaker to request that an attribute not be sent to it, the Attribute Propagation Scope Filter is used to express that an attribute may be sent to the peer but should not be further propagated beyond an indicated scope. The type-specific information is:

The Attribute Type Code identifies the parent BGP Path Attribute to which the propagation constraint applies. The Propagation Scope identifies the boundary beyond which the matching attribute or matching sub-component should not be propagated. The Propagation Action identifies the behavior to apply when advertising beyond that scope. The optional selector fields allow the constraint to apply to a sub-component of the parent attribute rather than to the entire attribute. If Selector Length is zero, the constraint applies to the entire parent attribute and the Selector Value field is absent. This document defines the following initial Propagation Scope Values:

This document defines the following initial Propagation Action values:

The Attribute Propagation Scope Filter is cooperative. A speaker that accepts this PA-ORF Type from a peer agrees to apply the installed propagation constraint when re-advertising routes received from that peer, unless overridden by local policy. A speaker that does not want a peer to influence downstream propagation behavior SHOULD NOT advertise willingness to receive this PA-ORF Type. The Attribute Propagation Scope Filter is cooperative. A speaker that accepts this PA-ORF Type from a peer agrees to apply the installed propagation constraint when re-advertising routes received from that peer, unless overridden by local policy. A speaker that does not want a peer to influence downstream propagation behavior SHOULD NOT advertise willingness to receive this PA-ORF Type. The selector fields reuse the selector semantics defined for the Attribute Subtype Filter. This allows a propagation constraint to be applied to a specific tunnel type, TLV, community subtype, or other sub-component rather than to the entire Path Attribute. For example, a speaker may allow a Tunnel Encapsulation Attribute to be propagated but constrain a specific tunnel type to a bilateral scope. The Path Attribute Propagation Scope Filter ORF is intended to address the root of many Attribute Escape scenarios. It allows the originator or sender of a domain-specific attribute to communicate the intended propagation boundary to a peer in a dynamic and interoperable manner. It does not impose mandatory routing policy across administrative boundaries unless the receiving speaker has explicitly negotiated and accepted this PA-ORF Type.

PA-ORF is applied by the advertising speaker during construction of outbound UPDATE messages for the peer that installed the PA-ORF entries. The intended processing order is:

This order is important. PA-ORF is not a replacement for local policy. The advertising speaker first determines whether a route is eligible for advertisement according to its own policy. Only after the route is otherwise eligible does PA-ORF influence the attributes included in the outbound UPDATE. A PA-ORF rule received from a peer MUST NOT cause the advertising speaker to advertise an attribute that local policy would otherwise suppress. Similarly, PA-ORF MUST NOT cause the advertising speaker to advertise a route that local export policy would otherwise deny. The receiving speaker can request less information, but it cannot require the advertising speaker to send more information. When a PA-ORF entry matches an attribute, the advertising speaker applies the disposition associated with the first applicable entry according to the ordering rules. If no PA-ORF entry matches, the route is advertised according to local export policy and normal BGP attribute processing. An implementation MAY optimize PA-ORF processing by indexing entries by attribute type, subtype selector, or scope. Such optimization MUST NOT change the externally visible behavior of the ordered rule evaluation.

PA-ORF uses Route Refresh to install, modify, and remove outbound attribute filtering state. This reuses existing BGP machinery and avoids defining a separate policy transport channel. When a speaker sends PA-ORF entries with immediate refresh semantics, the receiving peer installs the entries and recomputes the affected Adj-RIB-Out state for that AFI/SAFI. The peer then sends updated advertisements reflecting the new PA-ORF state. The refresh may include routes whose attributes have changed because selected attributes were stripped, routes that are newly suppressed, and withdrawals for routes no longer advertised as a result of the new policy. When deferred refresh semantics are used, the peer installs the PA-ORF entries but is not required to immediately refresh affected routes. Deferred refresh is useful when a receiving speaker intends to install multiple filters and wants to avoid repeated recomputation or repeated UPDATE bursts. If the BGP Enhanced Route Refresh procedures are supported, the advertising speaker SHOULD use Begin-of-RIB-Refresh and End-of-RIB- Refresh markers when performing an immediate refresh. This allows the receiving speaker to identify the refresh boundary and distinguish policy-induced updates from unrelated routing changes. PA-ORF state is session state. Unless explicitly preserved by a future extension, PA-ORF state is removed when the BGP session is reset. After a session is re-established, PA-ORF entries MUST be re-advertised if the receiving speaker still wants them applied.

PA-ORF can express both PERMIT and DENY entries. Conflicts are resolved through ordered evaluation using the Sequence field. An implementation MUST evaluate entries of the same PA-ORF Type, same AFI/SAFI, and same installing peer in ascending Sequence order unless local policy specifies a stricter behavior. The first matching entry determines the disposition. If no entry matches, the attribute is processed according to local export policy and normal BGP rules. When entries of different PA-ORF Types apply to the same attribute, more specific filters SHOULD take precedence over less specific filters. The precedence is:

This precedence reflects the fact that subtype-level matching is more precise than whole-attribute matching, and whole-attribute matching is more precise than general unknown or scope-based matching. Local policy MAY override this precedence. However, implementations SHOULD provide deterministic behavior and SHOULD expose the effective PA-ORF rule order to operators for troubleshooting.

PA-ORF is intended to improve operational safety and therefore MUST NOT introduce unnecessary session resets. A malformed PA-ORF entry MUST NOT cause the BGP session to be reset. The receiving speaker SHOULD ignore the malformed entry and SHOULD log the event. If a PA-ORF message contains an unsupported PA-ORF Type that was not negotiated for the AFI/SAFI, the unsupported type MUST be ignored. Other valid PA-ORF entries in the same Route Refresh message MAY be processed. If an Attribute Subtype Filter contains a Selector Length that is inconsistent with the remaining message length, the entry is malformed and MUST be ignored. If the Selector Type is unknown, the entry MUST be ignored unless local policy explicitly provides a mapping for that selector. A REMOVE operation that does not match an installed entry MUST be silently ignored. A REMOVE-ALL operation applies only to PA-ORF state installed by the peer through PA-ORF and MUST NOT remove local export policy or operator-configured attribute filters. If applying ATTRIBUTE-STRIP or STRIP-BEYOND-SCOPE would result in an invalid BGP UPDATE, the advertising speaker MUST NOT send the invalid UPDATE. The speaker MAY suppress the route, apply a different locally configured disposition, or retain the original attribute if local policy requires it. In all cases, the speaker remains responsible for generating valid BGP messages.

PA-ORF gives a receiving speaker a dynamic way to request less attribute information from a peer. Operators should treat PA-ORF as a cooperative mechanism, not as a substitute for explicit policy at important administrative boundaries. Implementations SHOULD allow operators to configure which peers are allowed to install PA-ORF entries and which PA-ORF Types are accepted from each peer. For example, an operator may accept Attribute Type Filters from a customer peer but reject Unknown Attribute Filters or Scope Filters from the same peer. Operators should also consider update churn. Installing a broad PA-ORF entry with immediate refresh may cause many routes to be re-advertised. Deferred refresh can reduce churn when multiple policy changes are expected. PA-ORF can interact with add-path, route reflection, confederations, route servers, and inter-AS VPN designs. The PA-ORF state is neighbor-specific. A route reflector or route server that receives PA-ORF entries from one client applies those entries only when constructing outbound advertisements to that client or when enforcing accepted propagation constraints for routes received from that client. The entries do not automatically affect advertisements to other clients except where a negotiated Attribute Propagation Scope Filter explicitly applies to re-advertisement behavior.

PA-ORF affects outbound routing information sent by a BGP speaker. If accepted from an untrusted or unauthorized peer, PA-ORF could be used to remove attributes needed for correct forwarding, suppress routes, or hide policy-relevant information. Therefore, a speaker SHOULD accept PA-ORF only from peers that are authorized to influence outbound attribute filtering. PA-ORF MUST NOT override locally configured export policy. The advertising speaker retains final authority over what it advertises. A peer can request that fewer attributes be sent, but it cannot force the advertising speaker to send attributes or routes that local policy would otherwise block. Implementations SHOULD provide logging and operational visibility for installed PA-ORF entries. Operators need to determine whether an attribute was removed because of local policy, PA-ORF, or attribute validation rules. PA-ORF does not change the security properties of the underlying BGP session. Existing protections for BGP sessions, including transport security and peer authentication mechanisms where deployed, remain applicable.

IANA is requested to allocate four new ORF Types from the BGP ORF Types registry:

IANA is requested to create a new registry titled "BGP Path Attribute ORF Dispositions". The registration policy is Standards Action.

IANA is requested to create a new registry titled "BGP Path Attribute ORF Selector Types". The registration policy is Standards Action. IANA should make initial assignments as follows:

IANA is requested to create a new registry titled "BGP Path Attribute ORF Propagation Scope Values". The registration policy is Standards Action. IANA should make initial assignments as follows:

IANA is requested to create a new registry titled "BGP Path Attribute ORF Propagation Action". The registration policy is Standards Action. IANA should make initial assignments as follows:

TBD

TBD.