[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

BIER WG                                                       Quan Xiong
Internet-Draft                                               Greg Mirsky
Intended status: Informational                           ZTE Corporation
Expires: September 7, 2019                                    Fangwei Hu
                                                              Individual
                                                           March 6, 2019


                        The Resilience for BIER
                   draft-xiong-bier-resilience-02.txt

Abstract

   Bit Index Explicit Replication (BIER) is an architecture for the
   forwarding of multicast data packets.  In some scenarios, the
   resilience should be provided to guarantee the multicast data is
   protected by a given backup resource and forwarded successfully to
   the receivers in BIER-specific network.

   This document discusses the resilience use cases, requirements and
   proposes solutions for BIER, including the protection and restoration
   mechanisms and detection methods.

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 September 7, 2019.

Copyright Notice

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



Quan Xiong, et al.      Expires September 7, 2019               [Page 1]


Internet-Draft           The Resilience for BIER              March 2019


   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
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  BIER Resilience Use Cases . . . . . . . . . . . . . . . . . .   3
     2.1.  BIER End-to-End 1+1 Protection  . . . . . . . . . . . . .   3
     2.2.  BIER End-to-End Restoration . . . . . . . . . . . . . . .   4
     2.3.  BIER Link Protection  . . . . . . . . . . . . . . . . . .   5
   3.  Management and Control Considerations . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informational References  . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [RFC8279] defined Bit Index Explicit Replication (BIER) architecture
   as a solution for the forwarding of multicast data packets.  The
   routers which support BIER are known as Bit-Forwarding Router (BFR)
   and the multicast data packet enters a BIER domain at a Bit-
   Forwarding Ingress Router (BFIR) and leaves at one or more Bit-
   Forwarding Egress Routers (BFERs).

   [I-D.eckert-bier-te-frr] provides some protection mechanisms for
   traffic engineering in a BIER domain.  However, there is no mechanism
   to protect multicast traffic against BIER-specific network failures.
   In some scenarios, the resilience should be provided to guarantee the
   multicast data is protected by a given backup resource and forwarded
   successfully to the receivers in BIER-specific network.

   This document describes the resilience use cases and requirements for
   BIER-specific network and discusses the protection and restoration
   mechanisms and detection methods.







Quan Xiong, et al.      Expires September 7, 2019               [Page 2]


Internet-Draft           The Resilience for BIER              March 2019


1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   The terminology is defined as [RFC8279].

2.  BIER Resilience Use Cases

   The resilience use cases for a BIER-specific network should be
   considered including end-to-end and link protection scenarios.  The
   protection, restoration, and related detection mechanisms MUST be
   provided for BIER resilience against a failure of a link or a node.

2.1.  BIER End-to-End 1+1 Protection

   The end-to-end protection mechanisms for a BIER-specific network
   should be considered in some scenarios like shown in Figure 1.  It
   includes end-to-end 1+1 protection and restoration use cases.  Two
   disjoint end-to-end multicast paths that are available for 1+1
   protection or restoration from BFIR to BFERs should be provided.  One
   path could be BFIR->BFR1->BFR2->BFR3->BFER1 and
   BFIR->BFR1->BFR2->BFR3->BFER2; and the alternative path is
   BFIR->BFR6->BFR5->BFR4->BFER1 and BFIR->BFR6->BFR5->BFR4->BFER2.


                       +----+    +----+     +----+        +-----+
                       |BFR1|----|BFR2|-----|BFR3|--------|BFER1|
                       +----+    +----+     +----+        +-----+
                      /                           \      /
                     /                             \    /
               +----+                               \  /
               |BFIR|                                \/
               +----+                                /\
                     \                              /  \
                      \                            /    \
                       +----+    +----+      +----+      +-----+
                       |BFR6|----|BFR5|------|BFR4|------|BFER2|
                       +----+    +----+      +----+      +-----+


           Figure 1: BIER End-to-End Protection and Restoration

   For a 1+1 protection scenario, it is referred to as live-live, the
   BFIR sends two flows of multicast traffic to all BFERs through the



Quan Xiong, et al.      Expires September 7, 2019               [Page 3]


Internet-Draft           The Resilience for BIER              March 2019


   disjiont multipoint paths.  BFERs need to merge the two flows when no
   failure happens.  The BFERs MUST monitor and detect multicast
   failures and switch from one flow to another when a failure of a flow
   is detected.

   For example, in a Deterministic Networking (DetNet) service, Packet
   Replication Function (PRF) is used in combination with Packet
   Elimination Function (PEF) and usually referred to as PREF.  PREF is
   used in DetNet to lower the packet loss metric and it can be viewed
   as an example of live-live terminated within BIER domain.  PRF
   replicates packets into multiple DetNet member flows and sends them
   along multiple different paths to the destinations and PEF eliminates
   the duplication based on the failure detection.

   The failure detection mechanism for the end-to-end 1+1 protection
   scenario MUST be able to monitor and detect multicast failures in
   each working path.  P2MP BFD [I-D.ietf-bfd-multipoint] MAY be used to
   verify multipoint connectivity between a BFIR and a set of BFERs.
   [I-D.hu-bier-bfd] describes the use of p2mp BFD in a BIER domain.

   End-to-end 1+1 protection provides fast switch but low resource
   utilization.  All BFERs MAY receive two copies from two paths in the
   no-failure scenario and the receivers MUST be able to choose one of
   them and eliminate the duplication.

2.2.  BIER End-to-End Restoration

   This section discusses the end-to-end restoration for BIER.  If
   duplicate transmission is not desirable for some networks, the
   restoration mechanism may be taken into consideration where only one
   copy is sent to each receiver.  The BFIR will send multicast flows
   onto the original path.  If the BFIR detects a failure in the
   multicast path, the BFIR MAY create and new multicast tree and switch
   the multicast flow accordingly.

   The failure detection mechanism for end-to-end restoration use case
   MUST be enable receivers (tails) to monitor and detect multicast
   failures in the multicast tree and notify the head node.  BIER-
   specific extensions MAY be proposed based on
   [I-D.ietf-bfd-multipoint-active-tail].  The P2MP active tail
   detection method extends the mechanism defined in
   [I-D.ietf-bfd-multipoint].  It allows tails to notify the head of the
   failure of the multicast path and can be used in multipoint and
   multicast networks, e.g., in BIER domain as described in
   [I-D.hu-bier-bfd].

   If P2MP BFD uses the active tail mode, then when one of the BFERs
   detects the failure, it will send a message to the BFIR.  The BFIR



Quan Xiong, et al.      Expires September 7, 2019               [Page 4]


Internet-Draft           The Resilience for BIER              March 2019


   will create a new multicast path to restore the service and notify
   BFERs of switchover and start forwarding the multicast flows over the
   restoration path.

2.3.  BIER Link Protection

   Local protection, i.e., link or node protection, MAY be considered
   for BIER domain as an alternative to end-to-end protection.  The
   nodes which are the BFRs in BIER network and they exchange the
   information needed for them to forward packets to each other using
   BIER.  The node protection MAY be provided by using mechanisms
   already existing in the underlay network, for example, described in
   [I-D.eckert-bier-te-frr].

   A BFR MAY send BIER packets to directly connected BIER neighbors
   through a BIER link without requiring a routing underlay.  Link
   protection SHOULD be considered in BIER domain.  The detection of
   link failure MAY use the Point-to-Point BFD detection defined in
   [RFC5880].  A set of extension for BIER-specific P2P BFD SHOULD be
   proposed in further discussion.

   As shown in Figure 2, the BIER path from BFIR to BFERs is
   BFIR->BFR4->BFR3 ->BFR2->BFER1 and BFIR->BFR4->BFR3->BFER2.  If the
   BIER link from BFR4 to BFR3 fails, the failure can be protected by
   the backup paths over BFR4->BFR1->BFR2 ->BFR3.


                              +-----+        +-----+       +--+--+
                              |BFR1 +--------+BFR2 +-------+BFER1|
                              +--+--+        +--+--+       +--+--+
                                 |              |
                                 |              |
               +--+--+        +--+--+        +--+--+       +--+--+
               |BFIR +--------+BFR4 +--------+BFR3 +-------+BFER2|
               +--+--+        +-----+        +-----+       +-----+


                      Figure 2: BIER Link Protection

   As discussed in [I-D.eckert-bier-te-frr], the BIER link protection
   MAY use the existing RSVP-TE/P2MP or SR tunnel bypass.  When a node
   detects a failure on a link, it MAY be assumed that the link has
   failed and the traffic is switched onto the pre-established backup
   path to get packets to the downstream node.

   Also, as discussed in [RFC7490], the Topology Independent Loop-free
   Alternate Fast Re-route (TI-LFA) Fast Reroute (FRR) approach that
   achieves guaranteed coverage against link or node failure in the



Quan Xiong, et al.      Expires September 7, 2019               [Page 5]


Internet-Draft           The Resilience for BIER              March 2019


   Interior Gateway Protocol (IGP) network MAY be applied in BIER
   network.

3.  Management and Control Considerations

   BIER protection or restoration configuration, including BIER end-to-
   end protection, restoration, link/node protection and related
   information, MAY be defined and controlled from a centralized
   controller or a network management system.  A failure detection and
   notification mechanism MUST be supported.  The fast protection
   switching MUST be supported to minimize the loss of BIER packets due
   to BIER network failure.

4.  Security Considerations

   Security aspects of protection in BIER domain may be considered in
   relation to the data plane, and handling the dedicated OAM packets
   used to detect, signal a failure, coordinate the state in the BIER
   protection domain.

5.  IANA Considerations

   TBD

6.  Acknowledgements

   Authors would like to thank the comments and suggestions from Jeffrey
   (Zhaohui) Zhang.

7.  References

7.1.  Normative References

   [I-D.hu-bier-bfd]
              Xiong, Q., Mirsky, G., hu, f., and C. Liu, "BIER BFD",
              draft-hu-bier-bfd-03 (work in progress), February 2019.

   [I-D.ietf-bfd-multipoint]
              Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for
              Multipoint Networks", draft-ietf-bfd-multipoint-19 (work
              in progress), December 2018.

   [I-D.ietf-bfd-multipoint-active-tail]
              Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD
              Multipoint Active Tails.", draft-ietf-bfd-multipoint-
              active-tail-10 (work in progress), November 2018.





Quan Xiong, et al.      Expires September 7, 2019               [Page 6]


Internet-Draft           The Resilience for BIER              March 2019


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

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

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

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

7.2.  Informational References

   [I-D.eckert-bier-te-frr]
              Eckert, T., Cauchie, G., Braun, W., and M. Menth,
              "Protection Methods for BIER-TE", draft-eckert-bier-te-
              frr-03 (work in progress), March 2018.

Authors' Addresses

   Quan Xiong
   ZTE Corporation
   No.6 Huashi Park Rd
   Wuhan, Hubei  430223
   China

   Phone: +86 27 83531060
   Email: xiong.quan@zte.com.cn


   Greg Mirsky
   ZTE Corporation
   USA

   Email: gregimirsky@gmail.com







Quan Xiong, et al.      Expires September 7, 2019               [Page 7]


Internet-Draft           The Resilience for BIER              March 2019


   Fangwei Hu
   Individual
   China

   Email: hufwei@gmail.com














































Quan Xiong, et al.      Expires September 7, 2019               [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/