Source-Directed Propagation of VPN Prefix ORF for BGP-4
draft-wang-idr-vpn-prefix-orf-propagation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Aijun Wang | ||
| Last updated | 2026-10-14 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | idr at IETF-127 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-idr-vpn-prefix-orf-propagation-00
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-
prefix-orf-45>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291,
August 2008, <https://www.rfc-editor.org/info/rfc5291>.
[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
Route Refresh Capability for BGP-4", RFC 7313,
DOI 10.17487/RFC7313, July 2014,
<https://www.rfc-editor.org/info/rfc7313>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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]