Inter-Domain Routing Z. Li, Ed. Internet-Draft Z. An, Ed. Intended status: Standards Track China Mobile Expires: 5 May 2027 Z. Cao Huawei 1 November 2026 BGP Flow Specification Redirects to Direct IP draft-li-idr-flowspec-redirect-direct-ip-01 Abstract A bit, D bit, is defined in the Flow-spec Redirect-to-IPv4 Extended Community, which 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. 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 5 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Li, et al. Expires 5 May 2027 [Page 1] Internet-Draft Flow Specification Direct IP November 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. Scenarios to Be Addressed . . . . . . . . . . . . . . . . . . 3 2.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . 5 3. D Bit for Flow-spec Redirect-to-IPv4 . . . . . . . . . . . . 7 4. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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. Li, et al. Expires 5 May 2027 [Page 2] Internet-Draft Flow Specification Direct IP November 2026 This document extends the Flow-spec Redirect-to-IPv4 Extended Community 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 uses the previously undefined bit 14 in the Local Administrator field. 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]. 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. Scenarios to Be Addressed 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. 2.1. Scenario 1 As shown in Section 2.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. Li, et al. Expires 5 May 2027 [Page 3] Internet-Draft Flow Specification Direct IP November 2026 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 Figure 1: Redirected Traffic after Failure of the Direct Link Li, et al. Expires 5 May 2027 [Page 4] Internet-Draft Flow Specification Direct IP November 2026 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. 2.2. Scenario 2 As shown in Figure 2, Network 2 uses the prefix 198.51.100.0/24 and connects only to Router 2. S4 is a traffic scrubbing system, rather than an ordinary router. Router 1 connects to S4 over Link A, with interface addresses 192.0.2.1 and 192.0.2.2, respectively. Router 3 connects to Router 1 over Link B and to S4 over Link C. Router 1 reaches Network 2 through Router 2 over Link D, and Router 3's destination-based route to Network 2 uses Router 1 as its next hop. The SDN controller installs a BGP Flow Specification policy on Router 1 that matches packets destined to 198.51.100.0/24 and redirects them to S4's interface address 192.0.2.2. While Link A is available, Router 1 sends matching traffic directly to S4 for scrubbing. S4 reinjects the cleaned traffic toward Router 2 and Network 2 through a separate forwarding path that avoids reapplying Router 1's redirect policy. The clean-traffic reinjection path is omitted from the figure. Li, et al. Expires 5 May 2027 [Page 5] Internet-Draft Flow Specification Direct IP November 2026 +----------------+ | SDN Controller | +----------------+ * * BGP Flow Specification * v +----------+ +----+ | Router 2 |---------| N2 | +----------+ +----+ 15 / Link D / / +----+ +----------+ X +----------+ | N1 |---------| Router 1 |---------| S4 | +----+ +----------+ Link A +----------+ \ metric 100 / Link B \ (FAILED) / Link C 10 \ / 10 \ / +----------+ | Router 3 | +----------+ S4: traffic scrubbing system Clean-traffic reinjection path omitted. Forwarding loop over Link B after Link A fails: R1 === redirect-target lookup ===> R3 R1 <== destination lookup (N2) === R3 Figure 2: Forwarding Loop after Failure of the Direct Link to S4 When Link A fails, Router 1 removes the connected route to 192.0.2.2. In this example, an aggregate or default route still resolves the redirect target through Router 3 over Link B. Router 1 therefore retains the BGP Flow Specification policy and sends matching traffic destined to Network 2 to Router 3. The redirected packets in this example retain their original destination addresses and are not encapsulated in a tunnel to S4. After receiving a packet, Router 3 performs normal destination-based forwarding toward Network 2. Its route to Network 2 uses Router 1 as the next hop, so it sends the packet back to Router 1 over Link B. Router 3 does not need a BGP Flow Specification policy to cause this return path. Li, et al. Expires 5 May 2027 [Page 6] Internet-Draft Flow Specification Direct IP November 2026 When Router 1 receives the packet again, it matches the same BGP Flow Specification policy and redirects it toward S4 through Router 3. The packet consequently loops between Router 1 and Router 3 until its TTL expires. The loop consumes forwarding resources, and the packet is discarded without reaching Network 2, resulting in service interruption. 3. D Bit for Flow-spec Redirect-to-IPv4 This document extends the Flow-spec Redirect-to-IPv4 Extended Community 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. The D bit is encoded using the previously undefined bit 14 in the Local Administrator field of the Flow-spec Redirect-to-IPv4 Extended Community, as shown in Figure 3. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |D|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of the D Bit in the Local Administrator Field 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 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. Li, et al. Expires 5 May 2027 [Page 7] Internet-Draft Flow Specification Direct IP November 2026 4. Behavior 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. 5. Deployment Considerations This extension supports incremental deployment. Existing BGP Flow Specification policies without the D bit retain the Redirect-to-IPv4 processing specified in [I-D.ietf-idr-flowspec-redirect-ip]. Introducing support for the D bit does not, by itself, change the behavior of those policies. A receiver that supports this extension MUST follow the behaviors specified in this document. Li, et al. Expires 5 May 2027 [Page 8] Internet-Draft Flow Specification Direct IP November 2026 A receiver that supports Redirect-to-IPv4 but not this extension MUST ignore the D bit and continue processing the policy, in accordance with the reserved-bit processing rules defined in [I-D.ietf-idr-flowspec-redirect-ip]. The receiver MUST NOT discard the extended community or the Flow Specification route solely because the D bit is set. Consequently, the direct-link protection described in this document applies only to policies with the D bit set to 1 on supporting receivers. Policies with D set to 0, and policies on receivers that ignore D, may still exhibit the failure behavior described in the scenarios. Previously advertised policies require an update with D set to 1 to obtain this protection on supporting receivers. 6. IANA Considerations This document defines the D bit at bit position 14 in the Local Administrator field of the existing Flow-spec Redirect-to-IPv4 Extended Community. IANA is requested to add this document as an additional reference for the "Flow-spec Redirect-to-IPv4" entry in the "Transitive IPv4- Address-Specific Extended Community Sub-Types" registry [IANA_bgp_extended_communities_trans_ipv4]. 7. Security Considerations The security considerations discussed in [I-D.ietf-idr-flowspec-redirect-ip] also apply to this document. 8. References 8.1. Normative References [I-D.ietf-idr-flowspec-redirect-ip] Haas, J., Henderickx, W., and W.A. Simpson, "BGP Flow-Spec Redirect-to-IP Action", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-16, 21 May 2026, . [IANA_bgp_extended_communities_trans_ipv4] IANA, "Transitive IPv4-Address-Specific Extended Community Sub-Types", . Li, et al. Expires 5 May 2027 [Page 9] Internet-Draft Flow Specification Direct IP November 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [IEEE8021AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation", IEEE Std 802.1AX-2020, May 2020, . [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC826, November 1982, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, . [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, . Acknowledgements TBD. Authors' Addresses Zhenqiang Li (editor) China Mobile 29 Finance Avenue, Xicheng District Beijing China Li, et al. Expires 5 May 2027 [Page 10] Internet-Draft Flow Specification Direct IP November 2026 Email: lizhenqiang@chinamobile.com Zhiwei An (editor) China Mobile 10 Manbai Road, Changping District BeiJing China Email: anzhiwei@chinamobile.com Ziqing Cao Huawei Huawei Bld., No.156 Beiqing Rd. Beijing China Email: caoziqing@huawei.com Li, et al. Expires 5 May 2027 [Page 11]