Futurewei

Dallas, TX USA ldunbar@futurewei.com

Futurewei

USA aretana@futurewei.com

This document defines the Metadata-Filter (MDF) Subsequent Address Family Identifier (SAFI). A BGP speaker uses MDF to signal its lack of interest in receiving service metadata attributes on routes that carry specified Route Targets (RTs), while leaving reachability unchanged.

Service Metadata can be added to BGP UPDATEs to make path selections not only based on the routing cost but also the running environment of the edge services . These attributes can proliferate per service and churn rapidly. Ingress nodes may have constrained control-plane resources, and may not need nor be able to efficiently process large, fast-changing metadata on every route. In typical iBGP topologies with Route Reflectors, edge nodes can advertise routes with service metadata without direct knowledge of which ingress nodes will receive and use information. Receivers therefore need a way to decline metadata for uninterested classes while continuing to receive reachability. The Metadata-Filter (MDF) SAFI provides a mechanism for a receiver to signal its lack of interest in service metadata for routes that carry specified Route Targets (RTs). In turn, the RR removes the specific attributes from the affected UPDATEs and continues to process the message accordingly. The signaling of a node's interest (or lack thereof) in metadata is dynamic. MDF allows ingress nodes adjust metadata delivery as service placement changes, while keeping reachability intact.

The reader is expected to be familiar with the terminology defined in . 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.

A node that doesn't need to receive service metadata for routes tagged with a given Route Target (RT) signals its peer by advertising an MDF NLRI (AFI=IPv4/IPv6, SAFI=TBD-MDF) that encodes the specific RT. Upon receiving this MDF NLRI, the receiver removes the service metadata attributes from any UPDATE that carries the RT when advertising to that peer, while leaving reachability and other attributes unchanged. The MDF state persists until the sender withdraws the MDF NLRI or the BGP session resets. Support for Enhanced Route Refresh is RECOMMENDED to facilitate on-demand resynchronization.

A BGP speaker that is able to receive the MDF NLRI MUST use the Multiprotocol Extensions Capability Code to advertise the corresponding (AFI, SAFI) pair (AFI=1|2, SAFI=TBD-MF).

The MDF NLRI is encoded in MP_REACH_NLRI and MP_UNREACH_NLRI attributes with (AFI=IPv4|IPv6, SAFI=TBD-MDF). The Length of Next Hop Network Address MUST be set to 0. The MDF NLRI is formatted as follows: Number of octets that follow. Reserved: MUST be transmitted as 0 and ignored when received. Route Target value, identical to the prefix structure of the Route Target membership NLRI : origin as (4) | route target (8).

Malformed MDF NLRI MUST be treated-as-withdraw . The session MUST NOT be reset because of a malformed MDF NLRI. If the errors are persistent, an implementation MAY use the AFI/SAFI disable approach .

A peer signals "omit metadata for RT=64512:100". The receiving peer advertises routes carrying RT=64512:100 to this peer without service metadata. UPDATE Path Attributes: ORIGIN: IGP AS_PATH: (iBGP) MP_REACH_NLRI (AFI=IPv4, SAFI=TBD-MDF) NLRI: Metadata Filter NLRI: Length: 13 Flags: 0 Entity: RT 64512:100

RTC constrains which routes are sent to a peer based on RT interest. The MDF SAFI mirrors this architectural pattern but constrains which service metadata attributes are attached to routes that are sent. The two are complementary and can be deployed together: RTC limits route flooding and MDF limits metadata propagation.

In this specification, Route Targets (RTs) can be used to delineate service classes, not merely membership. Each group of routes can have multiple RTs to, for example, identify a VPN or customer grouping, indicate reachability or constrain membership, or identify routes carrying particular service characteristics. MDF then keys on the service class to control delivery of service metadata.

Operators SHOULD define a small, stable set of service classes per customer, application, or administrative domain. Advertised routes may be tagged with both: a base RT (for normal reachability and membership), and the service class that denotes the class whose routes may carry service metadata. Nodes that use metadata simply do not install MDF and therefore receive the service metadata on those routes. Nodes that do not use metadata install MDF so the sender omits the metadata while leaving reachability unchanged. Example (illustrative): A DC exporter advertises 10.0.0.0/24 with RT-VPN=64512:100 and RT-ULL=64512:200, attaching the Metadata Path Attribute. The RR advertises the route with metadata to peers that do not have MDF[64512:200] and advertises the same route without metadata to peers that do.

If multiple RTs are used (as above), RTC SHOULD remain keyed to the base RT(s) so that reachability distribution is unaffected by MDF usage. The service class RT is used for MDF matching.

A pragmatic introduction plan is: Define service class RTs and add them to exporter policy alongside the other existing RTs. Enable MDF on RRs; verify that peers receive metadata unchanged. Opt-out ingress nodes that do not use metadata by installing MDF; validate that reachability persists and metadata is omitted. Broaden coverage to additional service classes only as needed; keep the service-class RT set small and well documented.

While MDF focuses on RT assignment and filtering of metadata, implementations should expose minimal telemetry for validation: count of MDF entries per peer, advertisements with metadata omitted, and last-change timestamps.

IANA is requested to allocate a new SAFI from the "SAFI Values" registry: Name: Metadata-Filter (MDF) Reference: This document

This document introduces no new security vulnerabilities beyond those discussed in and . The Metadata Filter can reveal preference intent or limitations of specific nodes. To limit exposure, deployment should primarily occur in iBGP, and the peers that may advertise MDF entries should be limited. Omission of metadata does not affect reachability but can affect path selection at the receiver; operators should audit Metadata Filter policy and enable change logging. Ignoring an MDF NLRI may result in processing unnecessary metadata and cause undue resource consumption.

In 5G deployments, multiple User Plane Functions (UPFs) or edge gateways anchor PDU sessions near users while distributed edge data centers host application workloads. BGP advertises reachability for these workloads, and may carry service metadata so ingress nodes can consider service conditions in addition to routing metrics when selecting paths. Service metadata can churn rapidly and inflate UPDATEs if flooded to all peers. Many ingress nodes (e.g., UPFs handling best-effort traffic) neither need nor can efficiently process such rapidly changing attributes. The Metadata-Filter (MDF) SAFI allows a receiver to signal its lack of interest in metadata associated with specific Route Targets (RTs). Upon receiving an MDF NLRI, a Route Reflector (RR) omits the matching metadata for that peer while preserving reachability. MDF signaling is dynamic: ingress nodes can add or withdraw MDF entries as service placement evolves, allowing networks to adapt metadata delivery without impacting route availability.

| +---+----+ +---+----+ | | | | | +------------|--------------------|--------------+ | | +---+----+ +--+---+ | RR | | RR | +---+----+ +--+---+ | | MDF[RT=ULL] ----> | | | | +----+----+ +--+----+ | UPF-1 | | UPF-2 | +---------+ +-------+ - DC-A/DC-B advertise routes tagged with a base RT (VPN/customer) and a service-class RT (e.g., RT=ULL). - UPF-1 sends MDF NLRI for RT=ULL: RR omits metadata on routes with RT=ULL when advertising to UPF-1. - UPF-2 does not send MDF: it receives routes with metadata unchanged. ]]>

Operators define a small, stable set of service-class RTs to delineate which groups of routes may carry service metadata (e.g., ultra-low-latency vs. best-effort). Exporters tag routes with both a base RT (for reachability/membership) and a service-class RT. MDF then keys on the service-class RT to control metadata delivery, while RTC (RFC 4684) and normal import/export policy remain keyed to the base RT so reachability is unaffected.

1. Define service classes: Choose a minimal set of RTs representing classes that may carry metadata (e.g., RT-ULL, RT-VID, RT-ML). Document ownership and intended use.
2. Tag exports: Data center exporters attach a base RT (VPN/customer) and a service-class RT to the same NLRI when metadata may accompany the route.
3. Enable MDF on RRs: RRs support the MDF SAFI and omit metadata per-peer when an MDF NLRI matches the service-class RT.
4. Ingress selection: UPFs/ingress nodes that do not use metadata advertise MDF NLRIs for the relevant service-class RTs; nodes that need metadata do not send MDF.
5. Adjust dynamically: As UE placement or service location changes, ingress nodes add/withdraw MDF entries to tune metadata reception over time.
6. Telemetry (recommended): Expose per-peer MDF entry counts, “metadata omitted” counters, and last-change timestamps to validate behavior.

• Control-plane scale: Limits fast-changing metadata propagation to UPFs and routers directly attached to UPFs, reducing UPDATE size and processing load on Route Reflectors and Provider Edge routers while preserving full reachability.
• Service agility: Supports dynamic changes in metadata subscription as new UEs (for example, drones or autonomous vehicles) roam into or away from UPFs. When a UE moves to a new UPF, that UPF can dynamically express interest in receiving metadata needed for optimal path selection; when the UE leaves, the UPF withdraws its interest, preventing unnecessary metadata distribution.
• Operational safety: Receiver-driven and RT-scoped; enables incremental rollout without impacting route propagation for other peers or service classes.

MDF complements RTC: RTC constrains route flooding; MDF constrains metadata attachment to those routes for specific peers :contentReference[oaicite:7]{index=7}. MDF is carried in MP\_REACH/MP\_UNREACH with AFI=IPv4|IPv6 and a dedicated SAFI; the Next Hop length is 0 for MDF NLRIs.