Source-Directed Propagation of VPN Prefix ORF for BGP-4

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. 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.

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.

This document uses the terminology of : 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. Interest Response: A response indicating INTERESTED, UNINTERESTED, or UNKNOWN.

Consider the following intra-Autonomous System (intra-AS) topology. The Provider Edge (PE) routers are connected to the RR as follows:

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.

An intermediate router first processes a received VPN Prefix ORF as specified in . 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.

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.

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.

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:

Reserved MUST be set to zero by the sender and ignored by the receiver. The Capability Length MUST be a nonzero multiple of four. 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.

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.

A downstream router detecting overload sends a VPN Prefix ORF to the peer from which the affected routes were received, as specified in . No propagation indication is required.

An intermediate router receiving a VPN Prefix ORF: 1. Processes it on the downstream session according to ; 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 capability negotiation. If any relevant downstream router is INTERESTED or UNKNOWN, the intermediate router MUST NOT send the ORF upstream.

A router receiving the VPN Prefix ORF processes it according to . 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.

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.

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.

Interest Query and Interest Response are encoded as BGP ROUTE-REFRESH messages using two new Message Subtype values. They do not install, remove, or modify an ORF on the receiving router. 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 . The Interest Query and Interest Response messages are distinguished by the TBD2 and TBD3 subtype values, respectively.

The Interest Query message is encoded as follows:

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 . 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. 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.

The Interest Response message is encoded as follows:

AFI, SAFI, and Query Identifier MUST equal the corresponding fields in the Interest Query. Interest State is encoded as follows:

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.

A speaker receiving an Interest Query or Interest Response without having advertised the capability defined in 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 . 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 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.

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.

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 capability state MUST be checked separately before an ORF is sent upstream.

The Internet Assigned Numbers Authority (IANA) is requested to assign a new value from the "Capability Codes" registry:

The Capability Value consists of one or more AFI/SAFI tuples as specified in . The Capability Length is a nonzero multiple of four.

IANA is requested to assign two values from the "BGP Route Refresh Subcodes" registry:

IANA is requested to create the "VPN Prefix ORF Interest States" registry under "Border Gateway Protocol (BGP) Parameters". The registration policy is IETF Review . The initial contents are:

TBD

TBD.