BIER WG                                                       Quan Xiong
Internet-Draft                                                Fangwei Hu
Intended status: Standards Track                             Greg Mirsky
Expires: September 5, 2018                               ZTE Corporation
                                                           March 4, 2018


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

Abstract

   Bit Index Explicit Replication (BIER) is an architecture that
   specifies a solution for the forwarding of multicast data packets.
   In some scenarios, the resilience should be provided to guarantee the
   multicast data be 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 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 5, 2018.

Copyright Notice

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



Quan Xiong, et al.      Expires September 5, 2018               [Page 1]


Internet-Draft           The Resilience for BIER              March 2018


   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 . . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  BIER Resilience Use Cases . . . . . . . . . . . . . . . . . .   3
     3.1.  End-to-End 1+1 Protection . . . . . . . . . . . . . . . .   3
     3.2.  End-to-End 1:1 Protection . . . . . . . . . . . . . . . .   4
     3.3.  BIER Link Protection  . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [RFC8279] introduces Bit Index Explicit Replication (BIER)
   architecture and specifies 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 leave at one or
   more Bit-Forwarding Egress Routers (BFERs).

   [I-D.eckert-bier-te-frr] provides some protection mechanisms for
   traffic engineering of BIER.  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 be 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 mechanisms and
   detection methods.

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




Quan Xiong, et al.      Expires September 5, 2018               [Page 2]


Internet-Draft           The Resilience for BIER              March 2018


1.2.  Terminology

   The terminology is defined as [RFC8279].

2.  Requirements

   The following lists the resilience requirements for BIER-specific
   multicast domain including the protection mechanisms and detection
   methods.

   (1)  The listed requirements MUST be supported with any type of
        transport layer over which BIER layer can be realized.

   (2)  BIER protection type MAY be defined and configured from a
        centralized controller or management network including BIER end-
        to-end protection and link/node protection and related
        information.

   (3)  It is required to support the failure detection and notification
        mechanisms.

   (4)  It is required to support the fast protection switching for the
        BIER packets within the limited time.

3.  BIER Resilience Use Cases

   The resilience use cases for BIER-specific network should be
   considered including end-to-end and link protection scenarios.  The
   protection and related detection mechanisms MAY be provided for BIER
   resilience against failures such as link or nodes.

3.1.  End-to-End 1+1 Protection

   The end-to-end protection mechanisms for BIER-specific network should
   be considered in some scenarios like the Figure 1 shown.  It includes
   end-to-end 1+1 and 1:1 protection use cases.  Two disjoint end-to-end
   paths that are available for 1+1 or 1:1 protection from BFIR to BFERs
   should be provided and one of them may be configured to be the backup
   path for the working path.  The working path is
   BFIR->BFR1->BFR2->BFR3->BFER1 and BFIR->BFR1->BFR2->BFR3->BFR4->BFER2
   and the backup path is BFIR->BFR7->BFR6->BFR5->BFR4->BFER1 and
   BFIR->BFR7->BFR6->BFR5->BFER2.









Quan Xiong, et al.      Expires September 5, 2018               [Page 3]


Internet-Draft           The Resilience for BIER              March 2018


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

                           Figure 1 BIER End-to-End protection

   For 1+1 protection scenario, the multicast traffic MUST be sent
   across the network through the working and backup paths
   respectively.When the link or node failure occurs in one of the path,
   the BFERs need to receive the flows transiting from the other path.

   The failure detection mechanism for end-to-end 1+1 protection
   scenario MUST be able to monitor and detect multicast failures such
   as the Point to Multipoint (P2MP) Bidirectional Detection (BFD) which
   is described in [I-D.hu-bier-bfd].  P2MP BFD MAY be used to verify
   multipoint connectivity between a BFIR and a set of BFERs.

   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.

3.2.  End-to-End 1:1 Protection

   This section discusses the end-to-end 1:1 protection for BIER.  If
   duplicate transmission is not desirable for some networks, end-to-end
   1:1 protection mechanism may be taken into consideration where only
   one copy is sent to each receiver.  The BFIR will send multicast
   flows from the working path and switch to the backup path when
   failures occur.

   The failure detection mechanism for end-to-end 1:1 protection
   scenario MUST be able to monitor and detect multicast failures in the
   receivers (tails) and notify the head node.  BIER-specific extensions
   MAY be proposed based on [I-D.ietf-bfd-multipoint-active-tail] which
   defined the P2MP active tail detection method.  It allows tails to
   reliably notify the head of the failures of multipoint connectivity
   and can be used in multipoint and multicast networks.



Quan Xiong, et al.      Expires September 5, 2018               [Page 4]


Internet-Draft           The Resilience for BIER              March 2018


   When one of the BFERs detects the failure of the working path, it
   will send message to the BFIR which wishes notification of path
   failure from the tail.  The BFIR could make a fast switch and start
   forwarding the multicast flows over the backup path.

3.3.  BIER Link Protection

   Link and node protection MAY be discussed for BIER domain as
   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 underlay existing mechanisms which 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 the Figure 2 shown, 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 uses 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.

   In addition, 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




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


Internet-Draft           The Resilience for BIER              March 2018


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

4.  Security Considerations

   TBD.

5.  IANA Considerations

   TBD.

6.  Acknowledgements

   TBD.

7.  Normative 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-02 (work in progress), June 2017.

   [I-D.hu-bier-bfd]
              hu, f., Mirsky, G., and C. Liu, "BIER BFD", draft-hu-bier-
              bfd-00 (work in progress), October 2017.

   [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-07 (work in progress), February 2018.

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







Quan Xiong, et al.      Expires September 5, 2018               [Page 6]


Internet-Draft           The Resilience for BIER              March 2018


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

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


   Fangwei Hu
   ZTE Corporation
   No.889 Bibo Rd
   Shanghai  201203
   China

   Phone: +86 21 68896273
   Email: hu.fangwei@zte.com.cn


   Greg Mirsky
   ZTE Corporation
   USA

   Email: gregimirsky@gmail.com


















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