BIER WG Quan Xiong
Internet-Draft Fangwei Hu
Intended status: Standards Track Greg Mirsky
Expires: April 15, 2019 ZTE Corporation
October 12, 2018
The Resilience for BIER
draft-xiong-bier-resilience-01.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 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 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 April 15, 2019.
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 April 15, 2019 [Page 1]
Internet-Draft The Resilience for BIER October 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 . . . . . . . . . . . . . . . . . . 3
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. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informational References . . . . . . . . . . . . . . . . 7
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 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 mechanisms and
detection methods.
Quan Xiong, et al. Expires April 15, 2019 [Page 2]
Internet-Draft The Resilience for BIER October 2018
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. 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 by any transport layer
over which the 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 a 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 a BIER-specific network
should be considered in some scenarios like shown in Figure 1. 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 protection path for the working path. In this example the
working path could be BFIR->BFR1->BFR2->BFR3->BFER1 and
BFIR->BFR1->BFR2->BFR3->BFER2; and then the protection path is
BFIR->BFR6->BFR5->BFR4->BFER1 and BFIR->BFR6->BFR5->BFR4->BFER2.
Quan Xiong, et al. Expires April 15, 2019 [Page 3]
Internet-Draft The Resilience for BIER October 2018
+----+ +----+ +----+ +-----+
|BFR1|----|BFR2|-----|BFR3|--------|BFER1|
+----+ +----+ +----+ +-----+
/ \ /
/ \ /
+----+ \ /
|BFIR| \/
+----+ /\
\ / \
\ / \
+----+ +----+ +----+ +-----+
|BFR6|----|BFR5|------|BFR4|------|BFER2|
+----+ +----+ +----+ +-----+
Figure 1: BIER End-to-End Protection
For 1+1 protection scenario, the multicast traffic MUST be sent
across the network through both the working and backup paths. When
the link or node failure occurs inf the working path, the BFERs need
to switch to receiving the data flow from the protection path.
The failure detection mechanism for end-to-end 1+1 protection
scenario MUST be able to monitor and detect multicast failures in
working and protection paths. 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.
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 onto the working path and switch to the backup path when a
failure occurs.
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]. The
P2MP active tail detection method extends the mechanism defined in
Quan Xiong, et al. Expires April 15, 2019 [Page 4]
Internet-Draft The Resilience for BIER October 2018
[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.
If P2MP BFD uses the active tail mode, then when one of the BFERs
detects the failure of the working path, it will send a message to
the BFIR. The BFIR will notify BFERs of switchover and start
forwarding the multicast flows over the protection path.
3.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
Quan Xiong, et al. Expires April 15, 2019 [Page 5]
Internet-Draft The Resilience for BIER October 2018
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
Interior Gateway Protocol (IGP) network MAY be applied in BIER
network.
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
TBD
7. References
7.1. Normative References
[I-D.hu-bier-bfd]
hu, f., Mirsky, G., Xiong, Q., and C. Liu, "BIER BFD",
draft-hu-bier-bfd-02 (work in progress), October 2018.
[I-D.ietf-bfd-multipoint]
Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for
Multipoint Networks", draft-ietf-bfd-multipoint-18 (work
in progress), June 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-09 (work in progress), June 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>.
Quan Xiong, et al. Expires April 15, 2019 [Page 6]
Internet-Draft The Resilience for BIER October 2018
[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
Fangwei Hu
ZTE Corporation
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Quan Xiong, et al. Expires April 15, 2019 [Page 7]
Internet-Draft The Resilience for BIER October 2018
Greg Mirsky
ZTE Corporation
USA
Email: gregimirsky@gmail.com
Quan Xiong, et al. Expires April 15, 2019 [Page 8]