Last Call Review of draft-ietf-bier-frr-07
review-ietf-bier-frr-07-rtgdir-lc-eckert-2025-03-11-00
| Request | Review of | draft-ietf-bier-frr |
|---|---|---|
| Requested revision | No specific revision (document currently at 14) | |
| Type | IETF Last Call Review | |
| Team | Routing Area Directorate (rtgdir) | |
| Deadline | 2025-03-12 | |
| Requested | 2025-02-20 | |
| Requested by | Gunter Van de Velde | |
| Authors | Huaimo Chen , Mike McBride , Steffen Lindner , Michael Menth , Toerless Eckert | |
| I-D last updated | 2026-07-21 (Latest revision 2026-07-21) | |
| Completed reviews |
Genart IETF Last Call review of -06
by Joel M. Halpern
(diff)
Secdir IETF Last Call review of -07 by Erica Olsen (diff) Rtgdir IETF Last Call review of -07 by Toerless Eckert (diff) Intdir Telechat review of -08 by Brian Haberman (diff) |
|
| Comments |
Please assign to a Multicast/BIER aware reviewer (Maybe Toerless if he has availability) |
|
| Assignment | Reviewer | Toerless Eckert |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-bier-frr by Routing Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/szz_MLXhTLZdcd6NyvYcIGAcwXY | |
| Reviewed revision | 07 (document currently at 14) | |
| Result | Has issues | |
| Completed | 2025-03-11 |
review-ietf-bier-frr-07-rtgdir-lc-eckert-2025-03-11-00
Dear authors, WG.
This is really a very important technology, and it is really difficult subject,
so i very much appreciate the effort put into the document so far. It does have
to sit on the shoulders of 20 years of successful but not even yet finished FRR
work on unicast (TI-LFA still not being an RFC, but almost), and trying to
apply all this to BIER.
I had a bunch of inroads with FRR for multicast pretty much giving up on node
protection for stateful IP Multicast (though there are patents describing
mechanisms), because it is way to complex and not scalable. Likewise i had to
recently review ietf-pim-mofrr-tilfa which alas i had toifind technically very
troubled, reinforcing my past beliefs about FRR and stateful multicast.
However, BIER and FRR are actually a match made in feature heaven, which means
i think BIERs market adoption could significantly improve with FRR (given how
i've seen FRR as a core desire).
With this being said, i really would love to see a very good quality BIER-FRR
specification, and unfortunately, this version of the document has a set of
unfortunate textual shortcoming, and also a few technical specification gaps.
I have tried to suggest a bunch of text paragraphs, but i think this may
overall be too much if the desire of the WG is to simply get out something
quickly and move on. To discuss what might be the best next steps i have also
asked for a discuss slot at IETF122 BIER-WG meeting.
Here is a quick summary of the mayor points, this is followed by a more
detailled explanation of mayor concerns and then inline mayor/minor/nit
comments.
I apologize if this review does not match the normal formalisms, but it is hard
to do it that way when you believe that rewrites of larger amounts of text
would be highly beneficial.
Thank you so much again
Toerless
Summary:
No good explanation of how useful and well-working this would be compared to
e.g.: PIM-MoFRR/TI-LFA No mentioning of BIER ECMP No mentioning of BIER using
MPLS, only referencing IP. I think SR-MPLS network may be a core deployment
target for BIER so this looks like a big gap. No mentioning of (IGP) signaling
requirements to support BIER-FRR (ability/SID to receive tunneled BIER) No
correct relating FRR to the principles of IP-LFA/RLFA/TI-LFA which should be
reused. No good examples to understand when multiple copies MUST be send or MAY
be sent No explanation how the two BIFT implementation models are but examples.
No good explanation of the priorization of FRR packet copies over non-FRR
packet copies in BIFT Confusing semantic: is Tunnel-based FRR just
link-protection backup tunnel or tunnel to some BFR ?
both cases are relevant, and may need to be explained.
No explanation how link-protection tunnels can work without BIFT work, only
node-protection
requiring BIFT work to support all topologies.
WG-Q: Current status of BIER and using non-directly connected BFR-NBR ? Its a
great benefits,
but has it been implemented (requires special IGP calculations).
Overall concerns:
----
nit:
To easier find, re-recognize and talk about this technology, i would really
like to see the title amended to say "BIER Fast ReRoute (BIER-FRR)".
Establishing the term BIER-FRR,
---
major:
Others may see this as just a nit, but i think it is a major problem of the
document that it does not well highlight nor explain the significant value
that this technology offers, because this is the first time in hmm 30 years,
that we manage to bring an actual working node-protection FRR solution to
network layer multicast.
And this is only possible due to the unique design qualities of BIER. We
tried to figure out working solutions for protocol like PIM or mLDP and they
would just be horrible complex, i am not aware anyone has actually tried to
do node protection FRR with RSVP-TE/P2MP where it would be possible but
significantly unscalable, and even BIER-TE (unfortunately) would not allow to
do it anywhere near as easy (and we've tried quite a lot).
Maybe it is just me, but i have a bit the feeling as if BIER as a new,
advanced technology is still struggling with adoption and pull by customers,
and IMHO FRR could be a great argument to go to BIER - especially given how
often in the past 20 years i have seen customers obsess about FRR, and we
have not been able to deliver better FRR than PIM fast-convergence in
significant deployment number(AFAI).
Therefore, i really would like to see in the beginning an appropiate pitch
and anywhere appropriate in the document a technical explanation.
For example for the abstract:
Fast ReRoute for BIER (BIER-FRR) enables rerouting of BIER traffic based on
local triggers such as physical link state similar to IP-FRR unicast
mechanisms. Triggering and switchover can be "sub 50 msec", supporting both
link and node-protection. Node protection support is unique because its
simple and scalable support depends on the unique forwarding mechanisms of
BIER. No stateful multicast protocol has successfully defined a
node-protection mechanism. Stateful multipoint traffic-engineering or traffic
steering mechanisms such as RSVP-TE/P2MP can theoretically support
node-protection, but with much more complexity and less scalability.
Long explanation in e.g: introduction:
BIER is the first IETF standardized multicast protocol for which
node-protection FRR can work easy and efficienctly because of the way BIER
performs forwarding. It does not suffer from the complexities that ultimately
circumvented the definition of node-protection FRR mechanisms for prior,
stateful multicast protocols. This section attempts to explain why.
FRR with any IP multicast mechanisms that builds explicit forwarding tree
state such as PIM-SM (RFC7761) always has the challenge of inefficient
node-protection. The prior-hop node to the failed node discovers that this
so-called next-hop node has failed and effectively needs to unicast copies to
next-next-hop nodes.
In many topologies, there will not be arbitrary many alternative next-hop
to the failed node available to reach these next-next hops. If there is for
example only one alternative next-hop and the failed next-hop node would have
replicated to 10 next-next hop nodes, then FRR would need to send 10 unicast
copies to that same alternative next-hop, one each to every next-next hop,
hence significantly increasing the load for multicast traffic when FRR is
active, likely creating bottlenecks.
Because BIER encodes the replication in the packet header itself, undesirable
copies to reach all destinations can very often be completely avoided. If
there is a single alternative next-hop towards all destinations, then a
single BIER FRR copy to this alternative next-hop will likely suffice,
because its BIER bitstring will indicate all the ultimate receiver nodes
(BFER) to which the packet needs to go, causing the necessary replication
without any additional state requirements in the appropriate downstream
nodes. In addition, BIER-FRR implementations may even be able to avoid such a
single additional FRR copy to that alternative next-hop would already have to
carry a copy of the packet even in the absence of failure. This is detailled
further below.
RSVP-TE/P2MP or other Stateful explicit tree traffic engineering or traffic
steering mechanisms can of course support node-protection, but it comes at
the expense of per-tree, per-node pre-establishment of FRR backup trees. In a
network with 1000 RSVP-TE/P2MP trees, and average tree size of 30 nodes, this
would incur an additional 30,000 backup node-protection trees.
Minimizing unnecessary copies is only one benefit of BIER-FRR though.
Receiver driven stateful IP multicast protocols would also require
significant protocol/signaling extensions to allow a node to know the
next-next hop nodes and hence even be able to run such FRR. Such extensions
where never defined for PIM, so node-protection FRR for stateful multicast
has been only a problematic theoretical possibility.
---
major:
It is unclear to me why this spec is "informational". I think it be equally
standards track as unicast LFA RFCs such as RFC5286. Of course,
"experimental" might be most proper given thre untested/unknown BIFT
requirements. That should give the whole concept also more confidence by
operators.
Of course, this document could be left as an informational "primer" to the
technology, and the WG could follow up with a more comprehensive rewrite
including for example what is suggested in this review here and do that as a
follow up experimental RFC.
---
mayor:
This document does not discuss "support levels for" BIER-FRR.
What seems to be mostly missing is an IGP indication of how a node may be
willing to receive tunneled/SR'ed BIER packets. But likewise it may be
useful to also classify which levels of BIER-FRR sending is supported (LFA,
RLFA, TI-LFA, steiner-optimized...).
---
minor:
As a flow-over from the previous point, i would suggest the following scope
setting text (independent of the informational/standards track target of the
document). Could be put into section called "Interop considerations" for
example.
BIER-FRR, like basic "Loop Free Alternative" (LFA) for unicast (RFC5286) does
not require new protocols on the wire or new control plane functionality, so
it can easily be introduced through local router implementations
incrementally.
Like unicast LFA BIER-FRR does require enhanced forwarding plane capabilities
local to the router (BFR), it requires some fast discovery of link failure,
and it requires advanced calculation of alternative next-hops and potentially
paths to them, which can be achieved without additional routing protocol
extensions when the existing link-state IGP OSPF (RFC...) or ISIS (RFC...)
are used in conjunction with their BIER extensions (RFC...). This
"node-internal" deployment option for BIER-FRR applies to node-protection
with so-call "direct" alternative next-hops.
For other options described in this document such as link-protection and
"remote" alternative next-hops, BIER-FRR relies on pre-existing unicast
encapsulation and/or unicast packet steering mechanisms which need to be
supported by both sending and receiving BFR, and for steering also on transit
routers. These options therefore require coordinated deployment.
BIER-FRR has minimal signaling requirements. In a controller driven
deployment, no additional signaling can be required. In an IGP driven
deployment, the only additional IGP signaling required is one indicating the
level of support for BIER-FRR so that the BFR can considered for appropriate
FRR operations. In deployment where all BFR can be assumed to support
BIER-FRR, even this signaling may be unnecessary.
---
minor:
This document does not mention MPLS at all. It would be good to write some
applicability text that discusses this. For example:
This document is written with the expectation of a BIER routing underlay
associated with an IP (IPv4 or IPv6) forwarding plane and potentially IP-FRR
mechanisms being deployed. The principles of the mechanism described in this
document are believed to be equally applicable to MPLS networks where the
BIER routing underlay is only associated with an MPLS forwarding plane and
its respective FRRsupport, such as TE-FRR and/or LFA, but no validation has
been done for this combination.
Of course, it would be even better to revisit all mentions of forwarding and
FRR dependencies in unicastand consider if/what would need to be written to
make MPLS be in scope given how if my understanding is not mistaken, BIER
could be quite popular in unicast MPLS networks due to how its header and
forwarding are also well optimized for MPLS LSR.
---
minor:
This document only talks about the routing underlay but refers to unicast
forwarding and potentially unicast FRR associated/derived from that routing
underlay. This may be the typical default setup of many BIER deployments, but
it is not the architectural definition or requirement of the BIER routing
underlay, see RFC8279, section 4.1
This should be clarified in the introduction, e.g.: whenever the document
refers to forwarding in the context of the "routing underlay", it is assuming
that there is an associated IP, MPLS? or SR (IPv6/MPLS) forwarding plane
associated with the routing underlay.
---
minor
The document does not mention what to do in the case of BIER ECMP. Either add
text to declare handling of BIER-ECMP out of scope for this document, or else,
This should not really be that difficult to add. For exmple:
In case of ECMP, a single BFR-id row in the BIFT has sub-rows
for each ECMP next-hop. Most logically seem then to be the following options:
a) Upon failure of a single sub-row (next-hop), no FRR happens, but instead
the BIFT
implementation should attempt as quick as possible to ECMP across the
remaining next-hops. This should be equal or faster possible than enabling
BIER-FRR.
b) Each sub-row has FRR data associated with it, and failure of a single
next-hop sub-row
will cause its FRR to be triggered. This option has the benefit over a)
that it will potentially maintain better load-splitting, but only if the
FRR next-hop calculation does take ECMP into account, because otherwise
the remaining ECMP member next-hops would simply be the backup next-hops,
resulting in just a worse variation of a)
Failure of more than one ECMP member link should be atypical, unless the links
are part of a link-bundle between two BFR, in which case it might be better to
represent the link bundle as a logical L2 link given how there are already
various L2 options to consider such a bundle up or down based on thresholds of
working members. And distributing the traffic only across the working members.
There is no benefit in reinventing these principles for different L3 forwarding
planes like BIER.
---
minor:
It should be made clear that the two presented BIFT FRR imeplementation options
are just two out of possible various other options, but that they do not carry
any architectural significance. This would best be achieved by moving them to
some "Implementation consideration section" to split them out explicitly.
Personally, i think that it would also be beneficial to consider implementation
options that attempt to follow classical unicast FRR implementations. In those
implementations, FRR is not part of the FIB processing, but solely of the
adjacency processing, which may also include header manipulations. In the case
of BIER, this would be represented by simply using "protected" BFR-NBR entries,
in the standard RFC8279 BIFT. Once the packet is then processed by such a
protected BFR-NBR adjacency code, the status check for its primary interface
was performed and depending on success/failure, the packet would be forewarded
to the primary or backup next-hop. This would all be as in unicast. But what
this code would then also have to do specific to BIER is to and the BIER
bitstring with the appropriate FPM (primary, backup). And not only modify the
packet copy bitstring, but also return the remaining bitstring bits to the
calling BIER forwarding code.
Even if this option does not help any specific hardware for implementation, it
does describe the BIER-FRR processing in terms closest to unicast FRR and may
thus help to better understand BIER-FRR for those more familiar with unicast
FRR than BIER.
---
minor:
It would be good to explain an example that shows how an example that makes it
easy to understand how BIER-FRR is different from unicast LFA but also shares
its design.
Suggested example:
------- BFER7
/
----BFR3 --- BFR4----- BFR1 ---- BFER1
/ /
BFIR---BFRa ------ PLR --L1-- Pbfr
\ \
----BFR5 --- BFR6----- BFR2 ---- BFER2
\
------- BFER8
Wihout Pbfr failure, a BIER packet to BFER1,2,7,8 would go via BFRa, PLR, Pbfr,
...
When Pbfr fails, PLR now needs to send packets via two RLA tunnels: one to
e.g.: BFR3 from where it will be forwarded as BIER again to BFER1/BFER7, and
one to BFR5 where it will become BIER again to go to BFER2,BFER8.
This can be called a "partitioning" case for the failure of the BFR-NBR.
---
Nits:
----
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
I have to admit, i do not know what current best practice in informational IETF
documents these days is, but to me it certainly would become strange to read
through the document, not see any such RFC2119 keywoards, but the template text.
Hold the suggestion for AD feedback, but to me it sounds as if the template for
the doc should be changed to not include the paragraph referencing RFC2119
keywords.
----
Please re-check the affiliations of all authors. I see at least one co-author
whose listed affiliation is not current anymore. Maybe the co-author may still
want to give credit to that sponsor for this work, i don't know, but best to
ask. No urgency i think, this can typically be done as late as AUTH48.
----
The following is idnits numbered output of the draft with inline
concerns.
2 Network Working Group H. Chen, Ed.
3 Internet-Draft M. McBride
4 Intended status: Informational Futurewei
5 Expires: 28 August 2025 S. Lindner
6 M. Menth
7 University of Tuebingen
8 A. Wang
9 China Telecom
10 G. Mishra
11 Verizon Inc.
12 24 February 2025
14 BIER Fast ReRoute
15 draft-ietf-bier-frr-07
17 Abstract
19 This document describes a mechanism for Fast Reroute (FRR) in Bit
20 Index Explicit Replication (BIER) networks. The proposed solution
21 enhances the resiliency of BIER by providing a method to quickly
22 reroute traffic in the event of a link or node failure, thereby
23 minimizing packet loss and service disruption. The document details
24 the procedures for detecting failures and selecting backup paths
25 within the BIER domain, ensuring that multicast traffic continues to
26 reach its intended destinations without requiring per-flow state or
27 additional signaling. This FRR mechanism is designed to integrate
28 seamlessly with existing BIER operations, offering a robust solution
29 for improving network reliability.
31 Requirements Language
33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
35 document are to be interpreted as described in [RFC2119] [RFC8174]
36 when, and only when, they appear in all capitals, as shown here.
38 Status of This Memo
40 This Internet-Draft is submitted in full conformance with the
41 provisions of BCP 78 and BCP 79.
43 Internet-Drafts are working documents of the Internet Engineering
44 Task Force (IETF). Note that other groups may also distribute
45 working documents as Internet-Drafts. The list of current Internet-
46 Drafts is at https://datatracker.ietf.org/drafts/current/.
48 Internet-Drafts are draft documents valid for a maximum of six months
49 and may be updated, replaced, or obsoleted by other documents at any
50 time. It is inappropriate to use Internet-Drafts as reference
51 material or to cite them other than as "work in progress."
53 This Internet-Draft will expire on 28 August 2025.
55 Copyright Notice
57 Copyright (c) 2025 IETF Trust and the persons identified as the
58 document authors. All rights reserved.
60 This document is subject to BCP 78 and the IETF Trust's Legal
61 Provisions Relating to IETF Documents (https://trustee.ietf.org/
62 license-info) in effect on the date of publication of this document.
63 Please review these documents carefully, as they describe your rights
64 and restrictions with respect to this document. Code Components
65 extracted from this document must include Revised BSD License text as
66 described in Section 4.e of the Trust Legal Provisions and are
67 provided without warranty as described in the Revised BSD License.
69 Table of Contents
71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
73 3. Definition of BIER-FRR . . . . . . . . . . . . . . . . . . . 6
74 3.1. Definition of Forwarding Actions . . . . . . . . . . . . 6
75 3.2. Definition of Backup Forwarding Entries . . . . . . . . . 6
76 3.3. Activating and Deactivating Backup Forwarding Entries . . 7
77 3.4. Computation of the Backup F-BM . . . . . . . . . . . . . 8
78 4. Representations for BIER-FRR Forwarding Data . . . . . . . . 8
79 4.1. Potential Emergence of Redundant Packets . . . . . . . . 8
80 4.2. Primary BIFT and Single Backup BIFT . . . . . . . . . . . 10
81 4.3. Primary BIFT and Failure-Specific Backup BIFTs . . . . . 12
82 5. Protection Levels . . . . . . . . . . . . . . . . . . . . . . 13
83 5.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13
84 5.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 13
85 5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
86 6. Backup Strategies . . . . . . . . . . . . . . . . . . . . . . 14
87 6.1. Tunnel-Based BIER-FRR . . . . . . . . . . . . . . . . . . 14
88 6.1.1. Tunnel-Based BIER-FRR with Link Protection . . . . . 14
89 6.1.2. Tunnel-Based BIER-FRR with Node Protection . . . . . 16
90 6.2. LFA-based BIER-FRR . . . . . . . . . . . . . . . . . . . 17
91 6.2.1. Relation of BIER-LFAs to IP-LFAs and Prerequisites . 17
92 6.2.2. Definition of BIER-LFAs . . . . . . . . . . . . . . . 18
93 6.2.3. Protection Coverage of BIER-LFA Types . . . . . . . . 19
94 6.2.4. Sets of Supported BIER-LFAs . . . . . . . . . . . . . 20
95 6.2.5. Link Protection . . . . . . . . . . . . . . . . . . . 20
96 6.2.6. Node Protection . . . . . . . . . . . . . . . . . . . 22
97 6.2.7. Optimization Potential to Reduce Redundant BIER Packets
98 in Failure Cases . . . . . . . . . . . . . . . . . . 23
99 7. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 24
100 7.1. Comparison of LFA-Based Protection for IP-FRR and
101 BIER-FRR . . . . . . . . . . . . . . . . . . . . . . . . 24
102 7.2. Advantages and Disadvantages of Tunnel-Based BIER-FRR . . 24
103 7.2.1. Advantages . . . . . . . . . . . . . . . . . . . . . 24
104 7.2.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 25
105 7.3. Advantages and Disadvantages of LFA-Based BIER-FRR . . . 25
106 7.3.1. Advantages . . . . . . . . . . . . . . . . . . . . . 25
107 7.3.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 25
108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
111 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
112 10.2. Informative References . . . . . . . . . . . . . . . . . 26
113 Appendix A. Specific Backup Strategy Examples . . . . . . . . . 27
114 A.1. LFA-based BIER-FRR using Single BIFT . . . . . . . . . . 27
115 A.2. LFA-based BIER-FRR using Multiple Backup BIFTs . . . . . 29
116 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
117 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
120 1. Introduction
122 With BIER [RFC8279], a Bit-Forwarding Router (BFR) forwards BIER
123 packets based on a bitstring in the BIER header using the information
124 in the Bit Index Forwarding Table (BIFT). Its entries are locally
125 derived from a routing underlay or set by a controller. In case of a
126 persistent link or node failure, BIER traffic may not be delivered
127 until the BIFT has been updated based on the reconverged routing
128 underlay or by the controller.
minor:
"persistent link or node failure", "may not be delivered"
The BIER architecture does not talk about fowarding to link/nodes, and "may not
be delivered" is pretty weak. E.g.: in which cases is there a persistent link
or node failure but the packet actually would be delivered ??
Suggestions (just using capitalization to highlight new suggested text):
With BIER [RFC8279], a Bit-Forwarding Router (BFR) forwards BIER
packets TO AN ADJACENCY based on a bitstring in the BIER header using the
information
....
In case of a LOSS OF AN ADJACENCY, for example caused by failure of a link or
link-adjacent BFR, BIER traffic to that adjacency will not be delivered
until recovery of the adjacency or until the BIFT has been updated based on
the routing underlay or by the controller.
If a BFR has two or more ECMP adjacencies to a destination, failure of If
there is ECMP to a destination, the BFR
which requires reconverged routing underlay information except when there is
ECM
Without the methods introduced in this document, BIER can repair adjacencies
to a link-adjacent BFR if there is a non-failed ECMP adjacency to it.
Otherwise, it needs to wait for reconverged routing underlay information.
130 Typically, BIER packets are forwarded without an outer IP header.
131 Consequently, if a link or node failure occurs, the corresponding BFR
132 Neighbor (BFR-NBR) becomes unreachable.
minor:
The logic is flawed. Even if the packet had an IP header, for example in a BIER
partial deployment case, where a non-BIER capable link-adjacent router needs to
be tunneled through, the situation does not change.
Suggest to remove the sentence.
132 Fast Reroute (FRR)
133 mechanisms in the routing underlay, such as IP-FRR, apply exclusively
134 to IP packets, leading to potential loss of BIER traffic.
minor:
See overall concerns section
Suggested replacements avbou routing underlay and associated forwarding plane.
134 BIER
135 traffic can only be restored after the routing underlay has
136 reconverged and the BIFT has been recalculated. Tunneling BIER
nit:
prepend:
In the absence of a BIER specific FRR solution as presented here, BIER traffic
...
137 packets can serve as a solution to reach the BFR-NBR in the case of a
138 link failure by leveraging the FRR capabilities of the routing
139 underlay, provided such mechanisms are available. However, this
minor:
suggests to enhance text:
...of the routing underlay's associated unicast forwarding plane..
..provided it supports such FRR mechanisms..
140 approach does not address node failures, as all destinations that
^^ where
141 rely on the failed node as their BFR-NBR become unreachable. Given
142 that BIER often carries multicast traffic with real-time
^ loss sensitive
143 requirements, there is a particular need to protect BIER traffic
144 against prolonged outages following failures.
146 This document introduces a nomenclature for Fast Reroute in BIER
147 (BIER-FRR). Upon detecting that a BFR-NBR is unreachable, BIER-FRR
148 enables a BFR to quickly reroute affected BIER packets using backup
^
pre-established
149 forwarding entries. To avoid the generation of redundant packets,
150 backup forwarding entries should be processed before normal
151 forwarding entries. To achieve this, two potential representations
minor:
This is a hard to grasp detail, you need to provide a forward pointer to the
section where it is explained. I would also suggest to reword:
In appropriate topologies and failure cases, BIER-FRR can even completely avoid
additional packet copies at the point of local repair by leveraging an
independently necessary BIER packet copy to another BIER-NBR and adding the
bitstring bits originally destined to the unreachable BIER-NBR to that packet
(see ....).
152 for backup forwarding entries are proposed.
154 The protection level offered by BIER-FRR can be either link
155 protection or node protection. Link protection is limited to
156 safeguarding against link failures and is simpler to implement but
157 may not be effective if a BFR itself fails. Node protection, while
158 more complex, also guards against the failure of BFRs. The choice of
^^^^^^ protects
159 backup strategy determines the selection of backup forwarding
160 entries.
162 Examples of backup strategies include tunnel-based BIER-FRR and Loop-
163 Free Alternate (LFA)-based BIER-FRR:
165 * Tunnel-based BIER-FRR: This approach leverages the mechanisms of
166 the routing underlay for FRR purposes. The routing underlay
^'s FRR capable forwarding plane
167 typically restores connectivity faster than BIER, as the
168 reconvergence of the routing underlay is a prerequisite for the
169 recalculation of the BIFT. When the routing underlay utilizes FRR
170 mechanisms, its forwarding capabilities are restored well before
^^^ BIER's (aka: be specific it's otherwise hard
guess what's referred to)
171 reconvergence is completed. To benefit from the rapid restoration
^ the routing underlay (likewise be specific)
172 of the routing underlay, BIER traffic affected by a failure is
173 tunneled over the routing underlay.
175 * LFA-based BIER-FRR: This approach reroutes BIER traffic to
nit:
Introduction of term LFA without expansion. Fix. Also add reference RFC5286
176 alternative neighbors in the event of a failure. It applies the
177 principles of IP-FRR, requiring that LFAs are also BFRs. Normal
178 BIER-LFAs can be reached without tunneling, remote BIER-LFAs
mayor:
This classification needs to be improved/refined. The following concerns
coalesce the concerns against the text here, and the related text in section
3.1:
It is unclear how this distinction between Tunnel based and LFA-based relates to
the three-tier classification in 3.1 - Plain, Tunnel and Explicit.
To me, Explicit also is a case of a "tunnel" = "routing underlay" method,
because BIER itself defines explicit path forwarding based on an encap header.
Better to talk unicast tunnel with/without steering - and LFA.
In section 3.1, both "tunnel" and "explicit" are talking about "BFR-NBR" as the
destination for the tunnel / explicit-(tunnel). This must be typos, and you
likely wanted to write just "BFR", because there is never a need to use a
tunnel with or without explicit traffic steering to reach any BFR-NBR from the
PLR except when it is the BFR-NBR reachable across a broken link.
I would suggest to replace the text here with more explanatory text without
showing irritating categorization:
---
Unlike receiver-driven IP multicast protocols, BIER use the established FRR
mechanisms for unicast: FRR (RFC5286), Remote-LFA (RLFA, RFC7490) and Toipology
Independent LFA (TI-LFA, rtgwg-segment-routing-ti-lfa).
Assuming impairment of the BIER network because of a failure of the primary
BFR-NBR towards a target BFER, or the link to that BFR-NBR:
* LFA: If the BIER could be delivered to the target BFER via the so-called
backup BFR-NBR (directly
connected), the BIER-FRR can directly send the packet to that BFR-NBR
without requiring any unicast forwarding associated with the routing
underlay.
* RLFA, Tunneled: If LFA is not possible, but if there is a BFR in PQ-Space
(according to RFC7490),
then BIER-FRR can use unicast forwarding associated with the routing
underlay to send the packet to that BFR.
* TI-LFA: If there is no PQ-Space BFR, then the packet needs to be steered
across a router in
P-Space to a BFR in Q-Space. The router in P-space does not need to support
BIER, but the unicast forwarding associated with the routing underlay needs
to support traffic steering, specifically Segment Routing (SR) to allow
reuse of all mechanisms of rtgwg-segment-routing-ti-lfa.
Note that as in unicast, use of TI-LFA may be beneficial, even if RLFA or LFA
are possible, becausethe path can be better controlled, and hence overloading
of paths due to FRR conditions can be minimized.
In specific situations, BIER-FRR link-protection may end up determining that
the BFR-NBR behind the failed link is the best tunnel endpoint. This is not
considered as a special case though, because it is just one possible result of
FRR calculations. It can for example happen if there are no alternative BIER
paths, but only alternative unicast forwarding paths to reach the BIER-NBR
behind the failed link.
The main novelty of BIER-FRR versus unicast FRR and other perceived, but not
realized unicast FRR mechanisms is that the nature of replication to BFER via a
bitstring in the BIER header allows to send/tunnel a single BIER packet copy to
a precalculated BFR (via LFA, RLA, TI-LFA), and resume BIER delivery with
replication from there on to multiple BFER.
In one simple approach, a PLR would simply do the same calculations as for
LFA/RLA/TI-LFA for all BFER and then determine which set of BFER have the same
best LFA-nbr/tunnel-LFA endpoint. This allows to keep new BIER-FRR specific
calculations to a minimum and reuse all FRR calculation results from unicast.
This "simple" approach does not necessarily result in the minimum number of
copies that need to be sent in the case of BIER-FRR though, because different
BFER may just have slightly different LFA endpoints in the topology resulting
in too many unnecessary copies to be send by BIER-FRR, when instead a single
copy to one of those FRR endpoints would also be able for BIER to deliver the
packet and reduce the total amount of traffic in the network due to FRR. This
type of optimization is a case of Steiner-Tree optimization and is hence
NP-hard, but given how this can be pre-calculated, it may well be feasible to
implement this type of optimization.
Another aspect of of optimization possible with BIER-FRR is to minimize the
worst-case number of duplicate copies of the same BIER packet during FRR. This
problem may happen not only on the links shared by an FRR LFA link or
RLFA/TI-LFA tunnel, but also in the native BIER deliery beyond that FRR path
segment.
179 employ a tunnel, and topology-independent BIER-LFAs use explicit
180 paths to reach the backup BFR-NBR. Unlike tunnel-based FRR, LFA-
181 based BIER-FRR does not depend on fast reroute mechanisms in the
182 routing underlay.
minor:
The propoed text above is redundant due to the previously proposed rewrite.
184 The BIER-FRR mechanism described in this document adheres to a
185 primary/backup path model, also known as 1:1 protection, which
186 contrasts with the 1+1 protection model, where traffic is duplicated
187 across both primary and backup paths, as explored for BIER in
188 [BrAl17].
190 2. Terminology
192 This document uses the following definitions:
194 BIER: Bit Indexed Explicit Routing
196 BIER FRR: Bit Indexed Explicit Routing Fast ReRoute
198 BFR: Bit-Forwarding Router
200 BFR-NBR: Bit-Forwarding Neighbor
202 BFIR: Bit-Forwarding Ingress Router
204 BFER: Bit-Forwarding Egress Router
206 BIFT: Bit Index Forwarding Table
208 F-BM: Forwarding Bit Mask
210 PLR: Point of Local Repair
212 LFA: Loop Free Alternate
214 BF-BM: Backup F-BM
216 BBFR-NBR: Backup BFR-NBR
218 BFA: Backup Forwarding Action
220 BEA: Backup Entry Active
222 3. Definition of BIER-FRR
224 In this section, forwarding actions and backup forwarding entries are
225 defined. Then, the BIER forwarding process with BIER-FRR and the
226 computation of the backup F-BM are explained.
228 3.1. Definition of Forwarding Actions
230 A BFR-NBR is considered directly connected if it is a next hop at the
231 network layer, meaning it can be reached via link layer technology.
minor:
a BFR-NBR is always the next hop at the BIER network layer, even if it is not
link layer connected, such as in partial BIER deployments. It may not be the
next-hop in the routing underlay though.
Rewrite accordingly (... if it is a next hop in the routing undelay).
232 Conversely, if the BFR-NBR cannot be reached directly through the
233 link layer, it is regarded as indirectly connected.
235 The following forwarding actions are defined:
237 * Plain: The BIER packet is sent directly to a BFR-NBR via a direct
238 link without encapsulation in a tunnel header. This indicates
239 that the packet is not routed through the underlying network.
minor:
I am not sure if a new word "plain" is useful. Why not direct ?
Note that the situation becomes more complex if we consider non-L2 connected
BFR neighbors even without FRR.
241 * Tunnel: The BIER packet is encapsulated with a tunnel header and
242 forwarded to a BFR-NBR over the routing underlay.
minor:
The BIER packet is encapsulated with a unicast encapsulation header and
forwarded to a directly or indirectly connected BFR-NBR.
Else you need to specify what a tunnel header is. And the routing underlay can
not forward packets, but if you want to keep it as an abbrevbiation, then say
so somewhere in the beginning (when this document uses the term routing
underlay in a packet forwarding context, then it refers to a unicast forwarding
plane derived from the routing underlay).
244 * Explicit: The packet is forwarded along an explicit path to a BFR-
245 NBR. The specific path information must be provided. If segment
246 routing is employed for this purpose, the segment IDs (SIDs) must
247 be specified. Two forwarding actions of type Explicit are
248 considered equivalent only if they utilize the same explicit path.
250 In the BIFT as outlined in [RFC8279], the forwarding actions are
251 implicitly determined by the connectivity status of the BFR-NBR. If
252 the BFR-NBR is directly connected, the forwarding action is Plain.
253 If the BFR-NBR is not directly connected, the forwarding action is
254 Tunnel.
minor:
If you can find / add section references to this in RFC8279, that would be
excellent!
256 3.2. Definition of Backup Forwarding Entries
258 The BIFT as proposed in [RFC8279] includes a Forwarding Bit Mask
259 (F-BM) and a BFR-NBR for a specific BFER. These elements constitute
260 a primary forwarding entry. The BIER-FRR (Fast Reroute) mechanism
261 extends the conventional BIFT by introducing additional columns that
s/the conventional/this/
262 contain backup forwarding entries. A backup forwarding entry
263 comprises the following components:
265 * Backup Forwarding Bit Mask (BF-BM)
267 * Backup BFR Neighbor (BBFR-NBR)
269 * Backup Forwarding Action (BFA)
270 * Backup Entry Active (BEA) Flag
272 The BF-BM and BBFR-NBR share the same structure as their primary
273 counterparts. The BFA is defined as a forwarding action according to
274 Section 3.1. The BEA flag indicates whether the backup forwarding
275 entry is currently active. When active, the BF-BM, BBFR-NBR, and BFA
276 are utilized for forwarding BIER packets in place of the primary
277 forwarding entry. The structure of the extended BIFT is illustrated
278 in Figure 1.
280 +--------+------+---------+--------+----------+--------+----+
281 | BFR-id | F-BM | BFR-NBR | BF-BM | BBFR-NBR | BFA | BEA|
282 +========+======+=========+========+==========+========+====+
283 | ... | ... | ... | ... | ... | ... | |
284 +--------+------+---------+--------+----------+--------+----+
286 Figure 1: Structure of an extended BIFT with backup forwarding
287 entries.
289 The primary action is not explicitly stated in the BIFT, as it is
290 derived from the BFR-NBR. In contrast, the backup forwarding action
291 is explicitly defined in the extended BIFT. Additionally, in the
nit:
Suggest justifying why the backup forwarding action is explicity defined in
the extended BIFT. If just to ensure understanding it can be one of the three
3.1 mechanism, maybe just say "for clarity". Else, if the selection of the
right mechanism depends on aspects explained in this document then say so
"because this document details which mechanism from 3.1 is applicable in
specific situations (see section XXX..), whereas in RFC8279 the architecture
agnostic to the primary action.
292 case of an Explicit forwarding action, the explicit path must be
293 indicated. However, since explicit paths are implementation-
294 specific, this information is not detailed in the table. The values
nit:
However ....
There is a lot of implementation specific aspects in all of this. That is not
not a good excuse. Just remove this sentence and replace "Explicit" in
the tables in this document with e.g.: Explicit(P), where P indicates the
path. 3.1 already explains that the path needs to be specified.
295 for the backup BFR-NBR and the backup action depend on the desired
296 level of protection and the chosen backup strategy. Examples of
297 these are provided in Section 6.1 and Section 6.2. The Backup
298 Forwarding Bit Mask (BF-BM) is determined based on the backup BFR-
299 NBR, and its computation is described in Section 3.4.
301 3.3. Activating and Deactivating Backup Forwarding Entries
303 When a primary BFR-NBR is not reachable over the implicit primary
304 action, a failure is observed. Then, the BEA flag of the
305 corresponding backup forwarding entry is set.
307 If the primary BFR-NBR is directly connected, the information about
308 the failed interface is sufficient to detect its unreachability. If
309 the primary BFR-NBR is indirectly connected, a BFD session between
nit:
If no other change introduced it earlier already, expand BFD and add RFC
reference.
310 the BFR as PLR and the BFR-NBR may be used to monitor its
nit:
Expand PLR on first ue.
311 reachability.
313 If the primary BFR-NBR is reachable again, the BEA flag is
314 deactivated. This may be caused by the disappearance of the failure
nit:
The backup forwarding entry is activated/deactivated, but the flag is cleared
(abov you "set" it, now you "clear" it)
315 or by a change of the primary BFR-NBR due to a reconfiguration of the
316 BIFT.
nit:
you talked a lot about reconvergence of routing underlay, but here you use
reconfiguration. Would be helpful to verbally link this to reconvergence as a
cause (or controller).
318 3.4. Computation of the Backup F-BM
320 The primary F-BM of a specific BFER identifies all BFERs that share
321 the same primary Bit-Forwarding Router Neighbor (BFR-NBR). The
322 backup F-BM for a specific BFER is computed to indicate:
nit:
Would help to say that "specific BFER" refers to the BFER with
the BFR-id in the BFR-id column of the BIFD entry.
nit:
to indicate a bitset inclusive of the two following bitsets:
(to make it clear that we are doing an OR of those two bitsets).
324 * All BFERs that share both the primary and backup BFR-NBRs of the
325 specific BFER, and
327 * All BFERs for which the backup BFR-NBR of the specific BFER serves
328 as the primary BFR-NBR.
nit:
you may want to give these two sets a name each, such as the first one being
the "BFR-NBR A backup set for BFR-NBR B", and the second one being the
"BFR-NBR A primary set". Because you may want to refer to these terms to
simplify explanations (see below).
330 4. Representations for BIER-FRR Forwarding Data
332 To minimize the occurrence of redundant packets, it is essential that
333 backup entries are prioritized for use within the single extended
334 BIFT.
minor:
I find this introduction and reliance on the later complex example insufficient
to explain a rather simpler explainable principle:
With BIER-FRR two copies of the same packet may need to be sent across the same
link (and potentially following links) unless optimized BIER-FRR forwarding
rules are implemented. Consider a BFR needs to send a packet copy for BFER 1
via BFR-NBR A and a packet copy for BFER 2 via BFR-NBR B. Assume BFR-NBR B is
failed and its backup BFR-NBR is A. If the copy for BFER 1 is made first then a
second copy for BFER 2 needs to be sent towards BFR-NBR B. If the copy for BFR
2 can be done first (prioritized) whenever BFR-NBR B is unreachable, then a
single packet copy to BFR-NBR A would suffice.
The following accordingly ordered BIFT show this difference:
+--------+------+---------+--------+----------+--------+----+
| BFR-id | F-BM | BFR-NBR | BF-BM | BBFR-NBR | BFA | BEA|
+========+======+=========+========+==========+========+====+
| 1 | Abm | A | ... | ... | ... | 0 | First packet
copy +--------+------+---------+--------+----------+--------+----+ | 2
| Bbm | B | Bbm|Abm| A | ... | 1 | Second packet copy
+--------+------+---------+--------+----------+--------+----+
+--------+------+---------+--------+----------+--------+----+
| BFR-id | F-BM | BFR-NBR | BF-BM | BBFR-NBR | BFA | BEA|
+========+======+=========+========+==========+========+====+
| 2 | Bbm | B | Bbm|Abm| A | ... | 1 | Only packet
copy +--------+------+---------+--------+----------+--------+----+ | 1
| Abm | A | ... | ... | ... | 0 |
+--------+------+---------+--------+----------+--------+----+
The reason why BIER forwarding rules avoid a second copy in the second BIFT
example is that BF-BM for BFR-NBR B includes Abm, so all bits in the packet
that would cause a packet to BFR-NBR A (including the bit for BFER 1) are kept
in the packet for BFR-NBR B and are cleared before reaching the BFID row for
BFER 1, hence no second copy is being made.
Likewise, this example could be expanded by the topology i proposed in the
overall feedback section to show the example, why a single failed BFR-NBR may
require two (or more) backup entries to different BBFR-NBR.
334 However, implementing this priority may be challenging or
335 infeasible on certain hardware platforms. Consequently, two
336 alternative representations of forwarding entries are proposed. The
337 first representation involves a primary BIFT and a Single Backup BIFT
338 (SBB). The second representation comprises a primary BIFT along with
339 multiple Failure-Specific Backup BIFTs (FBB).
minor:
First of all, IMHO it should be written (emphasized) that the problem is as
said before only a simple duplication in the case of a single failure. If the
packet had to go to 50 BFER, that would still make it only 2 instead of 50
copies in the case of unicast on a link. Hence the procedures of how to avoid
this duplicates are optional and the more important the the higher the BIER
traffic load is on the network.
341 4.1. Potential Emergence of Redundant Packets
343 The BIER forwarding procedure in failure-free scenarios is designed
344 to avoid the generation of redundant packets, ensuring that at most a
345 single copy is transmitted per link for each BIER packet. However,
346 this property may be compromised when BIER-FRR, as described in
347 Section 3 is employed to provide protection against a failure.
349 Figure 2 presents an example of a BIER network. In this example,
350 BFRs are identified by the prefix "B" followed by their BFR-ids. For
351 simplicity, each BFR also serves as a BFER, and its bit position in
352 the bitstring corresponds to its BFR-id. The number assigned to each
353 link represents its cost, which the routing underlay uses to compute
354 the shortest paths.
356 1 1
357 B1 --------- B6 ------------ B5 BFR Bi is BFER
358 | | | (i = 1,2,3,4,5,6,7;
359 | | | i is BFR-id of Bi)
360 2 | | 1 |
361 | 1 | | 1 cost of link B1-B2 is 2
362 B2 --------- B7 | cost of link B3-B4 is 4
363 | | cost of other links is 1
364 1 | |
365 | 4 |
366 B3 ------------------------- B4
368 Figure 2: BIER network example.
370 The extended BIFT with backup forwarding entries for LFA-based BIER-
371 FRR with link protection, as constructed by BFR B1, is illustrated in
372 Figure 3.
374 +------+----------+-------+----------+--------+----------+---+
375 |BFR-id| F-BM |BFR-NBR| BF-BM |BBFR-NBR| BFA |BEA|
376 +======+==========+=======+==========+========+==========+===+
377 | 2 | 0000110 | B2 | 1111110 | B6 | Plain | |
378 +------+----------+-------+----------+--------+----------+---+
379 | 3 | 0000110 | B2 | 1111110 | B6 | Plain | |
380 +------+----------+-------+----------+--------+----------+---+
381 | 4 | 1111000 | B6 | 1111110 | B2 | Plain | |
382 +------+----------+-------+----------+--------+----------+---+
383 | 5 | 1111000 | B6 | 1111110 | B2 | Plain | |
384 +------+----------+-------+----------+--------+----------+---+
385 | 6 | 1111000 | B6 | 1111110 | B2 | Plain | |
386 +------+----------+-------+----------+--------+----------+---+
387 | 7 | 1111000 | B6 | 1111110 | B2 | Plain | |
388 +------+----------+-------+----------+--------+----------+---+
390 Figure 3: B1's extended BIFT for LFA-based FRR with link protection.
392 The emergence of redundant packets during a failure scenario is
393 demonstrated as follows. Consider the extended BIFT for BFR B1
394 depicted in Figure 3. This BIFT includes backup forwarding entries
395 for LFA-based FRR with link protection. In a failure-free scenario,
396 when forwarding a BIER packet destined for B2 and B6 (bitstring
397 0100010), BFR B1 sends a single copy of the packet on the link B1-B2
398 and another on the link B1-B6.
400 In the event of a failure on link B1-B6, BFR B1, acting as the PLR,
401 detects the failure. Consequently, B1 sets the BEA flag for all
402 destinations that have B6 as their BFR-NBR. If B1 is to send a BIER
403 packet to B2 and B6 under these conditions, it first sends a copy
404 with bitstring 0000010 to B2 using the corresponding primary
405 forwarding entry in the extended BIFT shown in Figure 3.
407 Subsequently, B1 sends another copy of the packet with bitstring
408 0100000 to B2 for B6, using the backup forwarding entry, since the
409 BEA flag is activated.
411 This results in a second (redundant) copy being sent over the same
412 link B1-B2. This redundancy can be avoided if the backup forwarding
413 entry is prioritized. By using the backup forwarding entry first, B1
414 would send only a single copy of the packet with bitstring 0100010 to
415 B2, and no additional copy would be sent to B2, as the bitstring in
416 the packet would be cleared by the BF-BM 1111110. Therefore,
417 prioritizing the processing of BFERs with unreachable BFR-NBRs helps
418 to reduce the generation of redundant packet copies.
nit:
I fould the example difficult to parse/follow and hence not a good choice to
understand the principles.
420 4.2. Primary BIFT and Single Backup BIFT
422 The extended BIFT can be divided into two distinct BIFTs: one serving
423 as the primary BIFT, and the other as a single backup BIFT. The
424 primary BIFT functions in the same manner as the regular BIFT. The
425 backup BIFT, however, contains the backup forwarding entries,
426 including the BBF-BM, BBFR-NBR, BFA, and BEA flag from the extended
427 BIFT. When a BFR, acting as the PLR, detects that a BFR-NBR has
^^^^^^^^^^^^^^^^^^
nit:
Would be good to provide a more comprehensive introduction to terminology,
especially PLR earlier in the doc.
428 become unreachable, it activates the BEA flag for all BFERs in the
429 backup BIFT that have the affected BFR-NBR as their primary BFR-NBR.
430 When forwarding a BIER packet, the BFR processes the packet using the
431 backup BIFT first, followed by the primary BIFT. This prioritization
432 helps to reduce the number of redundant packet copies.
434 B1's extended BIFT from Figure 3 is divided into the primary BIFT
435 shown in Figure 4 and the single backup BIFT shown in Figure 5.
437 +--------+---------+---------+
438 | BFR-id | F-BM | BFR-NBR |
439 +========+=========+=========+
440 | 2 | 0000110 | B2 |
441 +--------+---------+---------+
442 | 3 | 0000110 | B2 |
443 +--------+---------+---------+
444 | 4 | 1111000 | B6 |
445 +--------+---------+---------+
446 | 5 | 1111000 | B6 |
447 +--------+---------+---------+
448 | 6 | 1111000 | B6 |
449 +--------+---------+---------+
450 | 7 | 1111000 | B6 |
451 +--------+---------+---------+
453 Figure 4: B1's primary BIFT for the BIER network example.
455 +------+----------+--------+-----------+---+-----------------+
456 |BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
457 | | | | | | failure of |
458 +======+==========+========+===========+===+=================+
459 | 2 | 1111110 | B6 | Plain | | Link B1->B2 |
460 +------+----------+--------+-----------+---+-----------------+
461 | 3 | 1111110 | B6 | Plain | | Link B1->B2 |
462 +------+----------+--------+-----------+---+-----------------+
463 | 4 | 1111110 | B2 | Plain | | Link B1->B6 |
464 +------+----------+--------+-----------+---+-----------------+
465 | 5 | 1111110 | B2 | Plain | | Link B1->B6 |
466 +------+----------+--------+-----------+---+-----------------+
467 | 6 | 1111110 | B2 | Plain | | Link B1->B6 |
468 +------+----------+--------+-----------+---+-----------------+
469 | 7 | 1111110 | B2 | Plain | | Link B1->B6 |
470 +------+----------+--------+-----------+---+-----------------+
472 Figure 5: B1's backup BIFT for the BIER network example.
minor:
I don't think the last column is really a comment column. It's
instead the original BIFT BFR-NBR column and acts as the trigger column to set
the according BEA. So i'd suggest a column label "BFR-NBR / trigger BEA on
failure", or omething like this. and remove "B1->" from the column entries.
It's always "B1->" anyhow given how this is B1's backup BIFT".
474 Each forwarding entry in the backup BIFT includes the BF-BM, BBFR-
475 NBR, BFA, and BEA. When a BFR-NBR fails, the BEA flag is activated
476 for all BFERs in the backup BIFT that have the affected BFR-NBR as
477 their primary BFR-NBR. For instance, BFERs B4, B5, B6, and B7 have
478 BFR-NBR B6 as their primary BFR-NBR. If BFR-NBR B6 fails, the BEA
479 flag for BFERs B4, B5, B6, and B7 is activated, setting the BEA in
480 the last four entries in the backup BIFT to one.
482 4.3. Primary BIFT and Failure-Specific Backup BIFTs
484 As an alternative to the single extended BIFT, the information can be
485 represented using a primary BIFT along with several failure-specific
486 backup BIFTs. A failure-specific backup BIFT is associated with the
487 unreachability of a particular BFR-NBR. A backup BIFT for the
488 failure of BFR-NBR N is simply referred to as a backup BIFT for N.
489 This backup BIFT mirrors the structure of the regular BIFT but
490 includes entries for backup forwarding actions. Therefore, a BFR
491 maintains a primary BIFT, identical to the regular BIFT, and a
492 separate backup BIFT for each of its BFR-NBRs.
494 Under normal, failure-free conditions, the BFR utilizes the primary
495 BIFT to forward BIER packets. Upon detecting that BFR-NBR N has
496 become unreachable, the BFR, acting as the PLR, switches to the
497 backup BIFT for N to forward all BIER packets. Once the routing
498 underlay has re-converged to reflect the updated network topology,
499 the primary BIFT is re-computed. The newly computed primary BIFT is
500 then reinstated for forwarding all BIER packets.
502 This concept can be illustrated using the example of the extended
503 BIFT in Figure 3. Figure 4 depicts B1's primary BIFT in this
504 context. BFR B1 in Figure 2 has two neighbors: B6 and B2.
505 Consequently, B1 maintains two backup BIFTs with link protection: one
506 for B6 and another for B2. Additionally, B1 also maintains two
507 backup BIFTs with node protection. Figure 6 represents B1's backup
508 BIFT for B6, which is utilized in response to the unreachability of
509 B6, functioning similarly to the extended BIFT shown in Figure 3.
511 +--------+---------+---------+-----------------+-----------------+
512 | BFR-id | F-BM | BFR-NBR |Forwarding Action|Comment: protects|
513 | | | | | failure of |
514 +========+=========+=========+=================+=================+
515 | 2 | 1111110 | B2 | Plain | |
516 +--------+---------+---------+-----------------+-----------------+
517 | 3 | 1111110 | B2 | Plain | |
518 +--------+---------+---------+-----------------+-----------------+
519 | 4 | 1111110 | B2 | Plain | Link B1->B6 |
520 +--------+---------+---------+-----------------+-----------------+
521 | 5 | 1111110 | B2 | Plain | Link B1->B6 |
522 +--------+---------+---------+-----------------+-----------------+
523 | 6 | 1111110 | B2 | Plain | Link B1->B6 |
524 +--------+---------+---------+-----------------+-----------------+
525 | 7 | 1111110 | B2 | Plain | Link B1->B6 |
526 +--------+---------+---------+-----------------+-----------------+
528 Figure 6: B1's backup BIFT for B6 for LFA-based BIER FRR with
529 link protection.
531 Once B1, as the PLR, detects that B6 has become unreachable via the
532 link to B6, it switches to the backup BIFT for B6 to forward all BIER
533 packets. Since this representation aligns with the concept of a
534 single primary and single backup BIFT, the occurrence of redundant
535 packets for the same forwarding action is avoided.
537 5. Protection Levels
539 Both link protection and node protection may be supported. Link
540 protection is designed to safeguard against the failure of an
541 adjacent link, whereas node protection addresses the failure of a
542 neighboring node and the associated path leading to that node. The
543 relevance of link or node protection depends on the specific service
544 being supported. Additionally, both protection levels can be
545 combined with any of the backup strategies outlined in Section 6.
547 5.1. Link Protection
549 In link protection, the backup path is designed to circumvent the
550 failed link (i.e., the failed primary path from the PLR to the
551 primary BFR-NBR), while still potentially including the primary BFR-
552 NBR itself. Consequently, the backup path remains operational even
^^^^^^^^ is expected to
remain
553 if the primary path fails. The primary limitation of link protection
^^^^
nit:
"primary path" and "backup path" are somewhat overloaded. How do you call the
path from the PLR all the way to the BFERs ? YOu can't call it "primary path"
because that in your above text refers only to the path segment from PLR to its
primary next-hop. Which typically is link-adjacent. So you could call it link.
Or path segment. Or adjacency. In any case, find a term, an specify it
explicitly in the beginning of the text.
554 is its inability to provide protection if the primary BFR-NBR itself
555 becomes inoperative. However, link protection also offers certain
555 becomes inoperative. However, link protection also offers certain
556 advantages. It typically results in shorter backup paths compared to
557 node protection. In the case of tunnel-based BIER-FRR, link
558 protection generates at most one redundant packet, whereas node
559 protection may result in multiple redundant packets. Additionally,
minor:
This is again repeating the confusion between tunnel-based BIER-FRR and
link-protection.
These claims should not be made without at least an example. I also contend that
they differ widely based on whether Link Protection uses Tunnel-based BIER-FRR
or LFA-based BIER-FRR. Although the text so far leaves me still wondering if
LFA-based Link-Protection is even included in this documents considerations.
IMHO, it should.
In any case, I think its easy to show by example principle how Tunnel-based Link
Protection BIER-FRR has equal or longer paths than LFA-based Link Protection
BIER-FRR, and that LFA-based Node-protection BIER-FRR has equal or longer paths
than LFA-based Link Protection BIER-FRR, but equal or shorter than Tunnel-based
Link Protection BIER-FRR.
mayor:
I think the one biggest thing about link-protection is that it can be
implemented without BIFT work, just using the same type of "adjacency-level
FRR" support that is used in unicast. This should be placed somwhere
accordingly in the text.
560 for LFA-based BIER-FRR, link protection is more effective in
561 safeguarding a greater number of BFERs using normal BIER-LFAs than
562 node protection.
mayor:
I contend that this is true. Please provide an example.
564 5.2. Node Protection
566 In node protection, the backup path is designed to avoid both the
567 failed node and the link to that node (i.e., the failed primary path
568 from the PLR to the primary BFR-NBR, including the primary BFR-NBR).
569 Consequently, the backup path must exclude both the primary path and
^^^^^^^^^^^^
nit:
path segment, adjacency, ... as mentioned above
570 the primary BFR-NBR to remain operational in the event of their
571 failure. If a BFER and its primary BFR-NBR are the same, only link
571 failure. If a BFER and its primary BFR-NBR are the same, only link
572 protection is feasible for that BFER. The primary advantage of node
nit:
I stumbled across this explanation, not understanding it at first read.
Suggested better explanation:
If the primary BFR-NBR itself is a BFER, it can only be protected by
link-protection, because if it is assumed to have failed (as in node
protection), then no BIER packets need to be delivered to it.
572 protection is feasible for that BFER. The primary advantage of node
573 protection is its enhanced protection quality compared to link
574 protection. However, node protection also has certain drawbacks. It
nit:
"protection quality" is not really an explanation. Suggestion:
Failure of an adjacency can not distinguish the root cause: link or node
failure. If FRR is configured to perform link protection, the backup path
calculations only assume link failure. If FRR is configured to peform node
protection, the backup path calculations assume link or node failure. In
result, node protection may have longer paths if link protection instead could
terminate the backup path in the primary BFR-NBR.
575 typically results in longer backup paths than link protection. In
576 the context of tunnel-based BIER-FRR, node protection may lead to the
577 transmission of a greater number of redundant packets over a link
578 than with link protection. Furthermore, for LFA-based BIER-FRR,
mayor
nit:
The document should include the most simple topology example to explain this
case and if not explained here, then at least point from here to such an
explanation. I did include what i consider to be a fitting most simple example
in the overall issues list.
579 fewer BFERs may be protected using normal BIER-LFAs, necessitating
580 the use of more remote or topology-independent BIER-LFAs, which are
581 inherently more complex.
583 5.3. Example
585 In the network depicted in Figure 2, the primary path from BFR B1 to
586 BFER B5 is B1-B6-B5. Protecting BFER B5 from a BFR-NBR B6 node
587 failure can only be provided through the backup path B1-B2-B3-B4-B5.
588 Link protection for BFER B5 is achieved via the backup path
589 B1-B2-B7-B6, and additionally through the backup path
590 B1-B2-B3-B4-B5-B6. The specific backup entries are determined by the
591 selected protection level and backup strategy. Example BIFTs
592 illustrating link and node protection are provided in Section 6.
594 6. Backup Strategies
596 Backup strategies determine the selection of backup forwarding
597 entries, influencing both the choice of the backup BFR-NBR and the
598 backup action, and consequently, the backup path. The following
599 sections present tunnel-based BIER-FRR and LFA-based BIER-FRR as
600 potential strategies.
602 6.1. Tunnel-Based BIER-FRR
604 The routing underlay may possess the capability to forward packets to
605 their destinations even in the presence of a failure, potentially due
606 to FRR mechanisms within the routing underlay. In such scenarios,
607 while the primary BFR-NBR may no longer be reachable via the primary
608 action (Plain), it could still be accessible through a backup action
609 (Tunnel).
611 Tunnel-based BIER-FRR encapsulates BIER packets impacted by a failure
612 within the routing underlay, thereby leveraging the routing
613 underlay's fast restoration capabilities. As soon as connectivity in
614 the routing underlay is reestablished, the affected BIER packets can
615 be forwarded to their intended destinations. The appropriate backup
616 forwarding entries in a BIFT for BIER-FRR are determined by the
617 desired protection level.
619 6.1.1. Tunnel-Based BIER-FRR with Link Protection
621 In the context of link protection, the backup BFR-NBRs are identical
622 to the primary BFR-NBRs. If a primary BFR-NBR is directly connected
623 to the BFR acting as the Point of Local Repair (PLR), the
624 corresponding backup forwarding action is Tunnel. Consequently, BIER
625 packets affected by a failure are tunneled through the routing
626 underlay to their BFR-NBR, rather than being directly sent as plain
627 BIER packets. If the primary BFR-NBR is not directly connected to
628 the BFR as a PLR (i.e., the implicit primary action is Tunnel), the
629 corresponding backup action is also Tunnel. The backup F-BMs are
minor:
The backup tunnel may need to be a TI-LFA, which in your terminology so far is
"explicit". Otherwise you do not get 100% coverage.
630 identical to the primary F-BMs, consistent with the computation of
631 backup F-BMs described in Section 3.4.
633 +------+----------+--------+-----------+---+-----------------+
634 |BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
635 | | | | | | failure of |
636 +======+==========+========+===========+===+=================+
637 | 2 | 0000110 | B2 | Tunnel | | Link B1->B2 |
638 +------+----------+--------+-----------+---+-----------------+
639 | 3 | 0000110 | B2 | Tunnel | | Link B1->B2 |
640 +------+----------+--------+-----------+---+-----------------+
641 | 4 | 1111000 | B6 | Tunnel | | Link B1->B6 |
642 +------+----------+--------+-----------+---+-----------------+
643 | 5 | 1111000 | B6 | Tunnel | | Link B1->B6 |
644 +------+----------+--------+-----------+---+-----------------+
645 | 6 | 1111000 | B6 | Tunnel | | Link B1->B6 |
646 +------+----------+--------+-----------+---+-----------------+
647 | 7 | 1111000 | B6 | Tunnel | | Link B1->B6 |
648 +------+----------+--------+-----------+---+-----------------+
650 Figure 7: B1's backup BIFT for tunnel-based BIER-FRR with link
651 protection.
653 Figure 7 illustrates B1's backup BIFT for tunnel-based BIER-FRR with
654 link protection in the BIER network example depicted in Figure 2.
655 The backup BFR-NBRs and backup F-BMs in this backup BIFT correspond
656 to the primary BFR-NBRs and primary F-BMs in the primary BIFT shown
657 in Figure 4. However, the backup actions in this backup BIFT are
658 Tunnel, while the primary actions in the primary BIFT are Plain
659 (which are not explicitly shown but implied).
661 When B1, acting as the PLR, detects a failure of its link to B6, a
662 BIER packet with the bitstring 0100000 destined for B6 is tunneled by
663 B1 through the routing underlay towards B6. The specific path of the
664 backup tunnel depends on the routing underlay and could be
665 B1-B2-B7-B6 or B1-B2-B3-B4-B5-B6.
667 If a BIER packet is destined for {B2, B5, B7}, an encapsulated packet
668 copy is first forwarded via link B1-B2 to backup BFR-NBR B6 using the
669 backup action Tunnel to deliver packet copies to BFERs B5 and B7.
670 Subsequently, a non-encapsulated packet copy is forwarded via link
671 B1-B2 to BFR-NBR B2 using the primary action Plain to deliver a
672 packet copy to BFER B2. Therefore, with tunnel-based BIER-FRR, a
673 single redundant packet copy may occur in the event of a failure
674 because an encapsulated and a non-encapsulated packet copy are
675 forwarded over the same link. This redundancy occurs even though
676 BIER packets affected by failures are forwarded before those
677 unaffected by failures.
679 A BIER packet with the bitstring 1000000 destined for B7 is forwarded
680 along the backup path B1-B2-B7-B6-B7, as it is first delivered to the
681 backup BFR-NBR B6. Consequently, the backup path may be
682 unnecessarily long. This phenomenon is similar to the facility
683 backup method described in [RFC4090] which employs paths analogous to
684 those in tunnel-based BIER-FRR..
686 6.1.2. Tunnel-Based BIER-FRR with Node Protection
688 To determine the backup forwarding entries for node protection, a
689 case-by-case analysis of the BFER to be protected is required. If
690 the BFER is the same as its primary BFR-NBR, node protection is not
691 feasible for that BFER. In such cases, link protection is applied,
692 meaning the backup BFR-NBR is set to the primary BFR-NBR. If this
693 level of protection is deemed insufficient, egress protection as
694 described in [I-D.chen-bier-egress-protect] may be applied.If the
nit:
New paragraph
694 If the
695 BFER is different from its primary BFR-NBR, the backup BFR-NBR is set
696 to the primary BFR-NBR's primary BFR-NBR for that BFER, making the
697 backup BFR-NBR a next-next-hop BFR. In all scenarios, the backup
minor:
You may not be able to reach this next-next hop neighbor without explicit
tunnel, which you do not call tunnel.
I would also give this strategy a different name. The defining property of this
approach is not "tunnel", but it is do do RLFA/TI-LFA to the next-next hops.
Without additional signaling, this can only be done if the PLR does exactly know
the path calculation of the (assumed) failed BFR-NBR. So it would rather be
correct to say "the assumed next-next hop - as calculated by the PLR assuming it
was the failed BFR-NBR".
I guess the next step then is to group all BFER reachable via the failed BFR
neighbor by the ssame next-next hop to determine the different FRR copies that
need to be sent. This process should be better explained. Doing this from the
example does not make it clear whats the supposed algorithm is.
698 action is Tunnel. In the first case, the backup F-BM is set to all
699 zeros with the bit for the BFER to be protected enabled. In the
700 second case, the backup F-BM is computed as described in Section 3.4.
702 +------+----------+--------+----------+---+-----------------+
703 |BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
704 | | | | | | failure of |
705 +======+==========+========+==========+===+=================+
706 | 2 | 0000010 | B2 | Tunnel | | Link B1->B2 |
707 +------+----------+--------+----------+---+-----------------+
708 | 3 | 0000100 | B3 | Tunnel | | BFR-NBR B2 |
709 +------+----------+--------+----------+---+-----------------+
710 | 4 | 0011000 | B5 | Tunnel | | BFR-NBR B6 |
711 +------+----------+--------+----------+---+-----------------+
712 | 5 | 0011000 | B5 | Tunnel | | BFR-NBR B6 |
713 +------+----------+--------+----------+---+-----------------+
714 | 6 | 0100000 | B6 | Tunnel | | Link B1->B6 |
715 +------+----------+--------+----------+---+-----------------+
716 | 7 | 1000000 | B7 | Tunnel | | BFR-NBR B6 |
717 +------+----------+--------+----------+---+-----------------+
719 Figure 8: B1's backup BIFT for tunnel-based BIER-FRR with node
720 protection.
722 Figure 8 illustrates B1's backup BIFT for tunnel-based BIER-FRR with
723 node protection in the BIER network example provided in Figure 2.
724 BFERs B2 and B6 are direct neighbors of B1. To protect them, only
725 link protection is applied, as B1's primary BFR-NBR for these nodes
726 is the nodes themselves. As described above, only the bit for B2 is
727 set in the backup F-BM of B2, and similarly for B6. For BFER B5, the
728 backup BFR-NBR is B5, as it is B1's next-next-hop BFR towards B5.
729 Similarly, for BFER B7, the backup BFR-NBR is B7. When B1, acting as
730 the PLR, detects the failure of its BFR-NBR B6, a BIER packet with
731 bitstring 1010010 destined for {B2, B5, B7} is processed as follows:
732 an encapsulated copy of the packet is sent via tunnel B1-B2-B3-B4-B5,
733 another encapsulated copy is sent via tunnel B1-B2-B7, and a non-
734 encapsulated copy is sent via link B1-B2. In this example, two
735 redundant packets are sent over link B1-B2. Therefore, node
736 protection may result in more redundant packet copies than link
737 protection..
739 Caveat: If the routing underlay does not support node protection,
740 tunnel-based BIER-FRR will similarly be unable to provide node
741 protection. This limitation is illustrated in the following example.
742 In the network depicted in Figure 2, the underlay offers only link
743 protection. If BFR-NBR B6 fails and B1 must forward a packet to B5,
744 according to the backup BIFT in Figure 8 the packet is tunneled
745 towards B5. The underlay may route the packet along the path
746 B1-B2-B7-B6-B5 due to FRR with link protection. However, since B6 is
747 also unreachable from B7, the packet is returned to B2, resulting in
748 a loop between B2 and B7.
750 6.2. LFA-based BIER-FRR
752 LFA-based BIER-FRR leverages alternate BFRs to deliver BIER packets
753 to BFERs for which the primary BFR-NBR is unreachable. This approach
754 does not rely on any fast restoration or protection mechanisms in the
755 underlying routing infrastructure. First, the prerequisites for LFA-
756 based BIER-FRR are clarified, followed by the definition of BIER-
757 LFAs. Subsequently, link and node protection for LFA-based BIER-FRR
758 are discussed using a single backup BIFT.
760 6.2.1. Relation of BIER-LFAs to IP-LFAs and Prerequisites
762 A LFA for a specific destination is an alternate node to which a
763 packet is sent if the primary next hop for that destination is
764 unreachable. This alternate node should be capable of forwarding the
765 packet without creating a forwarding loop. LFAs have been defined
766 for IP networks in [RFC5286], [RFC7490] and
767 [I-D.ietf-rtgwg-segment-routing-ti-lfa], and such LFAs are referred
768 to as IP-LFAs. BIER-LFAs are similar to IP-LFAs, but a BIER-LFA node
769 must be a BFR. If only a subset of the nodes in the routing underlay
770 are BFRs, some IP-LFAs in the routing underlay may not be usable as
771 BIER-LFAs. To compute BIER-LFAs, network topology and link cost
772 information from the routing underlay are required. This differs
773 from tunnel-based BIER-FRR, where knowledge of the primary BIFTs of a
774 PLR and its BFR-NBRs is sufficient.
mayor:
"This differs from tunnel-based BIER-FRR, where knowledge of the primary BIFTs
of a
PLR and its BFR-NBRs is sufficient."
What ? Thats different from what you wrote before:
| 694 If the
| 695 BFER is different from its primary BFR-NBR, the backup BFR-NBR is
set | 696 to the primary BFR-NBR's primary BFR-NBR for that BFER, making
the | 697 backup BFR-NBR a next-next-hop BFR. In all scenarios, the
backup
That's the next-next hop, and the PLR can only get that information from the
link-state database, quite the same as LFA calculations. The thing that can
make the next-next-hop approach easier/different is that it does not require
calculation in the link-state-database under assumption of failure. That could
make it an easier calculation.
776 LFA-based BIER-FRR may reuse IP-LFAs as BIER-LFAs under the following
777 conditions: if an IP-LFA node for the destination of a specific BFER
778 is a BFR, it may be reused as the backup BFR-NBR for that BFER, along
779 with the backup action applied for that IP-LFA at the IP layer. A
780 normal IP-LFA corresponds to the backup action Plain, a remote IP-LFA
781 to Tunnel, and a TI-IP-LFA to Explicit.
783 6.2.2. Definition of BIER-LFAs
785 As with IP-LFAs, there are several types of BIER-LFAs:
787 * A BFR is considered a normal BIER-LFA for a specific BFER if it is
788 directly connected to the PLR and:
790 1. the BFER can be reached from it through the BIER domain.
792 2. both the path from the PLR to the BFR and the path from the
793 BFR to the BFER are disjoint from the primary path from the
794 PLR to the primary BFR-NBR. These paths:
796 - may include the primary BFR-NBR for link protection.
798 - must not include the primary BFR-NBR for node protection.
800 * A BFR is considered a remote BIER-LFA for a specific BFER if it is
801 not directly connected to the PLR, can be reached via a tunnel
802 from the PLR, and satisfies the aforementioned conditions 1 and 2.
804 * A BFR is considered a TI-BIER-LFA for a specific BFER if it is not
805 directly connected to the PLR, cannot be reached via a tunnel from
806 the PLR, but is reachable from the PLR via an explicit path (e.g.,
807 with the assistance of a Segment Routing (SR) header), and
808 satisfies the aforementioned conditions 1 and 2.
minor:
I think you are writing the same thing that the LFA architecture has explained
with the P/Q space concept, except that you didn't use that well estavblished
terminology, so the readers have to wonder if there is a difference or how to
know/determine if a case if LFA/RLFA or TILFA. Would be good to try to write
these explanations such that they refer to the unicast concepts and only point
out differences. Where i think the only differdence is what i wrote in the
beginning.
810 For some BFERs, one or more normal BIER-LFAs may be available at a
811 specific PLR. For other BFERs, only remote or TI-BIER-LFAs may be
812 available. There may also be BFERs for which only TI-BIER-LFAs are
813 available.
815 The backup actions for rerouting BIER packets depending on the type
816 of BIER-LFA are:
818 * For normal BIER-LFA: Plain
820 * For remote BIER-LFA: Tunnel
822 * For TI-BIER-LFA: Explicit
824 6.2.3. Protection Coverage of BIER-LFA Types
826 Protection coverage refers to the set of BFERs that can be protected
827 with a desired level of protection by a particular type of BIER-LFA.
828 The BIER-LFA types exhibit the following characteristics:
830 * Normal BIER-LFAs
832 - The protection coverage is the least, as some or many BFERs may
833 not be protected at the desired level or at all.
835 - Redundant packet copies are avoided.
837 - There is no encapsulation overhead.
839 * Remote BIER-LFAs
841 - They enhance the protection coverage of normal BIER-LFAs.
843 - Redundant packet copies may occur on a link, similar to tunnel-
844 based BIER-FRR.
846 - The encapsulation overhead is similar to that of tunnel-based
847 BIER-FRR.
849 * TI-BIER-LFAs
851 - They complement the protection coverage of normal and remote
852 BIER-LFAs to achieve 100% coverage.
854 - Redundant packets may occur on a link, similar to tunnel-based
855 BIER-FRR.
857 - The encapsulation overhead is similar or equivalent to that of
858 tunnel-based BIER-FRR, depending on the FRR mechanism employed
859 in the routing underlay.
minor:
This would all be a lot easier to absorb if it was phrased as "this is all the
same as in unicast" - except that instead of having multiple LFA/RLFA/TIFLA
tunnels to the same endpoints but for different destinations, we are sending
BIER packets into one such tunnel and it will be replicated after reaching the
tunnel endpoint.
861 6.2.4. Sets of Supported BIER-LFAs
863 Normal BIER-LFAs are the simplest option, as they do not require
864 tunneling or explicit paths. Remote BIER-LFAs offer greater
865 capabilities but introduce additional header overhead and require
^^^^^^^^^^^^ coverage
866 more functionality from the PLR. TI-BIER-LFAs are the most complex,
minor:
please specify what functionality - more advanced LFA calculations and tunnel
encapsulation for BIER packets.
866 more functionality from the PLR. TI-BIER-LFAs are the most complex,
867 necessitating the use of explicit paths. When implementing LFA-based
868 BIER-FRR, it is essential to specify the set of supported BIER-LFAs.
869 The available options are as follows:
871 * Option 1: Only normal BIER-LFAs are supported.
873 * Option 2: Both normal and remote BIER-LFAs are supported.
875 * Option 3: All types of BIER-LFAs are supported.
877 6.2.5. Link Protection
879 In link protection, normal BIER-LFAs are prioritized over remote
880 LFAs, and remote BIER-LFAs are preferred over TI-BIER-LFAs.
minor:
Thats one policy, but if the policy is to calculate some optimized traffic
characteristics, then is is not necessarily true.
881 Depending on the set of supported BIER-LFAs, it may not be possible
^ and topology
882 to protect all BFERs.
nit:
For 100% coverage in all topologies, the network needs to support TI-LFA.
884 Figure 5 illustrates B1's backup BIFT for LFA-based BIER-FRR with
885 link protection, using the network example provided in Figure 2.
887 If the link between B1 and B6 fails, B1 cannot reach the BFERs B4,
888 B5, B6, and B7 via their primary BFR-NBR. Consequently, B1 forwards
889 their traffic via the backup BFR-NBR B2, along with the traffic for
890 B2 and B3, as B2 is their primary BFR-NBR. In this scenario, the
891 backup F-BM is set to 1111110. Similarly, if the link between B1 and
892 B2 fails, B1 routes all traffic to B6, with the backup F-BM also set
893 to 1111110.
895 B1 requires only normal BIER-LFAs to protect all BFERs. However,
896 this situation can vary significantly for other BFRs. Figure 9 and
897 Figure 10 present the backup BIFTs for B7 and B5, respectively. BFR
898 B7 requires one normal BIER-LFA, three remote BIER-LFAs, and two TI-
899 BIER-LFAs to protect all BFERs. BFR B5 requires one normal BIER-LFA,
900 one remote BIER-LFA, and four TI-BIER-LFAs as backup BFR-NBRs. Thus,
901 depending on the set of supported BIER-LFAs, it may not be possible
902 to protect all BFERs using BIER-FRR.
904 Consider a scenario where B7 holds a BIER packet with destinations
905 {B1, B4, B5, B6}. If the link between B7 and B6 fails, the packet
906 copy for B1 is sent to B2 using the forwarding action Plain, the
907 packet copy for B4 is tunneled via B2 to B3, and the packet copies
908 for B5 and B6 are sent via explicit paths to B4 and B1, respectively.
909 Since these packet copies have different headers, all of them must be
910 transmitted, resulting in three redundant copies.
912 +------+----------+--------+-----------+---+-----------------+
913 |BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
914 | | | | | | failure of |
915 +======+==========+========+===========+===+=================+
916 | 1 | 0000111 | B2 | Plain | | Link B7->B6 |
917 +------+----------+--------+-----------+---+-----------------+
918 | 2 | 0000110 | B1 | Tunnel | | Link B1->B2 |
919 +------+----------+--------+-----------+---+-----------------+
920 | 3 | 0000110 | B1 | Tunnel | | Link B1->B2 |
921 +------+----------+--------+-----------+---+-----------------+
922 | 4 | 0001000 | B3 | Tunnel | | Link B1->B6 |
923 +------+----------+--------+-----------+---+-----------------+
924 | 5 | 0010000 | B4 | Explicit | | Link B1->B6 |
925 +------+----------+--------+-----------+---+-----------------+
926 | 6 | 0100000 | B1 | Explicit | | Link B1->B6 |
927 +------+----------+--------+-----------+---+-----------------+
929 Figure 9: B7's backup BIFT with link protection.
931 +------+----------+--------+-----------+---+-----------------+
932 |BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
933 | | | | | | failure of |
934 +======+==========+========+===========+===+=================+
935 | 1 | 1100011 | B3 | Explicit | | Link B5->B6 |
936 +------+----------+--------+-----------+---+-----------------+
937 | 2 | 1100011 | B3 | Explicit | | Link B5->B6 |
938 +------+----------+--------+-----------+---+-----------------+
939 | 3 | 0000100 | B4 | Plain | | Link B5->B6 |
940 +------+----------+--------+-----------+---+-----------------+
941 | 4 | 0001000 | B3 | Tunnel | | Link B5->B4 |
942 +------+----------+--------+-----------+---+-----------------+
943 | 6 | 1100011 | B3 | Explicit | | Link B5->B6 |
944 +------+----------+--------+-----------+---+-----------------+
945 | 7 | 1100011 | B3 | Explicit | | Link B5->B6 |
946 +------+----------+--------+-----------+---+-----------------+
948 Figure 10: B5's backup BIFT with link protection.
950 6.2.6. Node Protection
952 To determine the backup forwarding entries for node protection, it is
953 necessary to conduct a case-by-case analysis of the BFER to be
954 protected. If the BFER is the same as its primary BFR-NBR, node
955 protection is not feasible for that BFER, and link protection must be
956 applied instead. In all other cases, the BFER should be protected by
957 a node-protecting BIER-LFA. In this context, normal BIER-LFAs are
958 prioritized over remote BIER-LFAs, and remote BIER-LFAs are preferred
959 over TI-BIER-LFAs. Depending on the set of supported BIER-LFAs, it
960 may not be possible to protect certain BFERs.
962 Figure 11 illustrates B1's backup BIFT for LFA-based BIER-FRR with
963 node protection, using the network example provided in Figure 2.
965 +------+----------+--------+-----------+---+-----------------+
966 |BFR-id| BF-BM |BBFR-NBR| BFA |BEA|Comment: protects|
967 | | | | | | failure of |
968 +======+==========+========+===========+===+=================+
969 | 2 | 1111010 | B6 | Plain | | BFR-NBR B2 |
970 +------+----------+--------+-----------+---+-----------------+
971 | 3 | 0000100 | B4 | Tunnel | | BFR-NBR B2 |
972 +------+----------+--------+-----------+---+-----------------+
973 | 4 | 0001000 | B3 | Tunnel | | BFR-NBR B6 |
974 +------+----------+--------+-----------+---+-----------------+
975 | 5 | 0010000 | B4 | Explicit | | BFR-NBR B6 |
976 +------+----------+--------+-----------+---+-----------------+
977 | 6 | 1100100 | B2 | Plain | | BFR-NBR B6 |
978 +------+----------+--------+-----------+---+-----------------+
979 | 7 | 1100100 | B2 | Plain | | BFR-NBR B6 |
980 +------+----------+--------+-----------+---+-----------------+
982 Figure 11: B1's backup BIFT with node protection.
984 As B6 serves as the primary BFR-NBR for BFER B6, only link protection
985 can be applied. Consequently, B2 is utilized as a normal, link-
986 protecting BIER-LFA to safeguard B6. Similarly, as B2 is the primary
987 BFR-NBR for BFER B2, B2 is protected with B6 as its normal, link-
988 protecting BIER-LFA. BFER B7 is protected against the failure of
989 node B6 by using B2 as its normal, node-protecting BIER-LFA, as B2
990 has a shortest path to B7 that does not traverse B6. The backup
991 F-BMs for BFERs B6 and B7 are set to {B2, B6, B7}, as traffic for
992 these BFERs is routed via link B1-B2 with the forwarding action Plain
993 when B6 is unreachable.
995 BFER B4 cannot be reached via a normal LFA when BFR B6 fails.
996 However, B3 serves as a remote, node-protecting BIER-LFA for BFER B4,
997 as B3 has a shortest path to B4, is reachable from B1 via a shortest
998 path, and the resulting backup path from B1 to B4 does not traverse
999 B6. Similarly, B4 serves as a remote LFA for BFER B3 if BFR B2
1000 fails.
1002 BFER B5 is neither reachable through a normal BIER-LFA nor through a
1003 remote BIER-LFA when BFR B6 fails. However, B4 acts as a node-
1004 protecting TI-LFA for BFER B5, as B4 has a shortest path to B5 that
1005 does not traverse B6. Additionally, B4 is reachable through the
1006 explicit path B1-B2-B3-B4.
1008 6.2.7. Optimization Potential to Reduce Redundant BIER Packets in
1009 Failure Cases
1011 Redundant packets can occur with LFA-based BIER-FRR when BIER packets
1012 are transmitted over a specific link in different forms, including:
1014 * Plain BIER packets (either primary transmission or reroute to a
1015 normal BIER-LFA).
1017 * BIER packets encapsulated for transmission to a specific BFR-NBR
1018 (either tunneled primary transmission or reroute to a remote BIER-
1019 LFA).
1021 * BIER packets routed with an encoded explicit path (reroute to a
1022 TI-LFA).
1024 When different remote LFAs are utilized, multiple redundant packets
1025 may be generated through remote LFAs. A similar situation can arise
1026 with TI-LFAs. However, some redundant packets can be mitigated if
1027 remote LFAs or TI-LFAs are selected such that they can protect
1028 multiple BFERs, thereby reducing the need for additional remote LFAs
1029 or TI-LFAs. This approach, while potentially leading to longer
1030 backup paths, introduces a new optimization objective for the
1031 selection of remote or TI-BIER-LFAs, which does not exist in IP-FRR.
1032 The relevance of this optimization may vary depending on the specific
1033 use case.
1035 To illustrate this optimization potential, consider LFA-based BIER-
1036 FRR with link protection for B7, as described in its backup BIFT in
1037 Figure 9. As noted in Section 6.2.5, B7 needs to transmit four
1038 copies to forward a packet to {B1, B4, B5, B6}. If the more complex
1039 TI-BIER-LFA B4 is chosen to protect BFER B4 instead of the remote
1040 BIER-LFA B3, only two redundant copies need to be transmitted.
1042 7. Comparison
1044 This section first addresses the differences between IP-LFAs for IP-
1045 FRR and BIER-LFAs for BIER-FRR. It then examines the advantages and
1046 disadvantages of tunnel-based and LFA-based BIER-FRR.
1048 7.1. Comparison of LFA-Based Protection for IP-FRR and BIER-FRR
1050 LFAs were initially proposed for IP networks. They are
1051 straightforward in that they do not require any tunneling overhead.
1052 However, certain destinations cannot be protected against specific
1053 link failures, and even more destinations may be unprotected against
1054 certain node failures. To improve coverage, remote LFAs (R-LFAs)
1055 were introduced, which tunnel affected traffic to another node from
1056 which the traffic can reach the destination through normal
1057 forwarding. Despite this, there may still be destinations that
1058 remain unprotected against link or node failures. To address this,
1059 topology-independent LFAs (TI-LFAs) were developed, wherein affected
1060 traffic is tunneled via an explicit path (preferably using segment
1061 routing headers) to another node from which the traffic can reach its
1062 destination through standard IP forwarding. With TI-LFAs, all
1063 destinations can be protected against any failures as long as
1064 connectivity exists.
1066 LFA-based BIER-FRR adopts the principles of LFAs but differs from IP-
1067 FRR in that the LFA target node, i.e., the node to which traffic is
1068 diverted, must be a BFR. If an IP-LFA target is a BFR, it can be
1069 utilized as a BIER-LFA; otherwise, it cannot serve as a BIER-LFA.
1070 Consequently, if only a subset of nodes in the underlay are BFRs, the
1071 BIER-LFAs will differ substantially from IP-LFAs. Furthermore, this
1072 makes it more challenging to identify normal LFAs that do not require
1073 tunneling. As a result, LFA-based BIER-FRR is likely to require more
1074 remote LFAs and TI-LFAs than IP-FRR under such conditions.
minor:
Maybe try to collect a lot of this discussion and move into a backgrounder. I
think with the emergence of TI-LFA a lot of the simpler solutions may quickly
be seen as legacy, and then its better to have only the main/most-advanced
option as the main focus of attention.
1076 7.2. Advantages and Disadvantages of Tunnel-Based BIER-FRR
1078 7.2.1. Advantages
1080 * The computation of backup forwarding entries is straightforward,
1081 requiring only the primary BIFTs of a PLR and its BFR-NBRs. No
1082 routing information from the routing underlay is necessary.
1084 * The forwarding action "Explicit" is not required. However,
1085 depending on the underlay, explicit forwarding may still be
1086 utilized to achieve FRR in the underlay.
mayor:
This is not true for node protection (next-next-hop calculation for BIER-FRR).
It is also just expects that the routing underlay has done all the hard work.
Aka: Correctly tated it is "least amount of additional work to support BIER-FRR
when there is already unicast FRR".
1088 7.2.2. Disadvantages
1090 * It relies on the presence of a FRR mechanism in the underlay.
1092 * It is constrained by the protection level provided by the
1093 underlay. For instance, if the underlay supports only link
1094 protection, tunnel-based BIER-FRR cannot offer node protection.
1096 * Redundant packet copies may occur in tunnel-based BIER-FRR.
nit:
should be able to explain/point to simple example where this is true when usuing
pre-established unicast FRR tunnels vs. new BIER-LFA tunnels.
1098 * In the case of node protection, backup paths may be unnecessarily
1099 extended.
1101 * A tunneling header is required for any rerouting, resulting in
1102 additional header overhead.
1104 7.3. Advantages and Disadvantages of LFA-Based BIER-FRR
1106 7.3.1. Advantages
1108 * It does not depend on any fast protection mechanisms in the
1109 underlay.
1111 * It can provide superior protection at the BIER layer compared to
1112 the IP layer, particularly if LFA-based BIER-FRR utilizes BIER-
1113 LFAs with a higher protection level than those used in LFA-based
1114 IP-FRR. For example, the underlay may only offer FRR with link
1115 protection, while BIER-FRR can provide node protection for BIER
1116 traffic.
1118 * It avoids header overhead for normal BIER-LFAs.
1120 7.3.2. Disadvantages
1122 * The computation of backup forwarding entries requires routing
1123 information from the underlay.
1125 * The computation of backup forwarding entries is more complex when
1126 some nodes in the underlay are not BFRs.
1128 * The "Tunnel" forwarding action is required to protect certain
1129 BFERs, which adds header overhead.
1131 * The "Explicit" forwarding action is necessary to achieve full
1132 protection coverage in some topologies; without it, only partial
1133 protection coverage is possible. This requires support for
1134 explicit paths, such as segment routing.
1136 * More remote and TI-LFAs are needed compared to IP-FRR if some
1137 nodes in the routing underlay are not BFRs.
1139 * Redundant packet copies may occur in LFA-based BIER-FRR, though
1140 this is less frequent than with tunnel-based BIER-FRR.
1142 8. Security Considerations
1144 This specification does not introduce additional security concerns
1145 beyond those already discussed in the BIER architecture [RFC8279]
1146 along with the IP FRR [RFC5286] and LFA [RFC7490] specifications.
1148 9. IANA Considerations
1150 No requirements for IANA.
1152 10. References
1154 10.1. Normative References
1156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1157 Requirement Levels", BCP 14, RFC 2119,
1158 DOI 10.17487/RFC2119, March 1997,
1159 <https://www.rfc-editor.org/info/rfc2119>.
1161 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
1162 IP Fast Reroute: Loop-Free Alternates", RFC 5286,
1163 DOI 10.17487/RFC5286, September 2008,
1164 <https://www.rfc-editor.org/info/rfc5286>.
1166 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
1167 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
1168 RFC 7490, DOI 10.17487/RFC7490, April 2015,
1169 <https://www.rfc-editor.org/info/rfc7490>.
1171 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1172 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1173 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1175 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
1176 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
1177 Explicit Replication (BIER)", RFC 8279,
1178 DOI 10.17487/RFC8279, November 2017,
1179 <https://www.rfc-editor.org/info/rfc8279>.
1181 10.2. Informative References
1183 [BrAl17] Braun, W., Albert, M., Eckert, T., and M. Menth,
1184 "Performance Comparison of Resilience Mechanisms for
1185 Stateless Multicast Using BIER", May 2017.
1187 [I-D.chen-bier-egress-protect]
1188 Chen, H., McBride, M., Wang, A., Mishra, G. S., Liu, Y.,
1189 Menth, M., Khasanov, B., Geng, X., Fan, Y., Liu, L., and
1190 X. Liu, "BIER Egress Protection", Work in Progress,
1191 Internet-Draft, draft-chen-bier-egress-protect-07, 28
1192 March 2024, <https://datatracker.ietf.org/doc/html/draft-
1193 chen-bier-egress-protect-07>.
1195 [I-D.ietf-rtgwg-segment-routing-ti-lfa]
1196 Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
1197 Decraene, B., and D. Voyer, "Topology Independent Fast
1198 Reroute using Segment Routing", Work in Progress,
1199 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
1200 21, 12 February 2025,
1201 <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
1202 segment-routing-ti-lfa-21>.
1204 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
1205 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
1206 DOI 10.17487/RFC4090, May 2005,
1207 <https://www.rfc-editor.org/info/rfc4090>.
EOF - have not reviewed for now the appendices.
1209 Appendix A. Specific Backup Strategy Examples
1211 This appendix demonstrates the computations of some specific backup
1212 strategy options in details.
1214 A.1. LFA-based BIER-FRR using Single BIFT
1216 In the LFA-based BIER-FRR using single BIFT, every BFR has a single
1217 BIFT for a level of protection. Its structure is the same as the one
1218 in Figure 1.
1220 The following presents the details in BFR B1 in Figure 2 for building
1221 the BIFT for BIER-FRR link protection.
1223 At first, BFR B1 obtains a BIER-LFA as BBFR-NBR for each BFER. B6 is
1224 normal BIER-LFA as BBFR-NBR for BFER B2 and B3. B2 is normal BIER-
1225 LFA as BBFR-NBR for BFER B4, B5, B6 and B7. Figure 12 illustrates
1226 B1's intermediate BIFT for link protection filled with values for
1227 BBFR-NBRs and BFAs.
1229 +------+---------+-------+----------+--------+----------+---+
1230 |BFR-id| F-BM |BFR-NBR| BF-BM |BBFR-NBR| BFA |BEA|
1231 +======+=========+=======+==========+========+==========+===+
1232 | 2 | 0000110 | B2 | | B6 | Plain | |
1233 +------+---------+-------+----------+--------+----------+---+
1234 | 3 | 0000110 | B2 | | B6 | Plain | |
1235 +------+---------+-------+----------+--------+----------+---+
1236 | 4 | 1111000 | B6 | | B2 | Plain | |
1237 +------+---------+-------+----------+--------+----------+---+
1238 | 5 | 1111000 | B6 | | B2 | Plain | |
1239 +------+---------+-------+----------+--------+----------+---+
1240 | 6 | 1111000 | B6 | | B2 | Plain | |
1241 +------+---------+-------+----------+--------+----------+---+
1242 | 7 | 1111000 | B6 | | B2 | Plain | |
1243 +------+---------+-------+----------+--------+----------+---+
1245 Figure 12: B1's intermediate BIFT for link protection.
1247 From the intermediate BIFT, BFERs B2 and B3 have the same BFR-NBR B2
1248 and BBFR-NBR B6, BFERs B4 to B7 have the same BFR-NBR B6 as the BBFR-
1249 NBR B6 for BFER B2. According to Section 3.4, the BF-BM for BFER B2
1250 has the bits for B2 and B3 as well as the bits for B4 to B7, which is
1251 1111110. The BF-BM for BFER B3 is also 1111110. Similarly, the BF-
1252 BM for each of BFERs B3 to B7 is computed, which is 1111110.
1254 With the BF-BMs, BFR B1 has the BIFT for link protection, which is
1255 illustrated in Figure 13.
1257 +------+---------+-------+----------+--------+----------+---+
1258 |BFR-id| F-BM |BFR-NBR| BF-BM |BBFR-NBR| BFA |BEA|
1259 +======+=========+=======+==========+========+==========+===+
1260 | 2 | 0000110 | B2 | 1111110 | B6 | Plain | |
1261 +------+---------+-------+----------+--------+----------+---+
1262 | 3 | 0000110 | B2 | 1111110 | B6 | Plain | |
1263 +------+---------+-------+----------+--------+----------+---+
1264 | 4 | 1111000 | B6 | 1111110 | B2 | Plain | |
1265 +------+---------+-------+----------+--------+----------+---+
1266 | 5 | 1111000 | B6 | 1111110 | B2 | Plain | |
1267 +------+---------+-------+----------+--------+----------+---+
1268 | 6 | 1111000 | B6 | 1111110 | B2 | Plain | |
1269 +------+---------+-------+----------+--------+----------+---+
1270 | 7 | 1111000 | B6 | 1111110 | B2 | Plain | |
1271 +------+---------+-------+----------+--------+----------+---+
1273 Figure 13: B1's BIFT for BIER-FRR link protection.
1275 A.2. LFA-based BIER-FRR using Multiple Backup BIFTs
1277 For the LFA-based BIER-FRR using multiple backup BIFTs, in addition
1278 to a primary BIFT, a BFR has a backup BIFT for each of its BFR-NBRs
1279 with a level of protection. The backup BIFT for BFR-NBR N with link
1280 protection (or simply called the backup BIFT for link to N) assumes
1281 that the link to N failed. The BFR uses it to protect against the
1282 failure of its link to N. The backup BIFT for N with node protection
1283 (or simply called the backup BIFT for N) assumes that node N failed.
1284 The BFR uses it to protect against the failure of N. Once the BFR as
1285 a PLR detects the failure of its link to N, it uses the backup BIFT
1286 for link to N to forward all BIER packets. When the BFR as a PLR
1287 detects the failure of its BFR-NBR N, it uses the backup BIFT for N
1288 to forward all BIER packets.
1290 Even though a BFR has multiple backup BIFTs, the LFA-based BIER-FRR
1291 using multiple backup BIFTs is scalable. Both the size of a backup
1292 BIFT and the number of backup BIFTs on the BFR are small. Assume a
1293 BIER network has 1000 BFRs and 100 BFERs, and each BFR has 10 BFR-
1294 NBRs on average. The size of a backup BIFT is 100 forwarding
1295 entries. The number of backup BIFTs on the BFR is 20 on average.
1296 The total size of all backup BIFTs is 100*20 = 2000 forwarding
1297 entries.
1299 The following presents the details in BFR B1 in Figure 2 for building
1300 the backup BIFT for link to B2 to support BIER-FRR link protection.
1302 To support link protection, BFR B1 in Figure 2 has two backup BIFTs:
1303 one for link to B2 and the other for link to B6. The backup BIFT for
1304 link to B2 is illustrated in Figure 14.
1306 +--------+---------+---------+-----------------+-----------------+
1307 | BFR-id | F-BM | BFR-NBR |Forwarding Action|Comment: protects|
1308 | | | | | failure of |
1309 +========+=========+=========+=================+=================+
1310 | 2 | 1111110 | B6 | Plain | Link B1->B2 |
1311 +--------+---------+---------+-----------------+-----------------+
1312 | 3 | 1111110 | B6 | Plain | Link B1->B2 |
1313 +--------+---------+---------+-----------------+-----------------+
1314 | 4 | 1111110 | B6 | Plain | |
1315 +--------+---------+---------+-----------------+-----------------+
1316 | 5 | 1111110 | B6 | Plain | |
1317 +--------+---------+---------+-----------------+-----------------+
1318 | 6 | 1111110 | B6 | Plain | |
1319 +--------+---------+---------+-----------------+-----------------+
1320 | 7 | 1111110 | B6 | Plain | |
1321 +--------+---------+---------+-----------------+-----------------+
1322 Figure 14: B1's backup BIFT for link to B2.
1324 BFR B1 builds the backup BIFT for link to B2 in two steps. In the
1325 first step, it builds the backup BIRT for link to B2 through copying
1326 its regular BIRT to the backup BIRT and then changing BFR-NBR B2 in
1327 the backup BIRT to a backup BFR-NBR to protect against the failure of
1328 the link to B2. The backup BIRT for link to B2 built by B1 is
1329 illustrated in Figure 15.
1331 +------+-------------+---------+-----------------+-----------------+
1332 |BFR-id|BFER's Prefix| BFR-NBR |Forwarding Action|Comment: protects|
1333 | | | | | failure of |
1334 +======+=============+=========+=================+=================+
1335 | 2 | B2 | B6 | Plain | Link B1->B2 |
1336 +------+-------------+---------+-----------------+-----------------+
1337 | 3 | B3 | B6 | Plain | Link B1->B2 |
1338 +------+-------------+---------+-----------------+-----------------+
1339 | 4 | B4 | B6 | Plain | |
1340 +------+-------------+---------+-----------------+-----------------+
1341 | 5 | B5 | B6 | Plain | |
1342 +------+-------------+---------+-----------------+-----------------+
1343 | 6 | B6 | B6 | Plain | |
1344 +------+-------------+---------+-----------------+-----------------+
1345 | 7 | B7 | B6 | Plain | |
1346 +------+-------------+---------+-----------------+-----------------+
1348 Figure 15: B1's backup BIRT for link to B2.
1350 The BFR-NBR in each of the first two routing entries with BFR-NBR B2
1351 originally from the BIRT is changed to its corresponding backup BFR-
1352 NBR. The BFR-NBR B2 in the first entry is changed to backup BFR-NBR
1353 BIER-LFA B6. The BFR-NBR B2 in the second entry is changed to backup
1354 BFR-NBR BIER-LFA B6.
1356 In the second step, BFR B1 derives the backup BIFT for link to B2
1357 from the backup BIRT for link to B2 in the same way as it derives its
1358 regular BIFT from its BIRT defined in [RFC8279]. The result of the
1359 backup BIFT for link to B2 is the one shown in Figure 14.
1361 When BFR B1 as a PLR detects the failure of its link to B2, it
1362 forwards all the BIER packets using the FRR-BIFT for link to B2.
1363 There is no redundant packet. For example, for a BIER packet with
1364 destinations B2 and B6 (i.e., bitstring 0100010), BFR B1 sends a
1365 single packet copy on the link to B6 using the backup BIFT for link
1366 to B2 after detecting the failure of its link to B2. It will not
1367 send any copy of the packet to B6 again since the bitstring in the
1368 packet will be all cleaned by the F-BM 1111110 after sending the
1369 packet to B6 via its link to B6. Similarly, for a BIER packet with
1370 destinations B2, B5 and B7 (i.e., bitstring 1010010), BFR B1 sends a
1371 single packet copy on its link to B6 using the backup BIFT for link
1372 to B2 after detecting the failure of its link to B2.
1374 Acknowledgments
1376 The authors would like to thank Daniel Merling, Jeffrey Zhang, Tony
1377 Przygienda and Shaofu Peng for their comments to this work. A
1378 special thank you to Gunter van de Velde for his extensive editing to
1379 help bring this document to publication.
1381 Contributors
1383 Yisong Liu
1384 China Mobile
1385 Email: liuyisong@chinamobile.com
1387 Yanhe Fan
1388 Casa Systems
1389 United States of America
1390 Email: yfan@casa-systems.com
1392 Lei Liu
1393 Fujitsu
1394 United States of America
1395 Email: liulei.kddi@gmail.com
1397 Xufeng Liu
1398 Alef Edge
1399 United States of America
1400 Email: xufeng.liu.ietf@gmail.com
1402 Xuesong Geng
1403 China
1404 Email: gengxuesong@huawei.com
1406 Authors' Addresses
1408 Huaimo Chen (editor)
1409 Futurewei
1410 Boston, MA,
1411 United States of America
1412 Email: hchen.ietf@gmail.com
1414 Mike McBride
1415 Futurewei
1416 Email: michael.mcbride@futurewei.com
1418 Steffen Lindner
1419 University of Tuebingen
1420 Email: steffen.lindner@uni-tuebingen.de
1422 Michael Menth
1423 University of Tuebingen
1424 Email: menth@uni-tuebingen.de
1426 Aijun Wang
1427 China Telecom
1428 Beiqijia Town, Changping District
1429 Beijing
1430 102209
1431 China
1432 Email: wangaj3@chinatelecom.cn
1434 Gyan S. Mishra
1435 Verizon Inc.
1436 13101 Columbia Pike
1437 Silver Spring, MD 20904
1438 United States of America
1439 Phone: 301 502-1347
1440 Email: gyan.s.mishra@verizon.com