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