IDR Working Group A. Wang Internet-Draft China Telecom Intended status: Experimental 14 October 2026 Expires: 17 April 2027 Source-Directed Propagation of VPN Prefix ORF for BGP-4 draft-wang-idr-vpn-prefix-orf-propagation-00 Abstract The Virtual Private Network (VPN) Prefix Outbound Route Filter (ORF) [I-D.ietf-idr-vpn-prefix-orf] mechanism allows a Border Gateway Protocol (BGP) speaker to request that an adjacent peer filter matching VPN routes. In deployments using Route Reflectors (RRs) or Autonomous System Border Routers (ASBRs), the adjacent peer may not be the source of the affected routes. This document specifies when an intermediate router may send an ordinary VPN Prefix ORF to the upstream peer from which the affected routes were received. Upstream transmission is permitted only after the intermediate router determines that no relevant downstream router requires the affected routes. This document also defines an Interest Query/Response procedure for making that determination. Status of This Memo 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 17 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Wang Expires 17 April 2027 [Page 1] Internet-Draft source-propagation-ORF October 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Determination from Received VPN Prefix ORFs . . . . . . . 5 4.2. Query-Based Determination . . . . . . . . . . . . . . . . 5 5. Interest Query/Response Capability . . . . . . . . . . . . . 5 6. Relevant Downstream Routers . . . . . . . . . . . . . . . . . 6 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Downstream Router . . . . . . . . . . . . . . . . . . . . 6 7.2. Intermediate Router . . . . . . . . . . . . . . . . . . . 6 7.3. Upstream Router . . . . . . . . . . . . . . . . . . . . . 7 7.4. Interest Query/Response Procedure . . . . . . . . . . . . 7 8. State Changes . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Interest Query and Interest Response Encoding . . . . . . . . 7 9.1. Interest Query . . . . . . . . . . . . . . . . . . . . . 8 9.2. Interest Response . . . . . . . . . . . . . . . . . . . . 9 9.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 10. Operational Considerations . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12.1. Capability Code . . . . . . . . . . . . . . . . . . . . 10 12.2. BGP Route Refresh Subcodes . . . . . . . . . . . . . . . 10 12.3. VPN Prefix ORF Interest States . . . . . . . . . . . . . 11 13. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 11 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 15.2. Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction [I-D.ietf-idr-vpn-prefix-orf] defines a VPN Prefix ORF that a receiver can send to the peer advertising excessive VPN routes. The peer then filters matching routes toward that receiver. Wang Expires 17 April 2027 [Page 2] Internet-Draft source-propagation-ORF October 2026 In an RR or inter-AS topology, the peer receiving the ORF may be an intermediate router. Applying the ORF only on the downstream session protects the overloaded receiver but does not reduce the corresponding state on upstream sessions. The intermediate router can reduce that state by sending an equivalent VPN Prefix ORF upstream, provided that doing so does not remove routes still required by another downstream router. This document defines procedures for that determination. The VPN Prefix ORF sent upstream is an ordinary VPN Prefix ORF. This document defines neither a new ORF Type nor a propagation-specific VPN Prefix ORF encoding. "Upstream" and "downstream" are relative to the direction of VPN route advertisement. VPN routes flow from upstream to downstream; VPN Prefix ORFs flow in the reverse direction. 1.1. Requirements Language 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. 2. Terminology This document uses the terminology of [I-D.ietf-idr-vpn-prefix-orf]: * Affected Routes: VPN routes matching a VPN Prefix ORF entry. * Upstream Router: A BGP speaker from which the affected routes are received. * Downstream Router: A BGP speaker to which the affected routes are advertised. * Intermediate Router: A router, such as an RR or ASBR, that receives the affected routes from an upstream router and advertises them to downstream routers. * Relevant Downstream Router: A downstream router to which the intermediate router has advertised, or may advertise, the affected routes. * Interest Query: A request asking whether a downstream router requires any route in the affected route set. Wang Expires 17 April 2027 [Page 3] Internet-Draft source-propagation-ORF October 2026 * Interest Response: A response indicating INTERESTED, UNINTERESTED, or UNKNOWN. 3. Problem Statement Consider the following intra-Autonomous System (intra-AS) topology. The Provider Edge (PE) routers are connected to the RR as follows: +---------+ +-----------+Source PE| | +---------+ | +-++ +-----------------+RR+--------------------+ | ++-+ | | | | | | | +------+-----+ +-----+------+ +------+-----+ |Receiver PE1| |Receiver PE2+ |Receiver PE3+ +------------+ +------------+ +------------+ affected VPN routes: Receiver PE1/PE2/PE3 <-- RR <-- Source PE VPN Prefix ORF: Receiver PE1 --> RR --> Source PE Figure 1 VPN Prefix ORF Propagation Scenario Receiver PE1 can send a VPN Prefix ORF to the RR. The RR can then stop advertising matching routes to Receiver PE1. The RR MUST NOT send an equivalent VPN Prefix ORF to the Source PE unless it has determined that Receiver PE2 and Receiver PE3 also do not require the affected routes. 4. Design Overview An intermediate router first processes a received VPN Prefix ORF as specified in [I-D.ietf-idr-vpn-prefix-orf]. It MAY then determine whether every relevant downstream router is uninterested in the same route set. The determination may use VPN Prefix ORFs received from downstream routers, the Interest Query/Response procedure, or both. If every relevant downstream router is UNINTERESTED, the intermediate router MAY send an equivalent VPN Prefix ORF to the upstream peer from which the affected routes were received. If any relevant downstream router is INTERESTED or UNKNOWN, it MUST NOT do so. Wang Expires 17 April 2027 [Page 4] Internet-Draft source-propagation-ORF October 2026 4.1. Determination from Received VPN Prefix ORFs A relevant downstream router is UNINTERESTED when the intermediate router has received an equivalent VPN Prefix ORF from that router. Entries identifying different route sets MUST NOT be treated as equivalent. The intermediate router MAY send separate upstream ORF entries for route sets whose downstream interest has been determined independently. In Figure 1, if all the downstream routers(PE1/PE2/PE3) send out the VPN Prefix ORF messages to RR, then RR can propagate such message to the source PE safely. 4.2. Query-Based Determination If RR receives only the VPN Prefix ORF message from PE1, before sending the ORF upstream, the RR may query Receiver PE2 and Receiver PE3. A queried router returns: INTERESTED: It requires one or more affected routes. UNINTERESTED: It requires none of the affected routes. UNKNOWN: It cannot determine whether it requires the affected routes. A missing, malformed, or unsupported response MUST be treated as UNKNOWN. Only all the downstream routers express UNINTERESTED, then the RR can send propagate such message to the source PE safely. 5. Interest Query/Response Capability A BGP speaker advertises support for the Interest Query and Interest Response subtypes using the VPN Prefix ORF Interest Query/Response Capability defined in this document. The Capability Value contains one or more four-octet Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) tuples: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Reserved | SAFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Interest Query/Response Capability Encoding Format Reserved MUST be set to zero by the sender and ignored by the receiver. The Capability Length MUST be a nonzero multiple of four. Wang Expires 17 April 2027 [Page 5] Internet-Draft source-propagation-ORF October 2026 An intermediate router MUST NOT send an Interest Query for an AFI/ SAFI unless the peer has advertised the corresponding tuple. A relevant downstream router that has not advertised the tuple MUST be treated as UNKNOWN for query-based determination. It may still be classified as UNINTERESTED based on an equivalent VPN Prefix ORF received from it. The VPN Prefix ORF sent upstream is an ordinary VPN Prefix ORF. Its transmission is governed by the Outbound Route Filtering Capability [RFC5291]; the capability defined here is not required on the upstream session. 6. Relevant Downstream Routers The relevant downstream router set comprises the peers to which the intermediate router has advertised, or may advertise, the affected routes. The set may be derived from outbound Adjacent Routing Information Base (Adj-RIB-Out) state, Route Target Constraint (RTC) state, import policy, route-reflection state, or equivalent local state. If the set cannot be determined, the intermediate router MUST NOT send the VPN Prefix ORF upstream. 7. Procedures 7.1. Downstream Router A downstream router detecting overload sends a VPN Prefix ORF to the peer from which the affected routes were received, as specified in [I-D.ietf-idr-vpn-prefix-orf]. No propagation indication is required. 7.2. Intermediate Router An intermediate router receiving a VPN Prefix ORF: 1. Processes it on the downstream session according to [I-D.ietf-idr-vpn-prefix-orf]; 2. Identifies the affected route set and relevant downstream routers; 3. Determines each relevant downstream router's interest state; and 4. If all are UNINTERESTED, MAY send an equivalent VPN Prefix ORF to the upstream peer, subject to local policy and [RFC5291] capability negotiation. Wang Expires 17 April 2027 [Page 6] Internet-Draft source-propagation-ORF October 2026 If any relevant downstream router is INTERESTED or UNKNOWN, the intermediate router MUST NOT send the ORF upstream. 7.3. Upstream Router A router receiving the VPN Prefix ORF processes it according to [I-D.ietf-idr-vpn-prefix-orf] . It need not know why its peer sent the ORF. If it is also an intermediate router, it MAY independently apply this document before sending an equivalent ORF farther upstream. 7.4. Interest Query/Response Procedure The intermediate router assigns a Query Identifier that is unique among its outstanding queries on the BGP session. The Interest Query carries one or more VPN Prefix ORF entries identifying the affected route set. A queried router evaluates its local import interest for the complete route set identified by the query. It returns INTERESTED if it requires at least one matching route, UNINTERESTED if it requires no matching route, and UNKNOWN if it cannot make that determination. The intermediate router correlates the response using the Query Identifier. An unexpected Query Identifier, invalid response, or query timeout is treated as UNKNOWN. The Query Identifier may be reused after the query has completed or timed out. 8. State Changes An intermediate router that has sent a VPN Prefix ORF upstream MUST withdraw or replace it when the condition that justified it no longer holds. This includes a downstream interest-state change, removal of a downstream ORF, a change to the relevant downstream router set, RTC or import-policy changes, or a local-policy change. Withdrawal and replacement use the ordinary VPN Prefix ORF procedures. 9. Interest Query and Interest Response Encoding Interest Query and Interest Response are encoded as BGP ROUTE-REFRESH messages [RFC7313] using two new Message Subtype values. They do not install, remove, or modify an ORF on the receiving router. Wang Expires 17 April 2027 [Page 7] Internet-Draft source-propagation-ORF October 2026 A normal ROUTE-REFRESH message, with or without ORF entries, uses Message Subtype 0. For Subtype 0, the BGP Message Length distinguishes a plain ROUTE-REFRESH message from a ROUTE-REFRESH message carrying ORF entries as specified in [RFC5291]. The Interest Query and Interest Response messages are distinguished by the TBD2 and TBD3 subtype values, respectively. 9.1. Interest Query The Interest Query message is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Subtype=TBD2 | SAFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ORF Type=66 | Reserved | ORF Entries Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VPN Prefix ORF Entries ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Interest Query Message Encoding Format AFI and SAFI: identify the address family to which the query applies. Subtype is TBD2. Query Identifier: an unsigned 32-bit value selected by the sender. ORF Type: MUST be 66. Reserved: MUST be set to zero by the sender and ignored by the receiver. ORF Entries Length: an unsigned 16-bit value containing the total length, in octets, of the following VPN Prefix ORF entries. VPN Prefix ORF Entries: use the entry encoding defined in [I-D.ietf-idr-vpn-prefix-orf]. Each entry MUST have Action ADD and Match DENY. REMOVE, REMOVE-ALL, and PERMIT entries are invalid in an Interest Query. The entries are used only to identify the route set; they MUST NOT be installed in the receiver's ORF table. Wang Expires 17 April 2027 [Page 8] Internet-Draft source-propagation-ORF October 2026 The query applies to the union of the route sets identified by all entries in the message. The message MUST contain at least one complete VPN Prefix ORF entry, and ORF Entries Length MUST equal the number of remaining octets in the message. 9.2. Interest Response The Interest Response message is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Subtype=TBD3 | SAFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interest State| Reserved | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Interest Response Message Encoding Format AFI, SAFI, and Query Identifier MUST equal the corresponding fields in the Interest Query. Interest State is encoded as follows: Value Meaning ----- ------------ 0 Reserved 1 INTERESTED 2 UNINTERESTED 3 UNKNOWN Reserved fields MUST be set to zero by the sender and ignored by the receiver. The Interest Response has a fixed payload length of 12 octets, excluding the BGP message header. 9.3. Error Handling A speaker receiving an Interest Query or Interest Response without having advertised the capability defined in Section 5 MUST discard the message and SHOULD log the event. A message with an invalid length is handled as specified for an invalid ROUTE-REFRESH message in [RFC7313]. A query containing an invalid ORF Type, invalid VPN Prefix ORF entry, or inconsistent ORF- entry length MUST be answered with UNKNOWN when the Query Identifier Wang Expires 17 April 2027 [Page 9] Internet-Draft source-propagation-ORF October 2026 can be parsed; otherwise it MUST be discarded. An Interest Response containing an unrecognized Interest State or nonzero Reserved field MUST be treated as UNKNOWN. 10. Operational Considerations Query-based determination SHOULD be enabled only on trusted sessions. Implementations SHOULD rate-limit queries and avoid concurrent queries for the same peer and route set. Implementations SHOULD expose the relevant downstream router set, current interest states, and dependent upstream ORFs. 11. Security Considerations An incorrect interest determination can suppress routes required by a downstream router. Unsupported peers, invalid responses, and timeouts MUST therefore be treated as UNKNOWN. A malicious peer can send false responses or trigger repeated state changes. Existing BGP session protection, local policy, rate limiting, and monitoring apply. The Interest Query/Response Capability does not imply support for VPN Prefix ORF; the [RFC5291] capability state MUST be checked separately before an ORF is sent upstream. 12. IANA Considerations 12.1. Capability Code The Internet Assigned Numbers Authority (IANA) is requested to assign a new value from the "Capability Codes" registry: +============+=============================================+=========================+ | Value | Description | Reference | +============+=============================================+=========================+ | TBD1 | VPN Prefix ORF Interest Query/Response | This document | +------------+---------------------------------------------+-------------------------+ The Capability Value consists of one or more AFI/SAFI tuples as specified in Section 5. The Capability Length is a nonzero multiple of four. 12.2. BGP Route Refresh Subcodes IANA is requested to assign two values from the "BGP Route Refresh Subcodes" registry: Wang Expires 17 April 2027 [Page 10] Internet-Draft source-propagation-ORF October 2026 +============+=============================================+=========================+ | Value | Description | Reference | +============+=============================================+=========================+ | TBD2 | VPN Prefix ORF Interest Query | This document | +------------+---------------------------------------------+-------------------------+ | TBD3 | VPN Prefix ORF Interest Response | This document | +------------+---------------------------------------------+-------------------------+ 12.3. VPN Prefix ORF Interest States IANA is requested to create the "VPN Prefix ORF Interest States" registry under "Border Gateway Protocol (BGP) Parameters". The registration policy is IETF Review [RFC8126]. The initial contents are: Under "Border Gateway Protocol (BGP) Parameters" Registry: "VPN Prefix ORF Interest States" +==========+=========================+================+ | Value | Description | Reference | +====================================+================+ | 0 | Reserved | This document | +----------+-------------------------+----------------+ | 1 | INTERESTED | This document | +----------+-------------------------+----------------+ | 2 | UNINTERESTED | This document | +----------+-------------------------+----------------+ | 3 | UNKNOWN | This document | +----------+-------------------------+----------------+ | 4-250 | Unassigned | This document | +----------+-------------------------+----------------+ | 251-254 | Experimental Use | This document | +----------+-------------------------+----------------+ | 255 | Reserved | This document | +----------+-------------------------+----------------+ 13. Contributor TBD 14. Acknowledgement TBD. 15. References 15.1. Normative References Wang Expires 17 April 2027 [Page 11] Internet-Draft source-propagation-ORF October 2026 [I-D.ietf-idr-vpn-prefix-orf] Wang, W., Wang, A., Wang, H., Mishra, G. S., and J. Dong, "VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4", Work in Progress, Internet-Draft, draft-ietf-idr- vpn-prefix-orf-45, 9 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008, . [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References Author's Address Aijun Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: wangaj3@chinatelecom.cn Wang Expires 17 April 2027 [Page 12]