Skip to main content

Segment Routing for Unaffiliated BFD Echo Function
draft-chen-spring-sr-policy-for-ubfd-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Mach Chen , Xinjun Chen
Last updated 2021-07-12 (Latest revision 2021-01-20)
RFC stream (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-chen-spring-sr-policy-for-ubfd-01
Source Packet Routing in Networking                              M. Chen
Internet-Draft                                                   X. Chen
Intended status: Standards Track                                  Huawei
Expires: January 13, 2022                                  July 12, 2021

           Segment Routing for Unaffiliated BFD Echo Function
                draft-chen-spring-sr-policy-for-ubfd-01

Abstract

   This document describes how to leverage Segment Routing (SR) to
   ensure that the Unaffiliated BFD (U-BFD) Echo packets must reach the
   remote system before being looped back to the local system.  This
   enables that U-BFD works not only for one hop scenario but for
   multiple hops scenario as well.

   In addition, this document also defines a way to explicitly specify
   the loop back path of the U-BFD Echo packets.  This is useful in the
   case where the forward and reverse path of the Echo packets are
   required to follow the same path.

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

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 January 13, 2022.

Chen & Chen             Expires January 13, 2022                [Page 1]
Internet-Draft            SR Unaffiliated Echo                 July 2021

Copyright Notice

   Copyright (c) 2021 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
   (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 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
   2.  Tunnel U-BFD Packets to Remote System . . . . . . . . . . . .   4
   3.  Specify Reverse Path of U-BFD Echo Packets  . . . . . . . . .   4
   4.  Binding SID for Segment-List  . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   BFD Echo function was originally defined in [RFC5880] and [RFC5881],
   where the remote system is required to loop the BFD Echo packets back
   to the local system.  To support BFD Echo Function, some negotiations
   between the local system and remote system are needed, and both the
   local and remote system need to maintain the BFD session state.

   Unaffiliated BFD Echo Function (U-BFD) is defined in
   [I-D.ietf-bfd-unaffiliated-echo].  Where the destination IP address
   of the BFD Echo packets is set to one of the IP addresses of the
   local system.  Therefore, the Echo packets can be automatically
   looped back (through normal IP forwarding) by the remote system to
   the local system.  With U-BFD, the remote system does not need to
   support any BFD related functions and maintain any session states.
   This further simplifies the BFD Echo Function process at the remote
   system hence greatly increases scalability.

Chen & Chen             Expires January 13, 2022                [Page 2]
Internet-Draft            SR Unaffiliated Echo                 July 2021

   But, the U-BFD works when there is only one hop between the local
   system and remote system.  Otherwise, the Echo packets will be
   prematurely looped back by an intermediate node, and the Echo packets
   will not reach the remote system.  This may result in false negative
   issue.  Take the following figure (Figure 1) as an example, if the
   U-BFD is expected to monitor the path between node A and node C, node
   A (as the local system) sets the destination IP to itself and sends
   the Echo packets to node B.  Since node B has the route to node A,
   the Echo packets will be directly forwarded back to node A.  If there
   is a failure on the path between node B and node C, obviously, the
   U-BFD session cannot detect it.

            +-+        +-+         +-+
            |A|--------|B|---------|C|
            +-+        +-+         +-+

           Figure 1, Multi-hop Scenario

   In addition, in some scenarios, for example, mobile backhaul network,
   where the forward and reverse direction of a path are required to
   along the same path.  When apply BFD in mobile backhaul network, it
   also expects that the BFD control packets in both directions follow
   the same path, otherwise, it may result in false positive issue.
   Take the following figure (Figure 2) as an example, there are two
   paths (A-B-C, A-D-C) between node A and node C.  Assuming that it
   expects to monitor the path A-B-C by using BFD, where node A is the
   local system and node C is the remote system.  If node C chooses path
   C-D-A to send the Echo packets, when a failure occurs on path C-D-A,
   node A (the local system) may not receive the BFD packets and
   consider that path A-B-C is failed.  But actually path A-B-C is
   working.

            +-+        +-+         +-+
            |A|--------|B|---------|C|
            +-+        +-+         +-+
             |         +-+          |
             +---------|D|----------+
                       +-+
       Figure 2, Multi-hop, Multi-path Scenario

   To solve the above issues, this document describes how to leverage
   the Segment Routing (SR) [RFC8402] to ensure that the U-BFD Echo
   packets must reach the remote system before being looped back.  This
   enables that U-BFD Echo Function works not only for one hop scenario
   but for multiple hops scenario.  In addition, by using SR policy
   [I-D.ietf-spring-segment-routing-policy], the loop back path of the
   Echo packets can be specified as required.  This is useful in the

Chen & Chen             Expires January 13, 2022                [Page 3]
Internet-Draft            SR Unaffiliated Echo                 July 2021

   case where the forward and loop back path of the Echo packets are
   required to follow the same path.

2.  Tunnel U-BFD Packets to Remote System

   When using U-BFD to monitor a path, the U-BFD echo packets are
   constructed as specified in [I-D.ietf-bfd-unaffiliated-echo], then
   the U-BFD echo packets are encapsulated in an SR tunnel and sent to
   the remote system.  It needs to make sure that the SR tunnel and the
   path being monitored follow the same path and share the same fate,
   otherwise the UP/Down state can not reflect the health of the path
   being monitored.  This can be satisfied if the path itself is an SR
   path, where the U-BFD echo packets, just as other data traffic, are
   transmitted over the SR tunnel to the remote system.  When the packet
   arrives the remote system, the SR encapsulation (e.g, MPLS Label
   Stack, or IPv6 Header with/without SRH) is removed, the inner IP
   header is exposed.  Since the destination IP address of the inner
   header is one of the routable IP addresses of the local system, the
   echo packet will be forwarded back to the local system via IP
   routing.

   If the path is an pure IP path, SR over IP [RFC8663] or SRv6 Best
   Effort (BE) can be used to tunnel the U-BFD echo packets to the
   remote system.  Once the packet reaches the remote system, the remote
   system decapsulates the echo packet and forwards it back to the local
   system based on the inner header.

3.  Specify Reverse Path of U-BFD Echo Packets

   In some cases, for example, mobile backhaul network, bidirectional
   paths are often used.  And in general, the forward and reverse
   direction of the bidirectional path are required to follow the same
   path hence to share the same fate.  Therefore, when apply U-BFD to
   monitor such a bidirectional path, the forward and reserve path the
   U-BFD echo need to follow the same path as well.

   In the case of SR, [I-D.ietf-spring-segment-routing-policy] is
   normally used to implement bidirectional path.  To ensure that the
   U-BFD Echo packets can reach the remote system before looping back to
   the local system, the SR policy MUST have a candidate path that is
   associated with a Segment-List, and the Segment-List MUST include a
   SID that identifies the remote system.  That means the U-BFD Echo
   packets will be tunneled by the SR policy to the remote system, and
   then looped back.

   To specify the loopback path, a series of SIDs or a Binding SID
   (BSID) that is associated with the loopback path MUST be added to the

Chen & Chen             Expires January 13, 2022                [Page 4]
Internet-Draft            SR Unaffiliated Echo                 July 2021

   SID stack of the U-BFD Echo packets.  This can be done through the
   following ways:

   Given the topology in Figure 2, the SR policy can be modeled as
   below:

   1.  Not explicitly specify the reserve path:

     SR policy POL1 <headend = A, color = 1, endpoint = C>
       Candidate-path CP1 <protocol-origin = 20, originator =
                           100:1.1.1.1, discriminator = 1>
         Preference 200
         Weight W1, SID-List <B,C>

       The U-BFD Echo packets are transmitted to the remote system
       according the SR policy.  When the Echo packets reach the remote
       system, they will be decapsulated and then forwarded back to the
       local system according to inner IP header.

   2.  Specify the reverse path by carrying a Reverse Binding Segment
       Identifier (R-BSID):

     SR policy POL2 <headend = A, color = 1, endpoint = C>
       Candidate-path CP1 <protocol-origin = 20, originator =
                           100:1.1.1.1, discriminator = 2>
         Preference 200
         Weight W1, SID-List <B, C>, L-BSID, R-BSID

       Two new attributes, which are referred to as Local BSID (L-BSID)
       and Remote BSID (R-BSID), are introduced to a candidate path.
       Here, the L-BSID or R-BSID is a BSID that correlates to a
       specific SID List rather a candidate path.  The L-BSID is a local
       BSID on the headend, in the above example, it identifies the SID-
       List <B, C>.  The R-BSID identifies another corresponding SID
       list <B, A> that is deployed on the endpoint (Node C) and has the
       same path and share the same fate with SID-list <B, C>.  SID List
       <B, C> and SID List <B, A> form a bidirectional SR path.  With
       this, a SID stack <B, C, R-BSID> will be attached to the U-BFD
       echo packets, the SID B and C will take the echo packets to the
       remote system, the R-BSID will bring the echo packets back to the
       local system.

   3.  Specify the reverse path by explicitly carrying the SID list of
       the reverse path:

Chen & Chen             Expires January 13, 2022                [Page 5]
Internet-Draft            SR Unaffiliated Echo                 July 2021

     SR policy POL2 <headend = A, color = 1, endpoint = A>
       Candidate-path CP1 <protocol-origin = 20, originator =
                           100:1.1.1.1, discriminator = 3>
         Preference 200
         Weight W1, SID-List <B, C>, Reverse SID-List <B, A>

       A new attribute, Reverse SID-List, is introduced to a candidate
       path, it corresponds to a SID-List of the candidate path.  In the
       above example, the SID-List <B, C> and Reverse SID-List <B, A>
       form a bidirectional path.  With this, a SID stack <B, C, B, A>
       will be attached to the U-BFD echo packets, th SID B and C will
       take the echo packets to the remote system, and the SID B and A
       will bring the back to the local system.

4.  Binding SID for Segment-List

   With the current SR policy, a BSID corresponds to a candidate path
   that may have multiple SID Lists.  In the case of bidirectional SR
   path, the forward or reverse path corresponds to a specific SID List.
   In order to identify a SID List with a SID, the straightforward idea
   is to define a BSID to for SID list.  A bidirectional SR path
   correlates to two SID Lists: the forward SID List and the reverse SID
   List.  Therefore, two BSIDs (L-BSID and R-BSID) need to be defined
   for a bidirectional SR path to identify the corresponding SID list.

   An information model of a SR policy with the L-BSID and R-BSID is as
   follows:

     SR policy POL1 <headend = H1, color = 1, endpoint = E1>
       Candidate-path CP1 <protocol-origin = 20, originator =
                           100:1.1.1.1, discriminator = 1>
         Preference 100
         Weight W1, SID-List1 <SID11...SID1i>, L-BSID-1, R-BSID-1

       Candidate-path CP2 <protocol-origin = 20, originator =
                           100:1.1.1.1, discriminator = 2>
         Preference 200
         Weight W2, SID-List2 <SID21...SID2j>, L-BSID-2, R-BSID-2

   The POL1 has two candidate paths, CP1 and CP2.  Each has a SID-List,
   a Local BSID (L-BSID) and a Reverse BSID (R-BSID).  The L-BSID
   corresponds to the SID List (e.g., L-BSID-1 corresponds to SID-List
   <SID11...SID1i>).  The R-BSID corresponds a SID List of a candidate
   path of a policy that is deployed on the endpoint (E1), as following.
   Assume that the SID-List1 of POL1 and the SID-List1 of POL2 form a
   bidirectional SR path.  For policy POL1, the R-BSID-1 is the same as

Chen & Chen             Expires January 13, 2022                [Page 6]
Internet-Draft            SR Unaffiliated Echo                 July 2021

   the L-BSID-1' of policy POL2; and the R-BSID-1' of POL2 is the same
   as the L-BSID-1 of policy POL1.

     SR policy POL2 <headend = E1, color = 1, endpoint = H1>
       Candidate-path CP1 <protocol-origin = 20, originator =
                           200:1.1.1.1, discriminator = 1>
         Preference 100
         Weight W1, SID-List1 <SID11...SID1i>, L-BSID-1', R-BSID-1'

       Candidate-path CP2 <protocol-origin = 20, originator =
                           200:1.1.1.1, discriminator = 2>
         Preference 200
         Weight W2, SID-List2 <SID21...SID2j>, L-BSID-2', R-BSID-2'

   Therefore, to deploy such a policy, it needs to know the R-BSID of
   the corresponding reverse SID List.  It assumes that a controller
   will learn the L-BSID of each SID list and is responsible for the
   configuration of SR policy on both the headend and endpoint of the SR
   policies.

   The corresponding BGP or PECP extensions in support of SR policy with
   BSID for SID List will be defined in future version.

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   This document does not introduce additional security requirements and
   mechanisms other than the ones described in
   [I-D.ietf-bfd-unaffiliated-echo] and
   [I-D.ietf-spring-segment-routing-policy].

7.  Acknowledgements

8.  Contributors

   The following people have substantially contributed to this document:

Chen & Chen             Expires January 13, 2022                [Page 7]
Internet-Draft            SR Unaffiliated Echo                 July 2021

      Pingwei Fan
      Huawei

      EMail: fanpingwei@huawei.com

      Sheng Fang
      Huawei

      EMail: fangsheng@huawei.com

9.  References

9.1.  Normative References

   [I-D.ietf-bfd-unaffiliated-echo]
              Cheng, W., Wang, R., Min, X., Rahman, R., and R. C.
              Boddireddy, "Unaffiliated BFD Echo Function", draft-ietf-
              bfd-unaffiliated-echo-01 (work in progress), November
              2020.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-11 (work in progress),
              April 2021.

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

9.2.  Informative References

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

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              DOI 10.17487/RFC5881, June 2010,
              <https://www.rfc-editor.org/info/rfc5881>.

Chen & Chen             Expires January 13, 2022                [Page 8]
Internet-Draft            SR Unaffiliated Echo                 July 2021

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

   [RFC8663]  Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
              W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
              DOI 10.17487/RFC8663, December 2019,
              <https://www.rfc-editor.org/info/rfc8663>.

Authors' Addresses

   Mach(Guoyi) Chen
   Huawei

   Email: mach.chen@huawei.com

   Xinjun Chen
   Huawei

   Email: ifocus.chen@huawei.com

Chen & Chen             Expires January 13, 2022                [Page 9]