]> China Mobile

29 Finance Avenue, Xicheng District Beijing CN lizhenqiang@chinamobile.com

China Mobile

10 Manbai Road, Changping District BeiJing CN anzhiwei@chinamobile.com

Huawei

Huawei Bld., No.156 Beiqing Rd. Beijing CN caoziqing@huawei.com

Routing Inter-Domain Routing BGP Flow Specification Redirect Direct IP 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.

Introduction BGP Flow Specification, as specified in and , is widely used for traffic steering, traffic rate limiting, and other traffic-control purposes. defines the BGP Flow Specification Redirect-to-IP action, which enables Flow Specification to redirect traffic to an IP address. 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 defined in 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) , ARP-based neighbor reachability checks , and Link Aggregation Control Protocol (LACP) state monitoring .

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 when, and only when, they appear in all capitals, as shown here.

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.

Scenario 1 As shown in , 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.

Redirected Traffic after Failure of the Direct Link 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 , 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.

Scenario 2 As shown in , 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.

Forwarding Loop after Failure of the Direct Link to S4 R3 R1 <== destination lookup (N2) === R3 ]]>

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

D Bit for Flow-spec Redirect-to-IPv4 This document extends the Flow-spec Redirect-to-IPv4 Extended Community defined in 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 .

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.

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

Deployment Considerations This extension supports incremental deployment. Existing BGP Flow Specification policies without the D bit retain the Redirect-to-IPv4 processing specified in . 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. 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 . 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.

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 .

Security Considerations The security considerations discussed in also apply to this document.

References Normative References IANA Informative References IEEE

Acknowledgements TBD.