



ANIMA                                                         L. Du, Ed.
Internet-Draft                                                   X. Gong
Intended status: Standards Track                                  X. Que
Expires: 2 September 2026                                        F. Deng
                                                                    BUPT
                                                            1 March 2026


  Autonomic SRv6 Network Fast Failover Using Bounce-back Strategy with
                                 GRASP
                 draft-du-anima-srv6-failover-grasp-00

Abstract

   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.

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 2 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Du, et al.              Expires 2 September 2026                [Page 1]

Internet-Draft          SRv6 Failover with GRASP              March 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4
   3.  Failover Mechanism Overview . . . . . . . . . . . . . . . . .   5
     3.1.  Control Plane and Data Plane Separation . . . . . . . . .   5
     3.2.  Node Roles and Backup Path Requirements . . . . . . . . .   5
       3.2.1.  Anchor Node Definition  . . . . . . . . . . . . . . .   5
       3.2.2.  Bouncer Node Definition . . . . . . . . . . . . . . .   5
       3.2.3.  Backup Path Requirements  . . . . . . . . . . . . . .   5
     3.3.  Before Failure: Protection Information Distribution . . .   6
     3.4.  Failure Detection . . . . . . . . . . . . . . . . . . . .   6
     3.5.  After Failure: Bounce-back and Re-encapsulation . . . . .   6
   4.  GRASP Objective for Failover Path Management  . . . . . . . .   7
     4.1.  Failover Path Manager Objective . . . . . . . . . . . . .   7
     4.2.  Objective Value Definition  . . . . . . . . . . . . . . .   7
     4.3.  Objective Example . . . . . . . . . . . . . . . . . . . .   7
   5.  Failover Procedures and Scenarios . . . . . . . . . . . . . .   9
     5.1.  GRASP Procedures  . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Forwarding Behavior Requirements  . . . . . . . . . . . .   9
     5.3.  Intra-domain Scenario . . . . . . . . . . . . . . . . . .   9
       5.3.1.  Topology and Configuration  . . . . . . . . . . . . .   9
       5.3.2.  Failover Execution Example  . . . . . . . . . . . . .  10
     5.4.  Inter-domain Scenario . . . . . . . . . . . . . . . . . .  11
   6.  Implementation Considerations . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  GRASP Objective Name  . . . . . . . . . . . . . . . . . .  11
     8.2.  Node Role Registry  . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Complete CDDL Definition . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14






Du, et al.              Expires 2 September 2026                [Page 2]

Internet-Draft          SRv6 Failover with GRASP              March 2026


1.  Introduction

   Segment Routing over IPv6 (SRv6) [RFC8986] 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 [RFC9256] 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 [RFC8990] to autonomically distribute
   failover protection information during path setup.  The ACP [RFC8994]
   and BRSKI [RFC8995] provide the security foundation.

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.







Du, et al.              Expires 2 September 2026                [Page 3]

Internet-Draft          SRv6 Failover with GRASP              March 2026


2.  Terminology and Abbreviations

   This document uses the terminology defined in [RFC7575] and
   [RFC8986].

   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.




Du, et al.              Expires 2 September 2026                [Page 4]

Internet-Draft          SRv6 Failover with GRASP              March 2026


3.  Failover Mechanism Overview

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

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

3.2.  Node Roles and Backup Path Requirements

   Each node on the primary path is assigned one of two roles:

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

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

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












Du, et al.              Expires 2 September 2026                [Page 5]

Internet-Draft          SRv6 Failover with GRASP              March 2026


                       +----+     +----+     +----+
                       | b1 |-----| b2 |-----| b3 |
                       +----+     +----+     +----+
                   /                                    \
   +----+     +----+     +----+     +----+     +----+     +----+
   | h1 |-----| n1 |-----| n2 |-----| n3 |-----| n4 |-----| h2 |
   +----+     +----+     +----+     +----+     +----+     +----+
              Anchor     Anchor     Bouncer    Bouncer
                             \                          /
                                   +----+     +----+
                                   | b4 |-----| b5 |
                                   +----+     +----+

   Primary Path: h1 -> 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)

            Figure 1: Topology with Node Roles and Backup Paths

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

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

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



Du, et al.              Expires 2 September 2026                [Page 6]

Internet-Draft          SRv6 Failover with GRASP              March 2026


4.  GRASP Objective for Failover Path Management

4.1.  Failover Path Manager Objective

   The objective name is "SRv6-Failover" conforming to [RFC8990].
   Format in CDDL [RFC8610]:

   objective = ["SRv6-Failover", objective-flags, loop-count, ?objective-value]
   objective-name = "SRv6-Failover"
   objective-flags = uint .bits objective-flag
   loop-count = 0..255
   objective-value = srv6-failover-value

                      Figure 2: GRASP Objective Format

4.2.  Objective Value Definition

   srv6-failover-value = [flow-info, primary-path-info, *node-protection-info]

   flow-info = [flow-id, source-address, destination-address, lifetime]
   flow-id = uint
   source-address = bytes .size 16
   destination-address = bytes .size 16
   lifetime = uint

   primary-path-info = [primary-segment-list, *anchor-backup-entry]
   primary-segment-list = [*srv6-sid]
   srv6-sid = bytes .size 16
   anchor-backup-entry = [anchor-address, backup-segment-list]

   node-protection-info = [node-address, node-role, upstream-neighbor, downstream-neighbor, ?backup-info]
   node-role = &(anchor: 0, bouncer: 1)
   backup-info = [backup-segment-list, backup-next-hop]

               Figure 3: Flow and Path Information Structure

4.3.  Objective Example

   For the following topology and primary path:












Du, et al.              Expires 2 September 2026                [Page 7]

Internet-Draft          SRv6 Failover with GRASP              March 2026


                       +----+     +----+     +----+
                       | b1 |-----| b2 |-----| b3 |
                       +----+     +----+     +----+
                   /                                    \
   +----+     +----+     +----+     +----+     +----+     +----+
   | h1 |-----| n1 |-----| n2 |-----| n3 |-----| n4 |-----| h2 |
   +----+     +----+     +----+     +----+     +----+     +----+
              Anchor     Anchor     Bouncer    Bouncer
                             \                          /
                                   +----+     +----+
                                   | b4 |-----| b5 |
                                   +----+     +----+

   Primary Path: h1 -> n1 -> n2 -> n3 -> n4 -> h2
   Flow Identifier: 0x0000a

                         Figure 4: Example Topology

   The GRASP objective value would contain:

   srv6-failover-value = [
     ; flow-info
     [0x0000a, h1-address, h2-address, 3600000],

     ; primary-path-info
     [
       [n1-sid, n2-sid, n3-sid, n4-sid, h2-sid],  ; primary segment list
       [n1-address, [b1-sid, b2-sid, b3-sid, h2-sid]],  ; n1's backup
       [n2-address, [b4-sid, b5-sid, h2-sid]]           ; n2's backup
     ],

     ; node-protection-info for n1 (Anchor)
     [n1-address, 0, h1-address, n2-address,
      [[b1-sid, b2-sid, b3-sid, h2-sid], b1-address]],

     ; node-protection-info for n2 (Anchor)
     [n2-address, 0, n1-address, n3-address,
      [[b4-sid, b5-sid, h2-sid], b4-address]],

     ; node-protection-info for n3 (Bouncer)
     [n3-address, 1, n2-address, n4-address],

     ; node-protection-info for n4 (Bouncer)
     [n4-address, 1, n3-address, h2-address]
   ]

                     Figure 5: Objective Value Example




Du, et al.              Expires 2 September 2026                [Page 8]

Internet-Draft          SRv6 Failover with GRASP              March 2026


5.  Failover Procedures and Scenarios

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

   +------------------+                      +------------------+
   |     FPM ASA      |                      |     FPM ASA      |
   |  Path Initiator  |                      |  Path Responder  |
   +--------+---------+                      +--------+---------+
            |                                         |
            |    M_DISCOVERY (SRv6-Failover)          |
            |---------------------------------------->|
            |                                         |
            |    M_RESPONSE (locator)                 |
            |<----------------------------------------|
            |                                         |
            |    M_REQ_NEG (node-protection-info)     |
            |---------------------------------------->|
            |                                         |
            |    M_END (O_ACCEPT)                     |
            |<----------------------------------------|
            |                                         |

                   Figure 6: GRASP Negotiation Procedure

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

5.3.  Intra-domain Scenario

5.3.1.  Topology and Configuration












Du, et al.              Expires 2 September 2026                [Page 9]

Internet-Draft          SRv6 Failover with GRASP              March 2026


                       +----+     +----+     +----+
                       | b1 |-----| b2 |-----| b3 |
                       +----+     +----+     +----+
                   /                                    \
   +----+     +----+     +----+     +----+     +----+     +----+
   | h1 |-----| n1 |-----| n2 |-----| n3 |-----| n4 |-----| h2 |
   +----+     +----+     +----+     +----+     +----+     +----+
              Anchor     Anchor     Bouncer    Bouncer
                             \                          /
                                   +----+     +----+
                                   | b4 |-----| b5 |
                                   +----+     +----+

   Primary Path: h1 -> 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

             Figure 7: Intra-domain Topology and Configuration

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






Du, et al.              Expires 2 September 2026               [Page 10]

Internet-Draft          SRv6 Failover with GRASP              March 2026


5.4.  Inter-domain Scenario

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

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

7.  Security Considerations

   This mechanism inherits security considerations of [RFC8990] and
   [RFC8986].

   *  Authentication: All FPM ASA communication MUST occur over ACP
      [RFC8994].  Nodes MUST be authenticated via BRSKI [RFC8995].

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

8.  IANA Considerations

8.1.  GRASP Objective Name

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

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



Du, et al.              Expires 2 September 2026               [Page 11]

Internet-Draft          SRv6 Failover with GRASP              March 2026


   *  1: Bouncer - A node that can only bounce traffic upstream

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

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

9.2.  Informative References






Du, et al.              Expires 2 September 2026               [Page 12]

Internet-Draft          SRv6 Failover with GRASP              March 2026


   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <https://www.rfc-editor.org/info/rfc7575>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

Appendix A.  Complete CDDL Definition

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

   ; SRv6-Failover GRASP Objective CDDL Definition

   srv6-failover-objective = [
     "SRv6-Failover",
     objective-flags,
     loop-count,
     ?srv6-failover-value
   ]

   objective-flags = uint
   loop-count = 0..255

   srv6-failover-value = [
     flow-info,
     primary-path-info,
     *node-protection-info
   ]

   flow-info = [
     flow-id: uint,
     source-address: ipv6-address,
     destination-address: ipv6-address,
     lifetime: uint
   ]

   ipv6-address = bytes .size 16

   primary-path-info = [
     primary-segment-list: [*srv6-sid],
     *anchor-backup-entry
   ]




Du, et al.              Expires 2 September 2026               [Page 13]

Internet-Draft          SRv6 Failover with GRASP              March 2026


   srv6-sid = bytes .size 16

   anchor-backup-entry = [
     anchor-address: ipv6-address,
     backup-segment-list: [*srv6-sid]
   ]

   node-protection-info = [
     node-address: ipv6-address,
     node-role: 0..1,
     upstream-neighbor: ipv6-address,
     downstream-neighbor: ipv6-address,
     ?backup-info
   ]

   backup-info = [
     backup-segment-list: [*srv6-sid],
     backup-next-hop: ipv6-address
   ]

                     Figure 8: Complete CDDL Definition

Acknowledgements

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

Authors' Addresses

   Lintong Du (editor)
   Beijing University of Posts and Telecommunications
   No.10 Xitucheng Road
   Beijing
   Hai-Dian District, 100876
   China
   Email: baronmail@bupt.edu.cn


   Xiangyang Gong
   Beijing University of Posts and Telecommunications
   No.10 Xitucheng Road
   Beijing
   Hai-Dian District, 100876
   China
   Email: xygong@bupt.edu.cn






Du, et al.              Expires 2 September 2026               [Page 14]

Internet-Draft          SRv6 Failover with GRASP              March 2026


   Xirong Que
   Beijing University of Posts and Telecommunications
   No.10 Xitucheng Road
   Beijing
   Hai-Dian District, 100876
   China
   Email: rongqx@bupt.edu.cn


   Fang Deng
   Beijing University of Posts and Telecommunications
   No.10 Xitucheng Road
   Beijing
   Hai-Dian District, 100876
   China
   Email: dengfang@bupt.edu.cn



































Du, et al.              Expires 2 September 2026               [Page 15]
