| Internet-Draft | Metadata Constrained Dist | October 2025 |
| Dunbar & Retana | Expires 23 April 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.ietf-idr-5g-edge-service-metadata]. 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 [I-D.ietf-idr-5g-edge-service-metadata].¶
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 [RFC2119] [RFC8174] 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 [RFC7313] 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 [RFC4760] 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 [RFC4760] 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:¶
Reserved: MUST be transmitted as 0 and ignored when received.¶
Malformed MDF NLRI MUST be treated-as-withdraw [RFC7606]. 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 [RFC7606].¶
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 [RFC4684] 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 [RFC4684] and [I-D.ietf-idr-5g-edge-service-metadata].¶
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.¶
+------------------ Cloud / Core -----------------+
| |
| +--------+ +--------+ |
Apps/Services | | DC-A | | DC-B | |
(exports routes)| | (RR/PE)| | (RR/PE)| |
with RTs ---> | +---+----+ +---+----+ |
| | | |
+------------|--------------------|--------------+
| |
+---+----+ +--+---+
| 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.¶
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.¶