]> Beijing University of Posts and Telecommunications

No.10 Xitucheng Road Beijing Hai-Dian District 100876 China baronmail@bupt.edu.cn

Beijing University of Posts and Telecommunications

No.10 Xitucheng Road Beijing Hai-Dian District 100876 China xygong@bupt.edu.cn

Beijing University of Posts and Telecommunications

No.10 Xitucheng Road Beijing Hai-Dian District 100876 China rongqx@bupt.edu.cn

Beijing University of Posts and Telecommunications

No.10 Xitucheng Road Beijing Hai-Dian District 100876 China dengfang@bupt.edu.cn

Operations and Management ANIMA SRv6 GRASP Failover This document specifies an autonomic fast failover mechanism for SRv6 networks using a bounce-back strategy. It uses GRASP to distribute failover protection information, enabling data plane fast reroute without control plane reconvergence.

Introduction Segment Routing over IPv6 (SRv6) provides a flexible source routing paradigm that enables explicit path specification for traffic engineering and service chaining. This flexibility, however, comes with a trade-off: when any node or link along an explicitly specified SRv6 path fails, the entire path is disrupted. Traditional recovery mechanisms rely on control plane reconvergence, which typically takes seconds to complete. Existing fast protection mechanisms such as Topology-Independent Loop-Free Alternate (TI-LFA) provide local protection for IGP segments. However, as noted in Section 9, TI-LFA has inherent limitations:

• SR Policies built with non-protected Adjacency SIDs do not benefit from any local protection.
• Links that span multiple IGP domains cannot benefit from TI-LFA automated local protection.

This document introduces a bounce-back strategy to address these gaps. The strategy provides dual protection across the time dimension:

• For in-flight packets at the moment of failure, the Bouncer node bounces them back to the nearest upstream Anchor node, which re-encapsulates the traffic with a pre-computed backup SRv6 segment list.
• For new packets arriving after failure detection, the Anchor node directly encapsulates them onto the backup path.

The mechanism uses GRASP to autonomically distribute failover protection information during path setup. The ACP and BRSKI provide the security foundation.

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.

Terminology and Abbreviations This document uses the terminology defined in and .

Anchor Node:

A node on the primary path that has a pre-computed backup path to reach the destination. When receiving bounced-back traffic, it re-encapsulates with the backup SRv6 segment list.

Bouncer Node:

A node on the primary path that does NOT have a backup path. It can only bounce traffic upstream when detecting a downstream failure.

Bounce-back:

The action of forwarding traffic toward the upstream direction when a downstream link failure is detected.

FPM ASA:

Failover Path Manager Autonomic Service Agent. Manages the computation, distribution, and installation of failover protection information using GRASP.

Flow Identifier:

A value used to uniquely identify a communication flow. This document uses the IPv6 Flow Label field for this purpose.

Primary Path:

The main forwarding path computed for normal traffic transmission.

Backup Path:

A pre-computed alternative path used when the primary path fails.

Cascading Bounce-back:

When a failure occurs, traffic bounces upstream through one or more Bouncer nodes until reaching an Anchor node that can reroute traffic via a backup path.

Path Initiator:

The entity responsible for computing paths and distributing protection information via GRASP. Typically the Ingress Edge Node or a centralized controller.

Path Responder:

A node on the primary path that receives protection information from the Path Initiator via GRASP.

Failover Mechanism Overview The bounce-back failover mechanism operates in two distinct phases: control plane setup using GRASP, and data plane failover execution.

Control Plane and Data Plane Separation

• Control Plane: Distributes failover protection information during path setup. GRASP is NOT involved in failure detection or failover execution.
• Data Plane: Performs failure detection, executes bounce-back action, and performs backup path re-encapsulation. All failover decisions are made locally based on pre-installed forwarding state.

Node Roles and Backup Path Requirements Each node on the primary path is assigned one of two roles:

Anchor Node Definition An Anchor Node (role=0) has a valid backup path and can re-encapsulate traffic. When receiving bounced-back traffic, it MUST strip the original SRv6 encapsulation, re-encapsulate with its pre-installed backup segment list, and forward toward the backup path next-hop.

Bouncer Node Definition A Bouncer Node (role=1) does NOT have a valid backup path. When detecting downstream failure or receiving bounced-back traffic, it MUST forward upstream without modification.

Backup Path Requirements A valid backup path MUST satisfy: Reachability, Disjointness (MUST NOT traverse any primary path link between Anchor and destination), First-hop Difference, and SRv6 Expressibility.

Topology with Node Roles and Backup Paths n1 -> n2 -> n3 -> n4 -> h2 Node Roles: n1: Anchor (backup: n1 -> b1 -> b2 -> b3 -> h2) n2: Anchor (backup: n2 -> b4 -> b5 -> h2) n3: Bouncer (no backup path) n4: Bouncer (no backup path) Backup Path Validity: A valid backup MUST NOT traverse any primary path link downstream of the Anchor. For n2: backup via b4 -> b5 -> h2 is valid (avoids n2-n3, n3-n4, n4-h2 links) ]]>

Before Failure: Protection Information Distribution Before failure, protection information must be distributed to all path nodes via GRASP, including node role, upstream/downstream neighbor addresses, flow identifier, and backup segment list (for Anchors).

Failure Detection Failure detection is performed locally using link-layer detection, BFD, or hardware port monitoring. To achieve sub-50ms failover, hardware-assisted detection SHOULD be used.

After Failure: Bounce-back and Re-encapsulation When failure occurs: (1) Node detects downstream interface failure, (2) Immediately redirects traffic upstream, (3) Upstream nodes identify bounced traffic by arrival interface and flow-id, (4) Bouncer forwards upstream; Anchor re-encapsulates and forwards on backup path.

GRASP Objective for Failover Path Management

Failover Path Manager Objective The objective name is "SRv6-Failover" conforming to . Format in CDDL :

GRASP Objective Format

Objective Value Definition

Flow and Path Information Structure

Objective Example For the following topology and primary path:

Example Topology n1 -> n2 -> n3 -> n4 -> h2 Flow Identifier: 0x0000a ]]>

The GRASP objective value would contain:

Objective Value Example

Failover Procedures and Scenarios

GRASP Procedures The FPM ASA on the Path Initiator discovers path nodes via GRASP Discovery, then sends Request messages with node-protection-info. Path Responders resolve addresses, install forwarding state, and respond with Negotiation End (ACCEPT).

GRASP Negotiation Procedure | | | | M_RESPONSE (locator) | |<----------------------------------------| | | | M_REQ_NEG (node-protection-info) | |---------------------------------------->| | | | M_END (O_ACCEPT) | |<----------------------------------------| | | ]]>

Forwarding Behavior Requirements Nodes MUST distinguish Normal Traffic (from upstream) and Bounced Traffic (from downstream) based on arrival interface and flow identifier. Anchor nodes re-encapsulate; Bouncer nodes forward upstream.

Intra-domain Scenario

Topology and Configuration

Intra-domain Topology and Configuration n1 -> n2 -> n3 -> n4 -> h2 Flow Identifier: 0x0000a Protection Configuration: n1: Anchor, upstream=h1, downstream=n2 backup=[b1-sid, b2-sid, b3-sid, h2-sid], next-hop=b1 n2: Anchor, upstream=n1, downstream=n3 backup=[b4-sid, b5-sid, h2-sid], next-hop=b4 n3: Bouncer, upstream=n2, downstream=n4 n4: Bouncer, upstream=n3, downstream=h2 ]]>

Failover Execution Example When the n3-n4 link fails:

1. n3 detects the interface toward n4 is down.
2. n3 (Bouncer) bounces in-flight traffic toward n2.
3. n2 receives traffic from n3 direction with flow-id=0x0000a, identifies it as bounced traffic.
4. n2 (Anchor) re-encapsulates traffic with backup segment list [b4-sid, b5-sid, h2-sid] and forwards toward b4.
5. Traffic reaches h2 via the backup path n2 -> b4 -> b5 -> h2.

If b4-b5 link also fails, n2 bounces traffic to n1, which re-encapsulates via its backup path n1 -> b1 -> b2 -> b3 -> h2 (cascading bounce-back).

Inter-domain Scenario Flow identifier is preserved across domain boundaries. Each domain computes its own node roles for its portion of the path.

Implementation Considerations OpenFlow implementations MAY use: in_port, eth_type, ipv6_dst, ipv6_label match fields; fast-failover groups with watch_port. P4 implementations MAY use: ingress metadata, tables keyed by (ingress_port, flow_label, ipv6_dst), link status registers. To achieve sub-50ms failover: use hardware-based detection, implement bounce-back in hardware, pre-install forwarding state.

Security Considerations This mechanism inherits security considerations of and .

• Authentication: All FPM ASA communication MUST occur over ACP . Nodes MUST be authenticated via BRSKI .
• Authorization: Only authorized nodes SHOULD initiate or modify failover protection state.
• Integrity: GRASP messages MUST be integrity-protected.
• Flow Identifier Security: Ingress filtering SHOULD prevent flow identifier spoofing.
• Resource Exhaustion: Rate limiting of GRASP requests SHOULD be implemented.

IANA Considerations

GRASP Objective Name IANA is requested to add "SRv6-Failover" to the "GRASP Objective Names" registry. Reference: [this document]

Node Role Registry IANA is requested to create "SRv6-Failover Node Role" registry with initial values:

• 0: Anchor - A node with a pre-computed backup path
• 1: Bouncer - A node that can only bounce traffic upstream

Values 2-255 are reserved. New values require Standards Action.

References Normative References Informative References

Complete CDDL Definition This appendix provides the complete CDDL definition for the SRv6-Failover GRASP objective:

Complete CDDL Definition

Acknowledgements The authors thank the contributors of the ANIMA working group for their valuable feedback on autonomic networking mechanisms.