Skip to main content

Encapsulation of BFD for SRv6 Policy
draft-liu-spring-bfd-srv6-policy-encap-00

Document Type Active Internet-Draft (individual)
Authors Yisong Liu , Weiqiang Cheng , Changwang Lin , Mengxiao Chen , Xiao Min
Last updated 2022-10-21
Replaces draft-liu-bfd-srv6-policy-encap
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-spring-bfd-srv6-policy-encap-00
Network Working Group                                            Y. Liu
Internet Draft                                                 W. Cheng
Intended status: Standards Track                           China Mobile
Expires: April 21, 2023                                          C. Lin
                                                                M. Chen
                                                   New H3C Technologies
                                                                 X. Min
                                                                    ZTE
                                                       October 21, 2022

                   Encapsulation of BFD for SRv6 Policy
                 draft-liu-spring-bfd-srv6-policy-encap-00

Abstract

   Bidirectional Forwarding Detection (BFD) mechanisms can be used for
   fast detection of failures in the forwarding path of SR Policy. This
   document describes the encapsulation of BFD for SRv6 Policy, which
   can be applied for both S-BFD and U-BFD. The BFD packets may be
   encapsulated in transport mode or tunnel mode.

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 April 21, 2023.

Copyright Notice

   Copyright (c) 2023 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

Liu, et al.              Expire April, 2023                   [Page 1]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   (http://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 Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................2
      1.1. Requirements Language.....................................3
   2. Encapsulation of BFD Packet for SRv6 Policy....................3
      2.1. Control Packet in Transport Mode..........................4
      2.2. Echo Packet in Transport Mode.............................6
      2.3. Control Packet in Tunnel Mode.............................7
      2.4. Echo Packet in Tunnel Mode................................8
   3. Choice of Headend and Tail-end IPv6 Addresses.................10
      3.1. Control Packet...........................................10
      3.2. Echo Packet..............................................10
   4. Checksum in UDP Header........................................11
   5. Control of Inserting Additional IPv6 Address in SRH...........11
   6. Example.......................................................11
   7. Security Considerations.......................................13
   8. IANA Considerations...........................................13
   9. References....................................................14
      9.1. Normative References.....................................14
      9.2. Informative References...................................15
   Authors' Addresses...............................................16

1. Introduction

   Segment Routing (SR) [RFC8402] allows a headend node to steer a
   packet flow along any path. Per-path states of Intermediate nodes
   are eliminated thanks to source routing. A Segment Routing Policy
   (SR Policy) [I-D.ietf-spring-segment-routing-policy] is an ordered
   list of segments (i.e., instructions) that represent a source-routed
   policy. The packets steered into an SR Policy carry an ordered list
   of segments associated with that SR Policy. The SRv6 Policy is the
   instantiation of SR Policy for SR over IPv6 (SRv6) data-plane.

   In order to provide end-to-end protection, the headend node need to
   rapidly detect any failures in the forwarding path of SR Policy, so
   that it could switch from the active candidate path to another
   backup candidate path within the same SR Policy or switch from the
   active SR Policy to another backup SR Policy. Bidirectional

Liu, et al.              Expires April, 2023                  [Page 2]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   Forwarding Detection (BFD) mechanisms [RFC5880] [RFC7880] can be
   used for fast detection of such failures.

   As described in [I-D.ali-spring-bfd-sr-policy], the BFD mechanism to
   be used for monitoring SRv6 Policies is expected to be simple and
   lightweight, which can be setup and deleted dynamically and on-
   demand. Seamless Bidirectional Forwarding Detection (S-BFD)
   [RFC7880] simplifies the mechanism for using BFD with a large
   proportion of negotiation aspects eliminated. [I-D.ali-spring-bfd-
   sr-policy] describes the use of S-BFD for monitoring of SR Policy
   paths, and specifies the S-BFD Discriminator selection, the S-BFD
   session initiation and the return path control related to S-BFD use
   for SR Policy.

   Unaffiliated BFD Echo Function (U-BFD) [I-D.ietf-bfd-unaffiliated-
   echo] simplifies the BFD Echo Function procedure, by which the
   remote system does not need to support BFD or maintain any BFD
   session states. U-BFD may also be used to monitor SR Policies.

   This document describes the encapsulation of BFD for SRv6 Policy,
   which can be applied for both S-BFD and U-BFD. The BFD packets may
   be encapsulated in transport mode or tunnel mode.

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. Encapsulation of BFD Packet for SRv6 Policy

   On SRv6 data-plane, a BFD packet for SRv6 Policy carries a Segment
   Routing Header (SRH) [RFC8754] containing a list of SRv6 SIDs
   associated with that SRv6 Policy.

   The BFD packets may be encapsulated in transport mode or tunnel
   mode. In transport mode, the SRH is inserted after the IPv6 header.
   In tunnel mode, an outer IPv6 header with an SRH is encapsulated,
   which looks like an BFD packet for plain IPv6 is steered into an
   SRv6 Policy.

Liu, et al.              Expires April, 2023                  [Page 3]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   +-------------+---------+-------------+------------+
   | IPv6 header |   SRH   | UDP Header  |  Payload   |
   +-------------+---------+-------------+------------+

   Figure 1: Transport Mode Encapsulation

   +-------------+---------+-------------+------------+------------+
   | IPv6 header |   SRH   | IPv6 header | UDP Header |  Payload   |
   +-------------+---------+-------------+------------+------------+

   Figure 2: Tunnel Mode Encapsulation

   An SRv6 Policy may consist of multiple candidate paths, and each
   candidate path may consist of multiple Segment-Lists. To monitor a
   candidate path, an implementation may setup multiple sessions for
   each Segment-List associated with that path. If some of the Segment-
   Lists fail, the forwarding will be weighted load-balancing among the
   other Segment-Lists. If all of the Segment-Lists fail, the candidate
   path is deemed to be failed. An implementation may monitor each
   candidate path belonging to the SRv6 Policy respectively. If the
   active candidate path fails, the switchover to another backup
   candidate path will be triggered. If all the candidate paths fails,
   the SRv6 Policy is deemed to be failed. How to setup sessions for
   the candidate paths and Segment-Lists associated with an SRv6 Policy
   is out of the scope of this document.

2.1. Control Packet in Transport Mode

   In transport mode, the encapsulation format of BFD control packet is
   as follows:

Liu, et al.              Expires April, 2023                  [Page 4]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   +-----------------------------------------------------------+
   | IPv6 Header                                               |
   .  Source IP Address = Headend IPv6 Address                 .
   .  Destination IP Address = Segment List[SL]                .
   .  Next-Header = SRH                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | SRH                                                       |
   .  Segment List[0] = Tail-end IPv6 Address, or              .
   .                  Last Segment of SRv6 Policy Segment-List .
   .  Segment List[1]                                          .
   .  Segment List[2]                                          .
   .  ...                                                      .
   .  Next-Header = UDP                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | UDP Header                                                |
   .                                                           .
   +-----------------------------------------------------------+
   | Payload                                                   |
   .                                                           .
   +-----------------------------------------------------------+

   Figure 3: Format of Control Packet in Transport Mode

   In the SRH, the first element of the Segment List (Segment List[0])
   contains the SRv6 SID or IPv6 address of the tail-end node.

   If the last segment of the SRv6 Policy Segment-List does not belong
   to the tail-end node, an IPv6 address of tail-end should be added as
   Segment List[0], while Segment List[1] contains the last segment of
   the SRv6 Policy Segment-List. The typical scenarios are as follows:

   o The last segment of the SRv6 Policy Segment-List may be an End.X
      SID of the penultimate hop. If it is used as Segment List[0], the
      final destination for the BFD packet is missing.

   o The last segment of the SRv6 Policy Segment-List may be a Binding
      SID, for example, the application of SRv6 Policy for L3VPN
      service across multiple domains. If it is used as Segment
      List[0], according to [RFC8986], the node which instantiates the
      BSID will not perform the encapsulation behavior of the
      associated SRv6 Policy, but stop processing the SRH and proceed
      to process the next header in the packet.

   Else, the additional tail-end IPv6 address is not necessary, and it
   can be omitted in order to reduce the SRH size.

Liu, et al.              Expires April, 2023                  [Page 5]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   After tail-end receives the control packet, it will send response
   packet back to the headend. The response packet is IP routed based
   on the IPv6 SA of the control packet from headend. Additional
   measures may be taken to control the forwarding path of response
   packet, which is out of the scope of this document.

2.2. Echo Packet in Transport Mode

   In transport mode, the encapsulation format of BFD echo packet is as
   follows:

   +-----------------------------------------------------------+
   | IPv6 Header                                               |
   .  Source IP Address = Headend IPv6 Address                 .
   .  Destination IP Address = Segment List[SL]                .
   .  Next-Header = SRH                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | SRH                                                       |
   .  Segment List[0] = Headend IPv6 Address                   .
   .  Segment List[1]                                          .
   .  Segment List[2]                                          .
   .  ...                                                      .
   .  Next-Header = UDP                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | UDP Header                                                |
   .                                                           .
   +-----------------------------------------------------------+
   | Payload                                                   |
   .                                                           .
   +-----------------------------------------------------------+

   Figure 4: Format of Echo Packet in Transport Mode

   The BFD echo packet u-turns on the tail-end node and returns to the
   headend node. The difference from the control packet is that the
   final destination of the echo packet is the headend itself. So,
   Segment List[0] in the SRH should contain the IPv6 address of the
   headend, in order to indicate the tail-end to forward the echo
   packet back to headend. The return path is IP routed.

   In both S-BFD and U-BFD for SRv6 Policy, the echo packet may be used
   to control the return path. After the echo packet reaches the tail-
   end along the forwarding path of SRv6 Policy Segment-List,
   additional segments will indicate the packet to be forwarded along
   specific path back to the headend.

Liu, et al.              Expires April, 2023                  [Page 6]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   If segments of the return path is included in the SRH of echo packet
   and the last segment of the return path belongs to the headend, the
   additional headend IPv6 address is not necessary to be added as
   Segment List[0]. How to identify corresponding segment stack for the
   return paths is outside the scope of this document.

2.3. Control Packet in Tunnel Mode

   In tunnel mode, the encapsulation format of BFD control packet is as
   follows:

   +-----------------------------------------------------------+
   | IPv6 Header                                               |
   .  Source IP Address = Headend IPv6 Address                 .
   .  Destination IP Address = Segment List[SL]                .
   .  Next-Header = SRH                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | SRH                                                       |
   .  Segment List[0] = Tail-end IPv6 Address, or              .
   .                  Last Segment of SRv6 Policy Segment-List .
   .  Segment List[1]                                          .
   .  Segment List[2]                                          .
   .  ...                                                      .
   .  Next-Header = IPv6                                       .
   .                                                           .
   +-----------------------------------------------------------+
   | IPv6 Header                                               |
   .  Source IP Address = Headend IPv6 Address                 .
   .  Destination IP Address = Tail-end IPv6 Address           .
   .  Next-Header = UDP                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | UDP Header                                                |
   .                                                           .
   +-----------------------------------------------------------+
   | Payload                                                   |
   .                                                           .
   +-----------------------------------------------------------+

   Figure 5: Format of Control Packet in Tunnel Mode

   In the SRH, the first element of the Segment List (Segment List[0])
   contains the SRv6 SID or IPv6 address of the tail-end node.

   If the last segment of the SRv6 Policy Segment-List does not belong
   to the tail-end node and its function does not include decapsulation
   of the outer IPv6 header, an IPv6 address of tail-end should be

Liu, et al.              Expires April, 2023                  [Page 7]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   added as Segment List[0], while Segment List[1] contains the last
   segment of the SRv6 Policy Segment-List. The typical scenarios are
   as follows:

   o The last segment of the SRv6 Policy may be an End.X SID of the
      penultimate hop. If it is used as Segment List[0], the
      penultimate hop needs to remove the outer IPv6 header with all
      SRH, and forwards the inner IPv6 packet to reflector. If the last
      segment is with Ultimate Segment Decapsulation (USD) flavor, the
      penultimate SR endpoint node will perform such decapsulation as
      defined in [RFC8986]. Otherwise, how to process the packet when
      the upper-layer header type is IPv6, is not clearly defined in
      [RFC8986]. It depends on implementation, and may not work well
      for BFD.

   o The last segment of the SRv6 Policy may be a Binding SID, which
      is the same with the Binding SID case in section 2.1.

   Else, the additional tail-end IPv6 address is not necessary, and it
   can be omitted in order to reduce the SRH size.

   After tail-end receives the control packet, it will send response
   packet back to the headend. The response packet is IP routed based
   on the inner IPv6 SA of the control packet from headend. Additional
   measures may be taken to control the forwarding path of response
   packet, which is out of the scope of this document.

2.4. Echo Packet in Tunnel Mode

   In tunnel mode, the encapsulation format of BFD echo packet is as
   follows:

Liu, et al.              Expires April, 2023                  [Page 8]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   +-----------------------------------------------------------+
   | IPv6 Header                                               |
   .  Source IP Address = Headend IPv6 Address                 .
   .  Destination IP Address = Segment List[SL]                .
   .  Next-Header = SRH                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | SRH                                                       |
   .  Segment List[0] = Tail-end IPv6 Address, or              .
   .                  Last Segment of SRv6 Policy Segment-List .
   .  Segment List[1]                                          .
   .  Segment List[2]                                          .
   .  ...                                                      .
   .  Next-Header = IPv6                                       .
   .                                                           .
   +-----------------------------------------------------------+
   | IPv6 Header                                               |
   .  Source IP Address = Headend IPv6 Address                 .
   .  Destination IP Address = Headend IPv6 Address            .
   .  Next-Header = UDP                                        .
   .                                                           .
   +-----------------------------------------------------------+
   | UDP Header                                                |
   .                                                           .
   +-----------------------------------------------------------+
   | Payload                                                   |
   .                                                           .
   +-----------------------------------------------------------+

   Figure 6: Format of Echo Packet in Tunnel Mode

   If the last segment of the SRv6 Policy Segment-List does not belong
   to the tail-end node, an IPv6 address of tail-end should be added as
   Segment List[0], in order to guarantee that the packet can reach the
   tail-end.

   After the tail-end receives the echo packet, it decapsulates the
   outer IPv6 header with SRH, and then forwards the inner IPv6 packet
   back to the headend based on the IPv6 DA.

   If additional segments of the return path are included in the SRH of
   echo packet, the tail-end IPv6 address should not be included in the
   SRH. The segment stack should guarantee that the packet can reach
   the tail-end and then goes back to the headend. How to identify
   corresponding segment stack for the return paths are outside the
   scope of this document.

Liu, et al.              Expires April, 2023                  [Page 9]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

3. Choice of Headend and Tail-end IPv6 Addresses

3.1. Control Packet

   When traffics are steered into an SRv6 Policy, the headend
   encapsulates the received packets in an outer IPv6 header along with
   an SRH. The Source Address of the outer IPv6 header is an IPv6
   Address of the headend itself which can be routed. It may be a local
   interface address of the headend used for all SRv6 Policies. Or,
   different source addresses may be allocated per SRv6 Policy by local
   configuration.

   For the BFD control packet, the headend IPv6 address in the Source
   Address of IPv6 header may use the source address associated with
   the SRv6 Policy.

   An SRv6 Policy is identified through the tuple <headend, color,
   endpoint>. The endpoint indicates the destination of the policy, and
   is usually specified as an IPv6 address of the tail-end node.

   For the BFD control packet, the headend may choose endpoint of the
   SRv6 Policy to be the tail-end IPv6 address which appears in the
   first segment of SRH or DA of inner IPv6 header, without additional
   knowledge of the tail-end. However, in some scenarios, the endpoint
   of SRv6 Policy can be the unspecified address (:: for IPv6), and the
   tail-end IPv6 Address may be specified by local configuration or
   network controller.

3.2. Echo Packet

   For the BFD echo packet, the headend IPv6 address in the Source
   Address of IPv6 header may use the source address associated with
   the SRv6 Policy, which is similar with the control packet.

   Because the echo packet u-turns on the tail-end, the tail-end does
   not need to parse the packet or use the source address as the
   destination address to send back, which is different from the
   control packet. So, the SA of echo packet is not necessary to be
   routable. An implementation may use unreachable address as the
   headend IPv6 address in the SA, which would prevent icmpv6 messages
   from flooding into the headend in failure cases.

   For the headend IPv6 address which appears in the first segment of
   SRH or DA of inner IPv6 header of the echo packet, it should be an
   IPv6 address belonging to the headend and can be routed. An
   implementation may use the source address associated with the SRv6
   Policy. Or, particular addresses may be allocated per SRv6 Policy by

Liu, et al.              Expires April, 2023                 [Page 10]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   local configuration, in order to distinguish the BFD echo packets
   for different SRv6 Policies.

4. Checksum in UDP Header

   The computation of Checksum in UDP header includes the Destination
   Address of IPv6 header.

   In the encapsulation of transport mode, the IPv6 DA may change along
   the SRv6 forwarding path. When computing the UDP Checksum, the
   headend should use the first segment in the SRH as the IPv6 DA. It
   is consistent with the packet received by the final destination, the
   tail-end node for control packet or the headend node for echo
   packet. So, when the final destination processes the UDP header, the
   verification of Checksum will be passed.

   In the encapsulation of tunnel mode, the computation of UDP Checksum
   only involves the inner IPv6 header, which does not change en route.
   No additional action needs to be taken.

5. Control of Inserting Additional IPv6 Address in SRH

   An implementation may have local configurations to control whether
   to insert a headend or tail-end IPv6 address as the first segment in
   the SRH. Or, an implementation may always insert additional IPv6
   address.

6. Example

   In the following network, the headend A installs an SRv6 Policy to
   tail-end D with the segment list <SID-A1, SID-B1, SID-C1>. SID-A1,
   SID-B1 and SID-C1 are all SRv6 End.X SIDs.

   A--------------B-------------C-----------D

   Figure 7: example network

   Assume that A uses SBFD to monitor that SRv6 Policy. A may send S-
   BFD control packet in transport mode, as shown in Figure 8.

Liu, et al.              Expires April, 2023                 [Page 11]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   +=================+                      +=================+
   | IPv6 Header     |                      | IPv6 Header     |
   +-----------------+                      +-----------------+
   | SA=A's Addr     |                      | SA=A's Addr     |
   | DA=SID-B1       |                      | DA=D's Addr     |
   +=================+                      +=================+
   | SRH             |                      | SRH             |
   +-----------------+                      +-----------------+
   | SL=2            |                      | SL=0            |
   | Seg[0]=D's Addr |                      | Seg[0]=D's Addr |
   | Seg[1]=SID-C1   |                      | Seg[1]=SID-C1   |
   | Seg[2]=SID-B1   |                      | Seg[2]=SID-B1   |
   | Seg[3]=SID-A1   |                      | Seg[3]=SID-A1   |
   +=================+                      +=================+
   | UDP-header      |                      | UDP-header      |
   +=================+                      +=================+
   | Payload         |                      | Payload         |
   +=================+                      +=================+
           A------------->B------------>C---------->D

   Figure 8: Example of S-BFD Control Packet in Transport Mode

   Assume that A uses U-BFD to monitor that SRv6 Policy. A may send U-
   BFD echo packet in tunnel mode, as shown in Figure 9.

Liu, et al.              Expires April, 2023                 [Page 12]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

   +=================+                      +=================+
   | IPv6 Header     |                      | IPv6 Header     |
   +-----------------+                      +-----------------+
   | SA=A's Addr     |                      | SA=A's Addr     |
   | DA=SID-B1       |                      | DA=D's Addr     |
   +=================+                      +=================+
   | SRH             |                      | SRH             |
   +-----------------+                      +-----------------+
   | SL=2            |                      | SL=0            |
   | Seg[0]=D's Addr |                      | Seg[0]=D's Addr |
   | Seg[1]=SID-C1   |                      | Seg[1]=SID-C1   |
   | Seg[2]=SID-B1   |                      | Seg[2]=SID-B1   |
   | Seg[3]=SID-A1   |                      | Seg[3]=SID-A1   |
   +=================+                      +=================+
   | IPv6 Header     |                      | IPv6 Header     |
   +-----------------+                      +-----------------+
   | SA=A's Addr     |                      | SA=A's Addr     |
   | DA=A's Addr     |                      | DA=A's Addr     |
   +=================+                      +=================+
   | UDP-header      |                      | UDP-header      |
   +=================+                      +=================+
   | Payload         |                      | Payload         |
   +=================+                      +=================+
            -------------> ------------> ---------->
           A              B             C           D
            <------------- <------------ <----------
   +=================+                      +=================+
   | IPv6 Header     |                      | IPv6 Header     |
   +-----------------+                      +-----------------+
   | SA=A's Addr     |                      | SA=A's Addr     |
   | DA=A's Addr     |                      | DA=A's Addr     |
   +=================+                      +=================+
   | UDP-header      |                      | UDP-header      |
   +=================+                      +=================+
   | Payload         |                      | Payload         |
   +=================+                      +=================+

   Figure 9: Example of U-BFD Echo Packet in Tunnel Mode

7. Security Considerations

   TBD.

8. IANA Considerations

   This document has no IANA actions.

Liu, et al.              Expires April, 2023                 [Page 13]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

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

   [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
             Decraene, B., Litkowski, S., and R. Shakir, "Segment
             Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
             July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC9256] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
             P. Mattes, "Segment Routing Policy Architecture", RFC9256,
             DOI 10.17487/RFC9256, July 2022,
             <https://datatracker.ietf.org/info/rfc9256>.

   [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
             (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
             <http://www.rfc-editor.org/info/rfc5880>.

   [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
             Pallagatti, "Seamless Bidirectional Forwarding Detection
             (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
             <https://www.rfc-editor.org/info/rfc7880>.

   [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
             Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
             (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
             <https://www.rfc-editor.org/info/rfc8754>.

   [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
             0.17487/RFC8986, February 2021, <https://www.rfc-
             editor.org/info/rfc8986>.

Liu, et al.              Expires April, 2023                 [Page 14]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

9.2. Informative References

   [I-D.ali-spring-bfd-sr-policy] Ali, Z., Talaulikar, K., Filsfils,
             C., Nainar, N., and C. Pignataro, "Bidirectional
             Forwarding Detection (BFD) for Segment Routing Policies
             for Traffic Engineering", Work in Progress, Internet-
             Draft, draft-ali-spring-bfd-sr-policy-09, 8 May 2022,
             <http://www.ietf.org/internet-drafts/draft-ali-spring-bfd-
             sr-policy-09.txt>.

   [I-D.ietf-bfd-unaffiliated-echo] Cheng, W., Wang, R., Min, X.,
             Rahman, R., and R. C. Boddireddy, "Unaffiliated BFD Echo",
             Work in Progress, Internet-Draft, draft-ietf-bfd-
             unaffiliated-echo-05, 1 August 2022,
             <https://www.ietf.org/archive/id/draft-ietf-bfd-
             unaffiliated-echo-05.txt>.

Liu, et al.              Expires April, 2023                 [Page 15]
Internet-Draft    Encapsulation of BFD for SRv6 Policy     October 2022

Authors' Addresses

   Yisong Liu
   China Mobile
   China
   Email: liuyisong@chinamobile.com

   Weiqiang Cheng
   China Mobile
   China
   Email: chengweiqiang@chinamobile.com

   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com

   Mengxiao Chen
   New H3C Technologies
   China
   Email: chen.mengxiao@h3c.com

   Xiao Min
   ZTE Corp.
   China
   Email: xiao.min2@zte.com.cn

Liu, et al.              Expires April, 2023                 [Page 16]