Internet-Draft | BIER-TE Egress Protect | August 2021 |
Chen, et al. | Expires 26 February 2022 | [Page] |
This document describes a mechanism for fast protection against the failure of an egress node of an explicit point to multipoint (P2MP) multicast path/tree in a "Bit Index Explicit Replication" (BIER) Traffic Engineering (TE) domain. It does not have any per-flow state in the core of the domain. For a multicast packet to the egress node, when the egress node fails, its upstream hop as a PLR sends the packet to the egress' backup node once the PLR detects the failure.¶
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] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 26 February 2022.¶
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.¶
[I-D.ietf-bier-te-arch] introduces Bit Index Explicit Replication (BIER) Traffic/Tree Engineering (BIER-TE). It is an architecture for per-packet stateless explicit point to multipoint (P2MP) multicast path/tree and based on the BIER architecture defined in [RFC8279]. A multicast packet is replicated and forwarded along the P2MP path/tree encoded in the packet. It does not require intermediate nodes to maintain any per-path/tree state.¶
This document describes a mechanism for fast protection against the failure of an egress node of an explicit P2MP multicast path/tree in a BIER-TE domain. It is called BIER-TE Egress Protection. For a multicast packet to the egress node, when the egress node fails, its upstream hop as a PLR sends the packet to the egress' backup node (called backup egress node) once the PLR detects the failure.¶
This BIER-TE Egress Protection does not require intermediate nodes to maintain any per-path state for fast protection against the failure of an egress node of the path.¶
For fast protecting an egress node of a BIER-TE domain, a backup egress node is configured on the egress node. After the configuration, the egress node distributes the information about the backup egress to its direct neighbors.¶
For clearly distinguishing between an egress node and a backup egress node, an egress node is called a primary egress node sometimes.¶
For a multicast packet to a primary egress node of the domain, when the primary egress node fails, its upstream hop as a point of local repair (PLR) sends the packet to the backup egress node configured to protect the primary egress node once the PLR detects the failure. The upstream hop of the primary egress node is its direct neighbor.¶
A Bit-Forwarding Router (BFR) in a BIER-TE sub-domain has a BIER-TE Bit Index Forwarding Tables (BIFT) [I-D.ietf-bier-te-arch]. A BIER-TE BIFT on a BFR comprises a forwarding entry for a BitPosition (BP) assigned to each of the adjacencies of the BFR. If the BP represents a forward connected adjacency, the forwarding entry for the BP forwards the multicast packet with the BP to the directly connected BFR neighbor of the adjacency. If the BP represents a BFER (i.e., egress node) or say a local decap adjacency, the forwarding entry for the BP decapsulates the multicast packet with the BP and passes a copy of the payload of the packet to the packet's NextProto within the BFR.¶
The BIER-TE BIFT on a BFR is extended to support protection against the failure of an egress node. For each forwarding entry of the BIER-TE BIFT on the BFR, if it is for the BP representing a forward connected adjacency and its BFR-NBR is a BFER (i.e., primary egress node), the forwarding entry is extended to include a new forwarding entry, which is called backup forwarding entry or backup entry for short. This backup entry forwards the multicast packet with the BP to the backup egress node, which is configured to protect the primary egress node.¶
Once the BFR as a PLR detects the failure of its BFR-NBR X that is a primary egress node of the domain, for a multicast packet with the BP for the primary egress node, the PLR uses the backup forwarding entry in the extended BIER-TE BIFT to send the packet to the backup egress node configured to protect the primary egress node.¶
This section defines extensions to OSPF and IS-IS for advertising the backup information (including the information about the backup egress node for protecting a primary egress node).¶
When a node P (as a primary egress node) has a backup egress node configured to protect against its failure, node P advertises the information about the backup egress node to its neighbors in its router information opaque LSA of LS type 9 or 10. The information is included in a backup egress BP TLV. The format of the TLV is shown in Figure 1.¶
Type: 2 octets, its value (TBD1) is to be assigned by IANA.¶
Length: 2 octets, its value is 4 plus the length of the Sub-TLVs included. If no Sub-TLV is included, its value is 4.¶
Reserved: 2 octets, it MUST be set to zero when sending and be ignored while receiving.¶
BP of backup egress node: 2 octets, its value is the local decap BitPosition of the backup egress node, which is configured to protect against the failure of the primary egress node.¶
Sub-TLVs (Optional): No Sub-TLV is defined now.¶
After each of the neighbors receives the backup egress BP TLV from node P, it knows that node P as a primary egress node will be protected by the backup egress node in the TLV. Once detecting the failure of node P, it sends the packet with the BP for node P towards the backup egress node.¶
For supporting fast protection against the failure of a primary egress node in a BIER-TE domain, a new IS-IS TLV, called IS-IS backup egress BP TLV, is defined. It contains the local decap BitPosition of the backup egress node configured to protect the primary egress node.¶
When a node P (as a primary egress node) has a backup egress node configured to protect against its failure, node P advertises the information about the backup egress node to its neighbors using a IS-IS backup egress BP TLV.¶
This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. The format of the TLV is shown in Figure 2.¶
Type: 1 octet, its value (TBD2) is to be assigned by IANA.¶
Length: 1 octet, its value is 2 plus the length of the Sub-TLVs included. If no Sub-TLV is included, its value is 2.¶
BP of backup egress node: 2 octets, its value is the local decap BitPosition of the backup egress node configured to protect against the failure of the primary egress node.¶
Sub-TLVs (Optional): No Sub-TLV is defined now.¶
This section describes extensions to a BIER-TE BIFT of a BFR for supporting fast protection against the failure of a primary egress node and enhancements on a forwarding procedure to use the extended BIER-TE BIFT for egress protection.¶
If a BFR is a neighbor of an egress node in a BIER-TE sub-domain, it has an extended BIER-TE BIFT to support protection against the failure of its neighbor egress node. The forwarding entry with the egress node (say X) as its BFR-NBR in the BIFT comprises a backup entry. The backup entry contains a flag EPA (which is short for Egress Protection is Active) and a backup path to a backup egress node (say Y) which is configured to protect the egress node.¶
In normal operations, the flag EPA in the backup entry for neighbor egress node X is set to 0 (zero). The flag EPA is set to 1 (one) when egress node X fails. EPA == 1 means that the egress protection for primary egress node X is active and the backup entry will be used to forward the packet with BP for egress node X to backup egress node Y along the backup path.¶
The backup path from the BFR to backup egress node Y is a path that satisfies a set of constraints and does not traverse primary egress node X or any link connected to X. In one implementation, the backup path is represented by the BitPositions for the adjacencies along the backup path.¶
The forwarding procedure defined in [I-D.ietf-bier-te-arch] is updated/enhanced for using an extended BIER-TE BIFT to consider the egress protection (i.e., the new backup entry containing EPA and backup path in the BIFT).¶
For a multicast packet with the BP in the BitString indicating a BFR-NBR as a primary egress node, the updated forwarding procedure on a BFR sends the packet towards the backup egress node of the primary egress node if the primary egress node fails.¶
It checks whether EPA equals to 1 (one) in the forwarding entry with the BFR-NBR that is the primary egress node. If EPA is 1 (i.e., the primary egress node fails and the egress protection for primary egress is active), then the procedure clears two BPs in the packet's BitString and checks whether the backup egress node is not one of the packet's destinations.¶
One BP is the BP for the primary egress node and the other is the BP for the forward connected adjacency from the BFR to the primary egress node. After these two BPs are cleared in the packet's BitString, the packet will not be sent to the failed primary egress node.¶
When the BP for the backup egress node in the packet's BitString is 0, the backup egress node is not one of the packet's destinations. In this case, the procedure adds the backup path to the backup egress node into the packet through adding the BPs for the backup path in the packet's BitString. Thus the packet will be sent to the backup egress node along the backup path.¶
The updated procedure is described in Figure 3. It can also be used by the BFR to forward multicast packets in normal operations.¶
This section illustrates an example application of BIER-TE Egress Protection on a BFR in a BIER-TE topology in Figure 4.¶
An example BIER topology for a BIER-TE sub-domain is shown in Figure 4. It has 8 nodes/BFRs A, B, C, D, E, F, G and H.¶
Nodes/BFRs D, F, E, H and A are BFERs and have local decap adjacency BitPositions 1, 2, 3, 4, and 5 respectively. For simplicity, these BPs are represented by (SI:BitString), where SI = 0 and BitString is of 5 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0:00001), 2 (0:00010), 3 (0:00100), 4 (0:01000) and 5 (0:10000) respectively.¶
The BitPositions for the forward connected adjacencies are represented by i', where i is from 1 to 20. In one option, they are encoded as (n+i), where n is a power of 2 such as 32768. For simplicity, these BitPositions are represented by (SI:BitString), where SI = (6 + (i-1)/5) and BitString is of 5 bits. BitPositions i' (i from 1 to 20) are represented by 1'(6:00001), 2'(6:00010), 3'(6:00100), 4'(6:01000), 5'(6:10000), 6'(7:00001), 7'(7:00010), 8'(7:00100), . . . , 20'(9:10000).¶
For a link between two nodes X and Y, there are two BitPositions for two forward connected adjacencies. These two forward connected adjacency BitPositions are assigned on nodes X and Y respectively. The BitPosition assigned on X is the forward connected adjacency of Y. The BitPosition assigned on Y is the forward connected adjacency of X.¶
For example, for the link between nodes B and C in the figure, two forward connected adjacency BitPositions 3' and 4' are assigned to two ends of the link. BitPosition 3' is assigned on node B to B's end of the link. It is the forward connected adjacency of node C. BitPosition 4' is assigned on node C to C's end of the link. It is the forward connected adjacency of node B.¶
BFER H is configured to protect BFER D on BFR D. Suppose that this information is distributed to BFR D's neighbors BFR C and BFR G by IGP. BFR C and BFR G know that H is the backup egress to protect the primary egress D.¶
Similarly, BFER D is configured to protect BFER H on BFR H; BFER F is configured to protect BFER E on BFR E; and BFER E is configured to protect BFER F on BFR F. These are not shown in the figure.¶
CE is a multicast traffic Receiver, which is dual homed to primary egress node D and backup egress node H for protecting primary egress D. During normal operations, there is no multicast traffic to CE from backup egress node H and CE receives the multicast traffic only from primary egress node D. There is no duplicated traffic to receiver CE. This is different from MoFRR in [RFC7431], where duplicated traffic is sent to both the primary egress D and backup egress H, to which the receiver CE is dual homed. When primary egress node D fails, the multicast traffic is sent to CE from backup egress node H.¶
Every BFR in a BIER-TE sub-domain/topology has a BIER-TE BIFT. For the BIER-TE topology in Figure 4, each of 8 nodes/BFRs A, B, C, D, E, F, G and H has its BIER-TE BIFT for the topology.¶
The BIER-TE BIFT on BFR C (i.e. node C) is shown in Figure 5.¶
The 1st forwarding entry in the BIFT will forward a multicast packet with BitPosition 18' to D.¶
The 2nd forwarding entry in the BIFT will forward a multicast packet with BitPosition 12' to F.¶
The 3rd forwarding entry in the BIFT will forward a multicast packet with BitPosition 10' to H.¶
The 4-th forwarding entry in the BIFT will forward a multicast packet with BitPosition 3' to B.¶
The BIER-TE BIFT on BFR D (i.e. node D) is shown in Figure 6.¶
The 1st forwarding entry in the BIFT will forward a multicast packet with BitPosition 17' to C.¶
The 2nd forwarding entry in the BIFT will forward a multicast packet with BitPosition 15' to G.¶
The 3rd forwarding entry in the BIFT will locally decapsulate a multicast packet with BitPosition 1 and pass a copy of the payload of the packet to the packet's NextProto.¶
Each of the BFRs that are neighbors of egress nodes (i.e., BFERs) in a BIER-TE sub-domain/topology has an extended BIER-TE BIFT to support protection against the failure of every its neighbor egress node.¶
For example, the extended BIER-TE BIFT on BFR C is illustrated in Figure 7. It comprises a backup entry for each of its neighbor egress nodes D, F and H. Each of these backup entries contains a flag EPA and a backup path to a backup egress node. EPA is set to zero in normal operations. EPA in the backup entry for neighbor egress node X is set to one when egress node X fails.¶
The backup entry of the 1st forwarding entry in the BIFT contains EPA = 0 and backup path {10', 4}. When egress node D fails, the EPA is set to one and the backup entry is used to forward a multicast packet with BitPosition 1 for D to D's backup egress node H with BitPosition 4 along the backup path.¶
The backup entry of the 2nd forwarding entry in the BIFT contains EPA = 0 and backup path {3', 2', 3}. When egress node F fails, EPA is set to one and the backup entry is used to forward a multicast packet with BitPosition 2 for F to F's backup egress node E with BitPosition 3 along the backup path.¶
The backup entry of the 3rd forwarding entry in the BIFT contains EPA = 0 and backup path {18', 1}. When egress node H fails, EPA is set to one and the backup entry is used to forward a multicast packet with BitPosition 4 for H to H's backup egress node D with BitPosition 1 along the backup path.¶
Suppose that there is a multicast packet with explicit path {7', 4', 18', 12', 2, 1} on BFR A. The path is encoded in the BitPositions of the packet. BFR A forwards the packet to BFR B according to the forwarding entry for 7' in its extended BIER-TE BIFT. BFR B forwards the packet to BFR C according to the forwarding entry for 4' in B's extended BIER-TE BIFT.¶
In normal operations, after receiving the packet from BFR B, BFR C copies and sends the packet to BFR D and BFR F using the forwarding entries for 18' and 12' in the extended BIER-TE BIFT on BFR C respectively.¶
Once BFR C detects the failure of egress node D, it sets EPA of the backup entry in the 1st forwarding entry to one. After receiving the packet from BFR B, BFR C copies and sends the packet to D's backup egress node H using the backup entry in the forwarding entry for 18' with BFR-NBR D in C's extended BIER-TE BIFT. It copies and sends the packet to F using the forwarding entry for 12' in C's extended BIER-TE BIFT.¶
The packet received by BFR C from BFR B contains (SI:BitString) = (0:00011)(8:00010)(9:00100), which represents {18', 12', 2, 1}. Since EPA in the backup entry in the forwarding entry with BFR-NBR == D is 1, BFR C copies and sends the packet to D's backup egress node H in the following steps.¶
At first, it obtains the backup entry from the forwarding entry for 18' with BFR-NBR D. EPA == 1 in the backup entry indicates that egress protection for egress node D is active. BFR C clears BitPositions 18' and 1 in Packet's BitString and adds the backup path {10', 4} into Packet's BitString. The updated BitString in Packet is (0:01010)(7:10000)(8:00010), which represents {12', 10', 4, 2}. This lets BFR C copy and send Packet to F and H using the forwarding entries for 12' and 10' in C's extended BIER-TE BIFT respectively.¶
When node H receives the packet with BitPosition 4 for H, it decapsulates the packet and passes a copy of the payload of the packet to the packet's NextProto, which sends the payload to the same CE as egress node D sends.¶
When node F receives the packet with BitPosition 2 for F, it decapsulates the packet and passes a copy of the payload of the packet to the packet's NextProto, which sends the payload to another CE (not shown in the figure).¶
No requirements for IANA.¶
The authors would like to thank people for their comments to this work.¶