| Internet-Draft | Flow Specification Redirect to Direct IP | July 2026 |
| Li & An | Expires 6 January 2027 | [Page] |
A bit, D bit, is defined in Flow-spec Redirect-to-IPv4 Extended Community and Flow-spec Redirect-to-IPv6 Extended Community. This bit is used by BGP Flow Specification to indicate that the associated Flow Specification policy be set to an invalid state when the directly connected link associated with the redirect target address becomes unavailable.¶
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 6 January 2027.¶
Copyright (c) 2026 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.¶
BGP Flow Specification, as specified in [RFC8955] and [RFC8956], is widely used for traffic steering, traffic rate limiting, and other traffic-control purposes. [I-D.ietf-idr-flowspec-redirect-ip] defines the BGP Flow Specification Redirect-to-IP action, which enables Flow Specification to redirect traffic to an IP address.¶
[I-D.ietf-idr-flowspec-redirect-ip] specifies that the BGP speaker is expected to do a longest-prefix-match lookup of the "target address" in the database it uses to resolve next-hop addresses and then forward the redirected packets based on the resulting route, referred to as the "target route". In some cases, this mechanism can prevent a network element from promptly setting the corresponding BGP Flow Specification policy to an invalid state. This not only wastes resources on the network element and in the network, but may also cause a traffic forwarding loop, preventing traffic from reaching its destination and causing service interruption. The specific scenarios are described in the next section.¶
This document extends the Flow-spec Redirect-to-IPv4 Extended Community and Flow-spec Redirect-to-IPv6 Extended Community defined in [I-D.ietf-idr-flowspec-redirect-ip] by defining a new directly connected link indication bit, called the D bit. An SDN controller sets the D bit to 1 when it sends a BGP Flow Specification policy that redirects traffic to the peer interface address of a directly connected link and requires the receiving network element to set the corresponding policy to an invalid state if that link becomes unavailable.¶
How a network element detects the failure of a directly connected link is implementation specific and is not specified in this document. Possible mechanisms include, but are not limited to, Bidirectional Forwarding Detection (BFD) [RFC5880], ARP-based neighbor reachability checks [RFC826], and Link Aggregation Control Protocol (LACP) state monitoring [IEEE8021AX].¶
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.¶
The figures in this section use solid lines ("---") for physical links, asterisks ("***") for the logical BGP connection between the SDN controller and Router 1, and lines with arrowheads ("===>") for the direction of the traffic being discussed. The number associated with each physical link is both its IGP metric and, except for Link A, its delay in milliseconds. Link A has an IGP metric of 100 and a delay of 1 millisecond.¶
As shown in Figure 1, Network 2 uses the prefix 198.51.100.0/24. Interface Address 1 and Interface Address 2 are 192.0.2.1 and 192.0.2.2, respectively, on Link A. The numbers shown on the links are their IGP metrics and, except for Link A, also represent their delays in milliseconds. Link A has an IGP metric of 100 and a delay of 1 millisecond.¶
Under normal destination-based forwarding, the path from Router 1 to Router 4 through Router 3 has a total IGP metric of 20, while the path through Router 2 has a total IGP metric of 30. Therefore, traffic from Network 1 to Network 2 is forwarded by Router 1 over Link B to Router 3, by Router 3 over Link C to Router 4, and then by Router 4 to Network 2.¶
For traffic that requires a lower-delay path, the SDN controller generates a BGP Flow Specification route that matches packets with a destination in 198.51.100.0/24 and carries a Redirect-to-IPv4 action with the target address 192.0.2.2. The SDN controller sends this route to Router 1. After installing the corresponding policy, Router 1 redirects matching traffic over Link A to Router 4, which then forwards the traffic to Network 2.¶
+----------------+
| SDN Controller |
+----------------+
*
* BGP Flow Specification
*
*
* +----------+
v | Router 2 |
+----------+
15/ \15
Link D/ \Link E
/ \
+----+ +----------+ X +----------+ +----+
| N1 |---------| Router 1 |---------| Router 4 |---------| N2 |
+----+ +----------+ Link A +----------+ +----+
\ metric 100 /
Link B\ (FAILED) /Link C
10\ /10
\ /
+----------+
| Router 3 |
+----------+
After Link A fails while the Flow Specification policy remains active:
R1 ===> R3 ===> R4
While Link A is available, Router 1 has a connected route to the redirect target address 192.0.2.2 and sends the matching traffic directly to Router 4 over Link A. The redirected traffic therefore uses the 1-millisecond link instead of the normal 20-millisecond path through Links B and C.¶
When Link A fails, Router 1 removes the connected route to 192.0.2.2. However, the redirect target address may remain reachable through another route, such as an aggregate route or a default route whose forwarding path uses Links B and C. Under the procedures in [I-D.ietf-idr-flowspec-redirect-ip], Router 1 therefore retains the BGP Flow Specification policy and redirects the matching traffic over Link B to Router 3. Router 3 then forwards the traffic over Link C to Router 4, which forwards it to Network 2.¶
Retaining the BGP Flow Specification policy after Link A fails is unnecessary in this scenario. Without the policy, Router 1 would use the same destination-based path through Router 3 and Router 4. Moreover, the redirected traffic no longer uses the intended low-delay Link A and may no longer satisfy its delay requirement.¶
As shown in Figure 2, Scenario 2 uses the same topology, addressing, metrics, and BGP Flow Specification route installed on Router 1 as Scenario 1. In this scenario, Link A is unavailable, but Link C remains available. Therefore, if Router 3 used only normal destination-based forwarding, traffic destined to Network 2 could be forwarded from Router 3 to Router 4 over Link C.¶
However, Router 3 has already installed another BGP Flow Specification policy. This policy matches traffic destined to 198.51.100.0/24 and redirects the matching traffic to Router 1 over Link B. This Flow Specification policy is the reason Router 3 sends the traffic back to Router 1; the loop is not caused by a failure of Link C.¶
+----------------+
| SDN Controller |
+----------------+
*
* BGP Flow Specification
*
*
* +----------+
* | Router 2 |
v +----------+
15/ \15
Link D/ \Link E
/ \
+----+ +----------+ X +----------+ +----+
| N1 |---------| Router 1 |---------| Router 4 |---------| N2 |
+----+ +----------+ Link A +----------+ +----+
\ metric 100 /
Link B\ (FAILED) / Link C
10\ /10
\ /
+----------+
| Router 3 |
+----------+
Forwarding loop over Link B:
R1 === redirect-target lookup ===> R3
R1 <== Flow-spec redirect on R3 ==== R3
Router 3 Flow-spec policy:
match destination 198.51.100.0/24
redirect to Router 1
While Link A is available, Router 1 has a connected route to the redirect target address 192.0.2.2 and redirects matching traffic directly to Router 4 over Link A.¶
When Link A fails, Router 1 removes the connected route to 192.0.2.2. However, the redirect target address may still be resolved through another route, such as an aggregate route or a default route whose forwarding path uses Link B. Router 1 therefore retains the BGP Flow Specification policy and sends matching traffic destined to 198.51.100.0/24 over Link B to Router 3.¶
After receiving the traffic, Router 3 matches its own BGP Flow Specification policy for destination prefix 198.51.100.0/24. Although Link C remains available, the Flow Specification policy on Router 3 redirects the traffic back to Router 1 over Link B instead of allowing normal destination-based forwarding toward Router 4 over Link C.¶
When Router 1 receives the traffic again, it continues to match the same BGP Flow Specification policy and redirects the traffic toward the target address through Router 3. The traffic consequently loops between Router 1 and Router 3 over Link B until its TTL expires. The loop consumes forwarding resources, and the traffic is eventually discarded without reaching Network 2, resulting in service interruption.¶
This document extends the Redirect-to-IP Extended Communities defined in [I-D.ietf-idr-flowspec-redirect-ip] by defining a new directly connected link indication bit, called the D bit. The D bit is used to instruct a receiving network element to set the corresponding BGP Flow Specification policy that redirects traffic to an IP address to an invalid state when the directly connected link associated with that address becomes unavailable.¶
As shown in Figure 3, bit 14 in the Local Administrator field is solicited to be defined as the "D" (Direct) bit, which is applicable for both Flow-spec Redirect-to-IPv4 and Flow-spec Redirect-to-IPv6. The D bit is requested to be assigned by IANA.¶
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
D bit: The directly connected link indication bit. When a BGP Flow Specification policy is configured to redirect traffic to an IP address and the D bit is set to 1, the receiving network element sets the corresponding BGP Flow Specification policy to an invalid state if the directly connected link associated with that IP address becomes unavailable. When the directly connected link recovers, the network element sets the policy back to a valid state.¶
When the D bit is set to 0, the processing behavior of the Redirect-to-IPv4 and Redirect-to-IPv6 action is unchanged. If the directly connected link associated with the redirect target address becomes unavailable but the network element still has a route to that IP address, the corresponding BGP Flow Specification policy is not set to an invalid state and remains valid.¶
When an SDN controller intends matching traffic to be redirected to the peer interface address of a directly connected link, it originates a BGP Flow Specification route with the Redirect-to-IP action defined in [I-D.ietf-idr-flowspec-redirect-ip]. The SDN controller sets the D bit when the redirect action is required to remain valid only while that directly connected link is available.¶
After receiving the BGP Flow Specification route and completing the applicable validation procedures, a network element that supports the D bit associates the redirect target address with the directly connected link used to reach that address. The method used to determine the operational state of the link is implementation specific, as discussed in Section 1.¶
When the D bit is set and the associated directly connected link becomes unavailable, the network element sets the corresponding BGP Flow Specification policy to an invalid state and stops applying its Redirect-to-IP action. The network element does not keep that policy active by resolving the redirect target through a less-specific aggregate route or a default route. Matching packets are then processed by any other applicable policy or, if no such policy applies, by normal destination-based forwarding. This behavior prevents the unintended detour described in Scenario 1 and the forwarding loop described in Scenario 2.¶
When the associated directly connected link becomes available again, the network element re-evaluates the policy. If the redirect target is again reachable over that directly connected link and the BGP Flow Specification route remains otherwise valid, the network element sets the policy back to a valid state and resumes applying the Redirect-to-IP action. No new advertisement from the SDN controller is required solely because the link state changes.¶
When the D bit is not set, the procedures specified in [I-D.ietf-idr-flowspec-redirect-ip] are unchanged.¶
Two-octet registry called "Flow-spec Redirect-to-IPv4 Flags" is solicited to be created. This registry is located in the "Border Gateway Protocol (BGP) Extended Communities" registry [IANA-BGP-EXT-COMM]. New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. Initial registrations are as follows:¶
| Flag Position | Name | Reference |
|---|---|---|
| 0-13 | Unassigned | |
| 14 | Direct Flag (D) | This document |
| 15 | Copy Flag (C) | [I-D.ietf-idr-flowspec-redirect-ip] |
Two-octet registry called "Flow-spec Redirect-to-IPv6 Flags" is solicited to be created. This registry is located in the "Border Gateway Protocol (BGP) Extended Communities" registry [IANA-BGP-EXT-COMM]. New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. Initial registrations are as follows:¶
| Flag Position | Name | Reference |
|---|---|---|
| 0-13 | Unassigned | |
| 14 | Direct Flag (D) | This document |
| 15 | Copy Flag (C) | [I-D.ietf-idr-flowspec-redirect-ip] |
The security considerations discussed in [I-D.ietf-idr-flowspec-redirect-ip] also apply to this document.¶