Skip to main content

BIER Loop Avoidance using Segment Routing
draft-liu-bier-uloop-00

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 Yisong Liu , Changwang Lin , Yuanxiang Qiu
Last updated 2023-10-23
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-liu-bier-uloop-00
BIER Working Group
Internet-Draft                                                   Y. Liu
Intended status: Standards Track                           China Mobile
Expires: April 25, 2024                                          C. Lin
                                                                 Y. Qiu
                                                   New H3C Technologies
                                                       October 23, 2023

                 BIER Loop Avoidance using Segment Routing
                          draft-liu-bier-uloop-00

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 25, 2024.

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

Liu, et al.              Expires April, 2024                   [Page 1]
Internet-Draft           BIER loop Avoidance              October 2023

   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   This document provides a mechanism leveraging SR-MPLS and/or SRv6 to
   ensure that BIER messages can be forwarded loop-freeness during the
   IGP reconvergence process following a link-state change event.

Table of Contents

   1. Introduction...................................................3
      1.1. Requirements Language.....................................4
   2. Loop-free convergence process..................................4
   3. Computing Loop-avoiding Path...................................4
      3.1. Explicit Path of Loop-avoiding............................5
      3.2. Calculation Method of Explicit Path.......................5
   4. Example Application............................................6
   5. IANA Considerations............................................7
   6. Security Considerations........................................7
   7. References.....................................................7
      7.1. Normative References......................................7
      7.2. Informative References....................................8
   8. Acknowledgments................................................8
   Authors' Addresses................................................9

liu, et al.              Expires April, 2024                   [Page 2]
Internet-Draft           BIER loop Avoidance              October 2023

  1. Introduction

   Forwarding loops happen during the convergence of the IGP, as a
   result of transient inconsistency among forwarding states of the
   nodes of the network.

   When the network topology changes, loops may appear on new
   forwarding paths due to the different convergence speeds of each
   node's routing.

   During the multicast packet forwarding process, when the upstream
   BFR senses that its BFR-NBR is not reachable, the upstream BFR as a
   PLR node can quickly switch multicast traffic to backup path through
   the BIER FRR mechanism [I-D.ietf-bier-frr]. If the network fails to
   recover, multicast traffic will switch back from the backup path to
   the primary path.

   As shown in Figure 1 below, R1 is connected to the multicast source,
   and all IGP links are symmetric metric. Except for the link cost
   between G and H, which is 100, the cost of all other links is 1. The
   multicast data packet sent from R1 to R9 is initially forwarded
   along the path R1->R2->R3->R4->R9. When the link between R2 and R3
   fails, or node R3 fails, there may be a loop in traffic between R2
   and R7.

         SRC --- R1 ----- R2 ------ R3----- R4
                 |        |                 | \
                 |        |                 |   \
                 |        |                 |     \
                 R5 ----- R6 ------ R7------R8----- R9----Receiver
                                       100
                             Figure 1

   When R2 senses that R3's route is unreachable, R2 will send the
   packet to backup BFR-NBR R6. However, because R6's BIFT has not yet
   been updated, the BFR-NBR recorded on R6 to BFER R9 is still R2.
   Therefore, after R6 receives the multicast packet, it will send the
   packet to R9 according to the bitstring in the BIER header.
   Multicast traffic may loop between R2 and R6.

   If BIFT on R7 converges after R6, during the convergence process,
   the multicast packet sent by R2 to R9 also may loop between R6 and
   R7.

   This document provides a mechanism leveraging SR-MPLS and/or SRv6 to
   ensure that BIER messages can be forwarded loop-freeness during the
   IGP reconvergence process following a link-state change event.

liu, et al.              Expires April, 2024                   [Page 3]
Internet-Draft           BIER loop Avoidance              October 2023

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. Loop-free convergence process

   Upon a topology change, when a BFR converging for BFERs does not
   trust the loop-freeness of its post-convergence paths for BFERs, it
   performs convergence processing as follows.

   After computing the new path to BFER, for a predetermined amount of
   time C, BFR installs a BIFT for BFR-NBR that steers packets to BFER
   via a loop-free forwarding path. For example, forwarding through
   explicit SR unicast path or through explicit P2MP path. C should be
   greater than or equal to the worst-case convergence time of a node,
   network-wide. The determination of "C" is outside the scope of this
   document. The forwarding path is computed when the event occurs.

   After C elapses, BFR installs the normal post-convergence forwarding
   entry for BFER that ensure the loop-free property.

   Taking Figure 1 as an example, when the link between R2 and R3
   fails, R6 received multicast service from its downstream BFR
   neighbor R2. Within the interval C, R6 specifies the interface
   connecting R6 and R7 as the outbound interface, and forwards
   multicast packets sent to R9 according to a strictly explicit path
   to the next BFR neighbor R7.

   After R7 receives the multicast message from the explicit path, it
   performs similar processing as R6. If it is within the interval C,
   continue to specify the interface connecting R7 and R8 as the
   outbound interface, and forward multicast packets to BFR neighbor R8
   according to the strict explicit path. By analogy, before the
   routing convergence is completed, the traffic on the backup path is
   forwarded along the path R6->R7->R8->R9.

  3. Computing Loop-avoiding Path

   When the link between R2 and R3 fails, R6 receives multicast message
   from its downstream BFR neighbor R2 and temporarily redirects the
   traffic targeting R9 to an explicit path, forwarding it based on the
   specified node label or SRv6 SID in the explicit path.

liu, et al.              Expires April, 2024                   [Page 4]
Internet-Draft           BIER loop Avoidance              October 2023

   When the link between R2 and R3 fails to recover, the process of
   avoiding loops is also similar.

3.1. Explicit Path of Loop-avoiding

   The explicit path of loop-avoiding can be (but not limited to):

   * SR policy TE path. Treat each node or adjacent SID on the explicit
      path as a segment on the SR Policy TE path. During the convergence
      process, add SRv6 encapsulation to the BIER message, specify the
      SRH Segment List, and send it to the next BFR in the backup path.
      After reaching the next BFR, decapsulate the outer layer SR-
      MPLS/SRv6 packet header, restore the original BIER packet, and
      continue forwarding according to the BIER header.

   * BIER-TE forwarding path. During the convergence process, each node
      on the explicit path is treated as a BIER-TE node and forwarded
      through BIER-TE. The bit position of nodes on the BIER-TE path can
      be arranged into the bitstring of the original BIER header, or the
      BIER-TE header can be encapsulated outside the BIER message.

   * P2MP policy forwarding path. During the convergence process,
      multicast messages are forwarded through the path specified by the
      P2MP policy.

3.2. Calculation Method of Explicit Path

   There are currently two methods to calculate the nodes included in
   the explicit path.

   Method 1: Similar to [RFC7490], we use the concept of P-Space and Q-
   Space for TI-LFA. Generate explicit SR/SRv6-based path from P to Q.
   The repair list is expressed generally as {P node (NODE SID), all
   ADJ/End. X SIDs from P node to Q node}.

      a) Using the BFER destination node, calculate the optimal
         convergence path tree. That is, when the link fails, the source
         node reconverges to the calculated SPF tree.

      b) Find the Q node. On the convergence path tree, traverse the
         parent nodes starting from the BFER destination node until
         finding the farthest node from the destination node, which is
         not affected by the link failure and can reach the destination
         node, as the Q node.

      c) Find the P node. On the convergence path tree, traverse the
         parent nodes starting from the Q node until finding a node that

liu, et al.              Expires April, 2024                   [Page 5]
Internet-Draft           BIER loop Avoidance              October 2023

         is not affected by the link failure on the path from the source
         node to that node. This node will be considered as the P node.

      d) Calculate the repair segment list path. Calculate the repair
         segment list path. The repair segment list path is found by
         computing the explicit SR/SRv6-based path from P to Q when
         these nodes are not adjacent along the convergence path. For
         SR-MPLS, the repair list is expressed {Node_SID(P),
         AdjSID(P->Q)}; For SRv6, the repair list is expressed
         {END_SID(P), END. X(P->Q)}.

      e) Calculate the output interface. The next hop output interface
         that converges again after a link failure.

   Method 2: Directly from source node S to destination node Q,
   generating a strict explicit path. For SR-MPLS, the repair list is
   expressed {AdjSID(S->Q)}; For SRv6, the repair list is expressed
   {END. X(S->Q)}.

   If the Q nodes and Q nodes of different receivers are the same,
   which means that multicast packets can be forwarded through the same
   path, it is necessary to merge the multicast forwarding paths to
   avoid headend replication. Try to place the multicast replication
   point on the node closest to the multicast receivers.

  4. Example Application

       SRC --- R1 ----- R2 ------ R3----- R4----- R10----Receiver1
                 |        |                 | \
                 |        |                 |   \
                 |        |                 |     \
                 R5 ----- R6 ------ R7------R8----- R9----Receiver2
                                       100
                             Figure 2
   As an example, in Figure 2, R1 is connected to the multicast source,
   and all IGP links are symmetric metric. Except for the link cost
   between R7 and R8, the cost of all other links is 1. The multicast
   data packet sent from R1 to R9 and R10 is initially forwarded along
   the path R1->R2->R3->R4->R9/R10. When the link between R2 and R3
   fails, or node R3 fails, there may be a loop in traffic between R2
   and R7.

   Therefore, we will compute the repair path and repair list for the
   from R1 to R9 and R10 in the event of the link between R2 and R3
   fails, or node R3 fails.

liu, et al.              Expires April, 2024                   [Page 6]
Internet-Draft           BIER loop Avoidance              October 2023

   1) The expected convergence path from R1 to R9 and R10 considering
      the failure of link between R2 and R3 or of node R3 is
      <R1->R2/R5->R6->R7->R8->R9> and <R1->R2/R5->R6->R7->R8->R4->R10>.

   2) Q is computed and results in [R8].

   3) P is computed and results in [R7].

   4) To the two leaf nodes R9 and R10, both need to go through the
      R7->R8 link. For SR-MPLS, the repair list of R1 for destination R9
      and R10 considering the failure of link between R2 and R3 or of
      node R3 is: <NodeSID(R7), AdjSID_R7R8>. For SRv6, the repair list
      of R1 for destination R9 and R10 considering the failure of link
      between R2 and R3 or of node R3 is: <End.X_R7R8>.

   When the link between R2 and R3 fails, or R3 fails, multicast traffic
   is first sent to R8 along the R1->R2/R5->R6->R7->R8 path, and then
   two copies are replicated at R8. One copy is forwarded to R9, and the
   other copy is forwarded to R10.

  5. IANA Considerations

   No requirements for IANA.

  6. Security Considerations

   The behavior described in this document is internal functionality to
   a router that result in the ability to explicitly steer traffic over
   the post convergence path after a remote topology change in a manner
   that guarantees loop freeness. Because the behavior serves to
   minimize the disruption associated with a topology change, it can be
   seen as a modest security enhancement.

7. References

7.1. Normative References

   [I-D.ietf-6man-ipv6-alt-mark] Fioccola, G., Zhou, T., Cociglio, M.,
             Qin, F., and R. Pang, "IPv6 Application of the Alternate
             Marking Method", draft-ietf-6man-ipv6-alt-mark-16 (work in
             progress), July 2022.

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

liu, et al.              Expires April, 2024                   [Page 7]
Internet-Draft           BIER loop Avoidance              October 2023

   [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., So, N.,
             "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", BCP
             14, RFC 8174, DOI 10.17487/RFC7490, April 2015,
             <https://www.rfc-editor.org/info/rfc7490>.

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

7.2. Informative References

   TBD

  8. Acknowledgments

   The authors would like to thank the following for their valuable
   contributions of this document:

   TBD

liu, et al.              Expires April, 2024                   [Page 8]
Internet-Draft           BIER loop Avoidance              October 2023

Authors' Addresses

   Yisong Liu
   China Mobile

   Email: liuyisong@chinamobile.com

   Changwang Lin
   New H3C Technologies
   China

   Email: linchangwang.04414@h3c.com

   Yuanxiang Qiu
   New H3C Technologies
   China
   
   Email: qiuyuanxiang@h3c.com

liu, et al.              Expires April, 2024                   [Page 9]