BIER Loop Avoidance using Segment Routing
draft-liu-bier-uloop-03
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yisong Liu , Changwang Lin , Zheng Zhang , Yuanxiang Qiu | ||
| Last updated | 2023-11-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-03
BIER Working Group
Internet-Draft Y. Liu
Intended status: Informational China Mobile
Expires: May 9, 2024 C. Lin
New H3C Technologies
Zh. Zhang
ZTE Corporation
Y. Qiu
New H3C Technologies
November 9, 2023
BIER Loop Avoidance using Segment Routing
draft-liu-bier-uloop-03
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 May 9, 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 May, 2024 [Page 1]
Internet-Draft BIER loop Avoidance November 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 ......................... 4
3.2. Calculation Method of Explicit Path .................... 5
4. Example Application ......................................... 6
5. IANA Considerations ......................................... 8
6. Security Considerations ..................................... 8
7. References .................................................. 8
7.1. Normative References ................................... 8
7.2. Informative References ................................. 8
8. Acknowledgments ............................................. 8
Authors' Addresses ............................................. 9
liu, et al. Expires May, 2024 [Page 2]
Internet-Draft BIER loop Avoidance November 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 R7 and R8, 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 May, 2024 [Page 3]
Internet-Draft BIER loop Avoidance November 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 BFIR 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, BFIR installs an explicit path through which packets can be
steered to BFER without loop. For example, forwarding through an
explicit SR/SRv6 path or through a 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 BFIR senses a link failure
between R2 and R3 through unicast routing, it recalculates the
forwarding path of multicast packets for the affected nodes. Within
the interval C, R1 specifies an explicit path to send multicast
packets to R9 along the link between R7-R8. Before the routing
convergence is completed, the multicast traffic is forwarded along
the path R1->R6->R7->R8->R9.
3. Computing Loop-avoiding Path
When the link between R2 and R3 fails, unicast routing converges,
and BFIR calculates a new SPF tree. Before the routing of all nodes
completes convergence, BFIR redirects the traffic targeting R9 to an
explicit path, forwarding it based on the specified node label or
SRv6 SID in the explicit path.
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):
liu, et al. Expires May, 2024 [Page 4]
Internet-Draft BIER loop Avoidance November 2023
* 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.
This document focuses on using the SR-MPLS and SRv6 TE path as the
path for multicast avoidance loop.
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], using 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}.
1) Using the BFER destination node, BFIR calculates the optimal
convergence path tree. That is, when the link fails, unicast
routing converges, and BFIR calculates a new SPF tree.
2) 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.
3) Find the P node. On the convergence path tree, traverse the
parent nodes starting from the Q node until finding a node that
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.
4) Calculate the repair segment list path. The repair segment list
path is found by computing the explicit SR/SRv6-based path from
liu, et al. Expires May, 2024 [Page 5]
Internet-Draft BIER loop Avoidance November 2023
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)}.
5) BFIR first sends the BIER message to the endpoint along the
unicast explicit path indicated by the repair list.
6) After the endpoint receives the message, remove the explicit
path encapsulation, restore the BIER message, and then continue
forwarding according to the BIER header.
Method 2: Directly generate a strict explicit path from source node
S to destination node Q.
* For SR-MPLS, the repair list is expressed {AdjSID(S->Q)}.
* For SRv6, the repair list is expressed {END. X(S->Q)}.
If the P 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.
liu, et al. Expires May, 2024 [Page 6]
Internet-Draft BIER loop Avoidance November 2023
Therefore, we will compute the repair path and repair list for each
BFER from R1 to R9 and R10 in the event of the link between R2 and
R3 fails, or node R3 fails.
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>.
The process is as follows:
1) When the link between R2 and R3 fails, BFIR R1 calculates the
repair path for each BFER.
2) Calculate the Q node for R9, and the result is [R8].
3) Calculate the P node for R9, and the result is [R7].
4) The path between P node and Q node is the repair path of R9.
5) Repeat the above process to calculate the repair path for R10. The
P and Q nodes are also R7 and R8.
6) BFERs with the same P and Q nodes use the same repair path.
Because multiple BFERs have the same repair path, the multicast
message is first forwarded to the endpoint of the repair path, and
then is replicated at the endpoint.
To 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, R1 first sends
the BIER message to R8 along the SR-MPLS/SRv6 path indicated by the
repair list.
After R8 receives the message, remove the outer SR-MPLS/SRv6
encapsulation, restore the BIER message, and then continue forwarding
according to the BIER header.
liu, et al. Expires May, 2024 [Page 7]
Internet-Draft BIER loop Avoidance November 2023
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>.
[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 May, 2024 [Page 8]
Internet-Draft BIER loop Avoidance November 2023
Authors' Addresses
Yisong Liu
China Mobile
Email: liuyisong@chinamobile.com
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Zheng Zhang
ZTE Corporation
Email: zhang.zheng@zte.com.cn
Yuanxiang Qiu
New H3C Technologies
Email: qiuyuanxiang@h3c.com
liu, et al. Expires May, 2024 [Page 9]