Early Review of draft-ietf-rtgwg-bgp-pic-23
review-ietf-rtgwg-bgp-pic-23-bgpdir-early-robert-2026-07-11-00
| Request | Review of | draft-ietf-rtgwg-bgp-pic |
|---|---|---|
| Requested revision | No specific revision (document currently at 23) | |
| Type | Early Review | |
| Team | BGP Directorate (bgpdir) | |
| Deadline | 2026-06-15 | |
| Requested | 2026-04-09 | |
| Requested by | Yingzhen Qu | |
| Authors | Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra , Yingzhen Qu | |
| I-D last updated | 2026-02-15 (Latest revision 2026-02-15) | |
| Completed reviews |
Rtgdir Early review of -00
by Bruno Decraene
(diff)
Secdir IETF Last Call review of -12 by Tero Kivinen (diff) Genart IETF Last Call review of -12 by Reese Enghardt (diff) Iotdir IETF Last Call review of -12 by Ines Robles (diff) Rtgdir IETF Last Call review of -12 by Bruno Decraene (diff) Tsvart IETF Last Call review of -12 by Brian Trammell (diff) Bgpdir Early review of -23 by Robert Raszuk |
|
| Comments |
The draft focus on BGP-PIC, although PIC is applicable to both BGP and IGPs. We need a BGP expert review to make sure the descriptions are accurate and clear, especially the terminologies. |
|
| Assignment | Reviewer | Robert Raszuk |
| State | Completed | |
| Request | Early review on draft-ietf-rtgwg-bgp-pic by BGP Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/bgpdir/xs9OMO6NL-Apr9s7e5DqcgXn97k | |
| Reviewed revision | 23 | |
| Result | Almost ready | |
| Completed | 2026-07-11 |
review-ietf-rtgwg-bgp-pic-23-bgpdir-early-robert-2026-07-11-00
1 2 3 4 5 Routing Area A. Bashandy, Ed. 6 Internet-Draft HPE 7 Intended status: Informational C. Filsfils 8 Expires: 19 August 2026 Cisco Systems 9 P. Mohapatra 10 Sproute Networks 11 Y. Qu, Ed. 12 Futurewei Technologies 13 15 February 2026 14 15 16 BGP Prefix Independent Convergence 17 draft-ietf-rtgwg-bgp-pic-23 18 19 Abstract 20 21 In a network comprising thousands of BGP peers exchanging millions of 22 routes, it is desirable to restore traffic after failure in a time 23 period that does not depend on the number of BGP prefixes. 24 25 This document describes an architecture by which traffic can be re- 26 routed to Equal Cost Multi-Path (ECMP) or pre-calculated backup paths 27 in a timeframe that does not depend on the number of BGP prefixes. 28 The objective is achieved through organizing the forwarding data 29 structures in a hierarchical manner and sharing forwarding elements 30 among the maximum possible number of routes. The described technique 31 yields prefix independent convergence while ensuring incremental 32 deployment, complete automation, and zero management and provisioning 33 effort. It is noteworthy to mention that the benefits of BGP Prefix 34 Independent Convergence (BGP-PIC) are hinged on the existence of more 35 than one path whether as ECMP or primary-backup. I would suggest to consider to rephrase the above to allow PIC to work in more then listed about two scenarios (ECMP or primary-backup). For example Unequal Cost Load Balancing is safe and getting popularity in network which use end to end encapsulation. I see no reason why PIC would not be applicable in such scenarios (especially when used with EPE). 36 37 Status of This Memo 38 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 41 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 51 52 This Internet-Draft will expire on 19 August 2026. 53 54 55 56 Bashandy, et al. Expires 19 August 2026 [Page 1] 57 58 Internet-Draft BGP Prefix Independent Convergence February 2026 59 60 61 Copyright Notice 62 63 Copyright (c) 2026 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 65 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised BSD License. 74 75 Table of Contents 76 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2.1. Dependency . . . . . . . . . . . . . . . . . . . . . . . 6 81 2.1.1. Hierarchical Hardware FIB (Forwarding Information 82 Base) . . . . . . . . . . . . . . . . . . . . . . . . 6 83 2.1.2. Availability of Precomputed Backup Paths . . . . . . 6 84 2.2. BGP-PIC Illustration . . . . . . . . . . . . . . . . . . 7 85 3. Constructing the Shared Hierarchical Forwarding Chain . . . . 9 86 3.1. Constructing the BGP-PIC Forwarding Chain . . . . . . . . 10 87 3.2. Example: Primary-Backup path Scenario . . . . . . . . . . 10 88 4. Forwarding Behavior . . . . . . . . . . . . . . . . . . . . . 11 89 5. Handling Platforms with Limited Levels of Hierarchy . . . . . 13 90 6. Forwarding Chain Adjustment at a Failure . . . . . . . . . . 13 91 6.1. BGP-PIC core . . . . . . . . . . . . . . . . . . . . . . 13 92 6.2. BGP-PIC edge . . . . . . . . . . . . . . . . . . . . . . 14 93 6.2.1. Adjusting Forwarding Chain in egress node failure . . 14 94 6.2.2. Adjusting Forwarding Chain on PE-CE link Failure . . 15 95 6.3. Handling Failures for Flattened Forwarding Chains . . . . 16 96 7. Operational Properties . . . . . . . . . . . . . . . . . . . 17 97 7.1. Failure Coverage . . . . . . . . . . . . . . . . . . . . 17 98 7.2. Convergence Characteristics . . . . . . . . . . . . . . . 18 99 7.3. Fast Local Repair . . . . . . . . . . . . . . . . . . . . 18 100 7.4. Configuration Free . . . . . . . . . . . . . . . . . . . 18 101 7.5. Incremental Deployment . . . . . . . . . . . . . . . . . 18 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 106 10.2. Informative References . . . . . . . . . . . . . . . . . 19 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21 108 109 110 111 112 Bashandy, et al. Expires 19 August 2026 [Page 2] 113 114 Internet-Draft BGP Prefix Independent Convergence February 2026 115 116 117 Appendix B. Handling Platforms with Limited Levels of 118 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 21 119 Appendix C. Example: Flattening a forwarding chain. . . . . . . 23 120 Appendix D. Perspective . . . . . . . . . . . . . . . . . . . . 30 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 122 123 1. Introduction 124 125 BGP speakers exchange reachability information about prefixes 126 [RFC4271]. For labeled address families, an edge router assigns 127 local labels to prefixes and associates the local label with each 128 advertised prefix using technologies such as L3VPN [RFC4364], 6PE 129 [RFC4798], and Softwire [RFC5565] using BGP label unicast (BGP-LU) 130 technique [RFC8277]. A BGP speaker then applies the path selection 131 steps to choose the best route. We run best path selection to choose best path for a given route. In modern networks, it is not 132 uncommon to have a prefix reachable via multiple edge routers. 133 Multiple techniques have been described to allow for BGP to advertise 134 more than one path for a given prefix 135 [I-D.ietf-idr-best-external][RFC7911][RFC6774], whether in the form 136 of equal cost multipath or primary-backup. Another common and widely I would just skip this "equal cost". Besides when advertising paths it is irrelevant how they are going to be used. 137 deployed scenario is L3VPN with multi-homed VPN sites with unique 138 Route Distinguisher. s/Distinguisher/Distinguishers/. /* we are talking about multiple sites */ 139 140 This document describes a hierarchical and shared forwarding chain 141 organization that allows traffic to be restored to a pre-calculated 142 alternative equal cost path or backup path in a time period that does Again "equal cost" ... I will suppress further comments about it, but if author decide to fix this please do so in the entire document. 143 not depend on the number of BGP prefixes. The technique relies on 144 internal router behavior that is completely transparent to the 145 operator and can be incrementally deployed and enabled with zero 146 operator intervention. In other words, once it is implemented and 147 deployed on a router, nothing is required from the operator to make 148 it work. It is noteworthy to mention that this document describes a 149 Forwarding Information Base (FIB) architecture that can be 150 implemented in both hardware and/or software, although we refer to 151 hardware implementation in most of the cases because of the 152 additional complexity and performance requirements associated with 153 hardware implementations. 154 155 It should be noted that although BGP is used for routes calculation 156 in this document, the underlying principles of hierarchical 157 forwarding, recursive resolution are not BGP specific. These 158 mechanisms apply equally to routes computed by other routing 159 protocols as well. The benefits of BGP-PIC are tied to the 160 forwarding plane design rather than to the BGP protocol. 161 162 163 164 165 166 167 168 Bashandy, et al. Expires 19 August 2026 [Page 3] 169 170 Internet-Draft BGP Prefix Independent Convergence February 2026 171 172 173 1.1. Terminology 174 175 This section defines the terms used in this document. 176 177 * BGP-LU: BGP Label Unicast. Refers to using BGP to advertise the 178 binding of an address prefix to one or more MPLS labels as in 179 [RFC8277]. 180 181 * BGP prefix: A set of destination as an IP prefix with route 182 learned through BGP as described in [RFC4271]. 183 184 * IGP prefix: A prefix that is learned via an Interior Gateway 185 Protocol (IGP), such as OSPF and IS-IS. 186 187 * ePE: Egress PE [RFC4364]. 188 189 * iPE: Ingress PE [RFC4364]. 190 191 * Path: One specific candidate way to reach the destination in a 192 route [RFC4271]. It's a sequence of nodes or links from the 193 source to the destination. The nodes may not be directly 194 connected. Well that is wrong definition of path from BGP POV. There is no sequence of nodes and links in BGP path. That comes from IGP-PATH. BGP Path just prvides BGP Next-Hop. 195 196 * Recursive path: The next-hop of a path is an IP without the 197 outgoing interface. it requires the router to look up the next-hop 198 IP in the routing table (recursion) until it finds a directly 199 connected or attached next-hop. Warning: Terminology overload. Here we are talking about IGP/underlay next-hop and not BGP next-hop. I think it may be useful to differentiate those two if by no other means maybe by the way we type them ... BGP NEXT_HOP vs IGP/underlay next-hop ? 200 201 * Non-recursive path: A path consisting of the IP address of a 202 directly connected next-hop and outgoing interface. 203 204 * Adjacency: The layer 2 encapsulation leading to the layer 3 205 directly connected next-hop. An adjacency is identified by a 206 next-hop and an outgoing interface 207 208 * Primary path: A recursive or non-recursive path that can be used 209 for forwarding. A prefix can have more than one primary path. 210 211 * Backup path: A recursive or non-recursive path that can be used 212 only after some or all primary paths become unreachable. 213 214 * Leaf: A container data structure for a prefix or local label. 215 Alternatively, it is the data structure that contains prefix 216 specific information. 217 218 * IP leaf: The leaf corresponding to an IPv4 or IPv6 prefix. 219 220 221 222 223 224 Bashandy, et al. Expires 19 August 2026 [Page 4] 225 226 Internet-Draft BGP Prefix Independent Convergence February 2026 227 228 229 * Label leaf. The leaf corresponding to a locally allocated label 230 such as the VPN label on an egress PE [RFC4364]. 231 232 * Pathlist: An array of paths used by one or more prefixes to 233 forward traffic to destination(s) covered by an IP prefix. Each 234 path in the pathlist carries its "path-index" that identifies its 235 position in the array of paths. In general the value of the path- 236 index in a path is the same as its position in the pathlist, 237 except in the case outlined in Section 5. For example the 3rd 238 path may carry a path-index value of 1. A pathlist may contain a 239 mix of primary and backup paths. 240 241 * OutLabel-List: Each labeled prefix is associated with an OutLabel- 242 List. The OutLabel-List is an array of one or more outgoing 243 labels and/or label actions where each label or label action has 244 1-to-1 correspondence to a path in the pathlist. Label actions 245 are: push (add) the label as specified in [RFC3031], pop (remove) 246 the label as specified in [RFC3031], swap (replace) the incoming 247 label with the label in the OutLabel-List entry, or don't push 248 anything at all in case of "unlabeled". The prefix may be an IGP 249 or BGP prefix. 250 251 * Forwarding chain: It is a compound data structure consisting of 252 multiple connected blocks that a forwarding engine walks one block 253 at a time to forward the packet out of an interface. Section 2.2 254 explains an example of a forwarding chain. Subsequent sections 255 provide additional examples 256 257 * Dependency: An object X is said to be a dependent or child of 258 object Y if there is at least one forwarding chain where the 259 forwarding engine must visit the object X before visiting the 260 object Y in order to forward a packet. Note that if object X is a 261 child of object Y, then Y cannot be deleted unless object X is no 262 longer a dependent/child of object Y. 263 264 * ASN: Autonomous System Number. 265 266 2. Overview 267 268 The idea of BGP-PIC is based on the following two pillars to make 269 convergence independent of the number of prefixes: 270 271 * A shared hierarchical forwarding chain: Multiple prefixes 272 reference common next-hop and path objects arranged in a See here reader is not sure if you are talking about BGP NEXT_HOP or IGP next-hop ? I am not even going here into recent "modern" DC networks where BGP is used as IGP. 273 hierarchy, so that changes to a single shared object affect all 274 dependent prefixes simultaneously. 275 276 277 278 279 280 Bashandy, et al. Expires 19 August 2026 [Page 5] 281 282 Internet-Draft BGP Prefix Independent Convergence February 2026 283 284 285 * A forwarding plane with multiple levels of indirection: The 286 forwarding plane supports recursive resolution and pointer-based 287 forwarding entries, allowing failover by updating a small number 288 of shared objects rather than per-prefix state. 289 290 A forwarding plane with shared, hierarchical forwarding chains with 291 maximal object reuse can reroute a large number of destinations by 292 modifying only a small set of shared objects. This enables 293 convergence in a time frame that does not depend on the number of 294 affected destinations. For example, if an IGP prefix used to resolve 295 a recursive next-hop changes, there is no need to update the 296 potentially large number of BGP NLRIs that reference that next-hop. 297 298 2.1. Dependency 299 300 This section describes the required functionalities in the forwarding 301 and control planes to support BGP-PIC as described in this document. 302 303 2.1.1. Hierarchical Hardware FIB (Forwarding Information Base) 304 305 BGP-PIC requires forwarding hardware that supports a hierarchical 306 FIB. When a packet’s destination address matches a BGP prefix, the 307 forwarding plane performs recursive lookups through successive levels 308 of indirection until a resolving adjacency is reached. Section 4 309 provides further details on the packet forwarding process. 310 311 For platforms that support only a limited number of levels of 312 indirection, a necessary trad-off approach is to flatten forwarding 313 dependencies when programming BGP destinations into the hardware FIB. 314 In this case, recursive resolution is resolved at programming time, 315 potentially eliminating both BGP pathlist and IGP pathlist lookups 316 during forwarding. 317 318 While flattening reduces the number of memory accesses per packet, it 319 comes at the cost of increased hardware FIB memory usage as 320 flattening reduces sharing and results in greater duplication of 321 forwarding entries, reduced ECMP and BGP-PIC properties as fewer 322 pathlists are available. 323 324 Appendix B describes the flattening approach in more detail for 325 hardware platforms with a limited number of supported indirection 326 levels. 327 328 2.1.2. Availability of Precomputed Backup Paths 329 330 BGP-PIC requires backup paths so that traffic can be immediately 331 redirected in the forwarding plane when a next hop fails, without 332 reprocessing individual BGP prefixes. Here again we need to be more explicit if this is talking about BGP NEXT_HOP or IGP next hop or both (as trigger may be comming actually from both). 333 334 335 336 Bashandy, et al. Expires 19 August 2026 [Page 6] 337 338 Internet-Draft BGP Prefix Independent Convergence February 2026 339 340 341 Backup paths are calculated before any failure and installed in the 342 FIB along with the primary path. Because many prefixes share the 343 same next hop, a failure only requires switching that next hop to its 344 back. Presumably it talks about BGP NEXT_HOPs. s/back./backup./ I think it would be good to upfront mention here the grouping of routes which share Primary BGP NEXT-HOP and backup NEXT_HOP - as those associations can really benefit from single switchover benefit. 345 346 The BGP distribution of multiple paths is available thanks to the 347 following BGP mechanisms: Add-Path [RFC7911], BGP Best-External 348 [I.D.ietf-idr-best-external], diverse path [RFC6774], and the s/diverse path/Diverse Path/ 349 frequent use in VPN deployments of different VPN RD's per PE. 350 Another option to learn multiple BGP next-hops/paths is to receive 351 IBGP paths from multiple BGP RRs [RFC9107] selecting a different path 352 as best. But lines 350-352 describe precisely how Diverse Path operates - so can not be said "Another option" just after mentioning RFC6774 :) It is noteworthy to mention that the availability of 353 another BGP path does not mean that all failure scenarios can be 354 covered by simply forwarding traffic to the available secondary path. 355 The discussion of how to cover various failure scenarios is beyond 356 the scope of this document. 357 358 2.2. BGP-PIC Illustration 359 360 To illustrate the two pillars above as well as the platform 361 dependency, this document will use an example of a multihomed L3VPN 362 prefix in a BGP-free core running LDP [RFC5036] or segment routing 363 over MPLS forwarding plane [RFC8660]. Is there any specific reason not to mention here SRv6 core ? 364 365 +--------------------------------+ 366 | | 367 | ePE2 (IGP-IP1 192.0.2.1, Loopback) 368 | | \ 369 | | \ 370 | | \ 371 iPE | CE....VRF "Blue", ASN 65000 372 | | / (VPN-IP1 198.51.100.0/24) 373 | | / (VPN-IP2 203.0.113.0/24) 374 | LDP/Segment-Routing Core | / 375 | ePE1 (IGP-IP2 192.0.2.2, Loopback) 376 | | 377 +--------------------------------+ 378 Figure 1: VPN prefix reachable via multiple PEs Would you consider upgrading the picture to SVG as per RFC9896 ? 379 380 Referring to Figure 1, suppose the iPE (the ingress PE) receives 381 NLRIs for the VPN prefixes VPN-IP1 and VPN-IP2 from two egress PEs, 382 ePE1 and ePE2 with next-hop BGP-NH1 (192.0.2.1) and BGP-NH2 383 (192.0.2.2), respectively. Assume that ePE1 advertise the VPN labels 384 VPN-L11 and VPN-L12 while ePE2 advertise the VPN labels VPN-L21 and 385 VPN-L22 for VPN-IP1 and VPN-IP2, respectively. Suppose that BGP-NH1 386 and BGP-NH2 are resolved via the IGP prefixes IGP-IP1 and IGP-IP2, 387 where each happen to have 2 equal cost paths with IGP-NH1 and IGP- 388 NH2 reachable via the interfaces I1 and I2 on iPE, respectively. Well on iPE the interfaces do not need to be unique and separate (I1, I2) ... The reason I am mentioning this is that reader should not have an impression that if to both ePEs packets leave over single interface I3 the BGP-PIC would work any differently nor worse. 389 390 391 392 Bashandy, et al. Expires 19 August 2026 [Page 7] 393 394 Internet-Draft BGP Prefix Independent Convergence February 2026 395 396 397 Suppose that local labels (whether LDP [RFC5036] or segment routing 398 [RFC8660]) + or service SID as defined in [RFC9252] ? on the downstream LSRs for IGP-IP1 are IGP-L11 and IGP- 399 L12 while for IGP-IP2 are IGP-L21 and IGP-L22. As such, the pic- 400 routing table at iPE is as follows: 401 402 65000: 198.51.100.0/24 403 via ePE1 (192.0.2.1), VPN Label: VPN-L11 404 via ePE2 (192.0.2.2), VPN Label: VPN-L21 405 406 65000: 203.0.113.0/24 407 via ePE1 (192.0.2.1), VPN Label: VPN-L12 408 via ePE2 (192.0.2.2), VPN Label: VPN-L22 409 410 192.0.2.1/32 (ePE2) 411 via I1, Label: IGP-L11 via I2, Label: IGP-L12 412 413 192.0.2.2/32 (ePE1) 414 via I1, Label: IGP-L21 via I2, Label: IGP-L22 415 416 Based on the above pic-routing-table, a hierarchical forwarding chain 417 can be constructed as shown in Figure 2. 418 419 IP Leaf: pathlist: IP Leaf: pathlist: 420 -------- +-----------+ -------- 421 | | +-------------+ 422 |BGP-NH1------->IGP-IP1 ----->| | 423 VPN-IP1-->| | | | IGP-NH1,I1----->adjacency1 424 | |BGP-NH2------->... | | | 425 | | | | | IGP-NH2,I2----->adjacency2 426 | +-----------+ | | | 427 | | +-------------+ 428 | | 429 v v 430 OutLabel-List: OutLabel-List: 431 +--------+ +--------+ 432 |VPN-L11 | |IGP-L11 | 433 |VPN-L21 | |IGP-L12 | 434 +--------+ +--------+ 435 436 Figure 1: Shared Hierarchical Forwarding Chain at iPE Wrong Figure number ... we already have had Figure 1. Would you consider upgrading the picture to SVG as per RFC9896 ? 437 438 The forwarding chain depicted in Figure 2 illustrates the first 439 pillar, which is sharing and hierarchy. It can be seen that the BGP 440 pathlist consisting of BGP-NH1 and BGP-NH2 is shared by all NLRIs While I know what you are saying the more intuitve would be to s/NLRIs/routes/ here. Picture does not contain term NLRI. NLRI term is only applicable when we are discussing MP_REACH_NLRI attribute. Here this is no longer BGP ... but FIB. There are routes, next-hops, labels, pathlists, pointers and paths there ... Moreover Terminology section does not define what is NLRI :) 441 reachable via ePE1 and ePE2. As such, it is possible to make changes 442 to the pathlist without having to make changes to the NLRIs. s/NLRIs/VPN routes/ For 443 example, if BGP-NH2 becomes unreachable, there is no need to modify 444 any of the possibly large number of NLRIs. Instead only the shared s/NLRIs/VPN routes/ Again I stop making any further corrections where NLRI is used as route or route + label, but if authors decided to fix it pls do so in entire doc. 445 446 447 448 Bashandy, et al. Expires 19 August 2026 [Page 8] 449 450 Internet-Draft BGP Prefix Independent Convergence February 2026 451 452 453 pathlist needs to be modified. Likewise, due to the hierarchical 454 structure of the forwarding chain, it is possible to make 455 modifications to the IGP routes without having to make any changes to 456 the BGP NLRIs. For example, if the interface "I2" goes down, only 457 the shared IGP pathlist needs to be updated, but none of the IGP 458 prefixes sharing the IGP pathlist nor the BGP NLRIs using the IGP 459 prefixes for resolution need to be modified. Well this draft is talking about BGP-PIC. Failover of I2 to I1 is an IGP local repair. It is perhaps cool to keep it to highlight the benefits of FIB hierarchy, but I would recommend to frame it correctly so reader is less confused how failure of I2 is related to BGP PIC. 460 461 Figure 2 can also be used to illustrate the second BGP-PIC pillar. 462 Having a deep forwarding chain such as the one illustrated in 463 Figure 2 requires a forwarding plane that is capable of accessing 464 multiple levels of indirection in order to calculate the outgoing 465 interface(s) and next-hops(s). While a deeper forwarding chain 466 minimizes the re-convergence time on topology change, there will 467 always exist platforms with limited capabilities and hence imposing a 468 limit on the depth of the forwarding chain. Section 5 describes how 469 to gracefully trade off convergence speed with the number of 470 hierarchical levels to support platforms with different capabilities. 471 472 Another example using IPv6 addresses can be something like the 473 following: 474 475 65000: 2001:DB8:1::/48 476 via ePE1 (65000: 2001:DB8:192::1), VPN Label: VPN6-L11 477 via ePE2 (65000: 2001:DB8:192::2), VPN Label: VPN6-L21 478 479 65000: 2001:DB8:2:/48 480 via ePE1 (65000: 2001:DB8:192::1), VPN Label: VPN6-L12 481 via ePE2 (65000: 2001:DB8:192::2), VPN Label: VPN6-L22 482 483 65000: 2001:DB8:192::1/128 484 via Core, Label: IGP6-L11 485 via Core, Label: IGP6-L12 486 487 65000: 2001:DB8:192::2/128 488 via Core, Label: IGP6-L21 489 via Core, Label: IGP6-L22 That illustration is incomplete. The underlay IGP labels are missing. Just like in the v4 case earlier: 410 192.0.2.1/32 (ePE2) 411 via I1, Label: IGP-L11 via I2, Label: IGP-L12 ^^^^^^^^^^^^^^ 412 413 192.0.2.2/32 (ePE1) 414 via I1, Label: IGP-L21 via I2, Label: IGP-L22 ^^^^^^^^^^^^^^ assuming we are still talking MPLS core. 490 491 492 The same hierarchical forwarding chain described can be constructed 493 for IPv6 addresses/prefixes. 494 495 3. Constructing the Shared Hierarchical Forwarding Chain 496 497 This section describes how the forwarding chain is constructed using 498 a hierarchical shared model, as introduced in Section 2. Section 3.1 499 details the construction steps, and Section 3.2 provides an 500 illustrative example. 501 502 503 504 Bashandy, et al. Expires 19 August 2026 [Page 9] 505 506 Internet-Draft BGP Prefix Independent Convergence February 2026 507 508 509 3.1. Constructing the BGP-PIC Forwarding Chain 510 511 The forwarding chain is built using the following steps: 512 513 (1) Prefix arrival in FIB. The prefix contains one or more outgoing 514 paths. For certain labeled prefixes, such as L3VPN [RFC4364] 515 prefixes, each path may be associated with an outgoing label and 516 the prefix itself may be assigned a local label. The list of s/local label./local vpn label on egress PE./ 517 outgoing paths defines a pathlist. 518 519 (2) Pathlist lookup/creation. If such pathlist does not already, 520 then the FIB manager (software or hardware entity responsible 521 for managing the FIB) creates a new pathlist, otherwise the 522 existing pathlist with the same list of paths exist (the 523 pathlist may already exist because there is another pic-route 524 that is already using the same list of paths) is used. 525 526 (3) Register prefix dependency. The BGP prefix is added as a 527 dependent of the pathlist. 528 529 (4) Resolve pathlist entries. The forwarding chain is completed by 530 resolving the paths of the pathlist. A BGP path usually 531 consists of a next-hop. The next-hop is resolved by finding a 532 matching prefix reachable via IGP or other protocols. s/A BGP path usually consists of a next-hop./A BGP path contains BGP NEXT-HOP/ BGP path does not usually have next hop ... it always have next hop. BGP path does not consists of only next-hop 533 534 The end result is a hierarchical shared forwarding chain where the 535 BGP pathlist is shared by all BGP prefixes that use the same list of 536 paths and the IGP prefix is shared by all pathlists that have a path 537 resolving via that IGP prefix. 538 539 3.2. Example: Primary-Backup path Scenario 540 541 Consider the egress PE ePE1 in the case of the multi-homed VPN 542 prefixes shown in Figure 1. Suppose ePE1 determines that the primary 543 path is the external path, while the backup path is the IBGP path to 544 the other PE ePE2 with next-hop BGP-NH2. ePE1 constructs the 545 forwarding chain depicted in Figure 3. The figure shows only a 546 single VPN prefix for simplicity. But all prefixes that are 547 multihomed to ePE1 and ePE2 share the BGP pathlist. 548 549 550 551 552 553 554 555 556 557 558 559 560 Bashandy, et al. Expires 19 August 2026 [Page 10] 561 562 Internet-Draft BGP Prefix Independent Convergence February 2026 563 564 565 BGP OutLabel-List 566 +---------+ 567 VPN-L11 |Unlabeled| 568 (Label-leaf)---+---->+---------+ 569 | | VPN-L21 | 570 v | (swap) | 571 | +---------+ 572 | 573 | 574 | 575 | 576 | BGP pathlist 577 | +--------------+ 578 | | | 579 | | CE-NH ------->(to the CE) 580 | | path-index=0 | 581 VPN-IP1 -----+------------------>+--------------+ 582 (IP leaf) | VPN-NH2 | 583 | | (backup) ------->IGP Leaf 584 | | path-index=1 | (Towards ePE2) 585 | +--------------+ 586 | 587 | BGP OutLabel-List 588 | +---------+ 589 | |Unlabeled| 590 +------------->+---------+ 591 | VPN-L21 | 592 | (push) | 593 +---------+ 594 595 Figure 2: VPN Prefix Forwarding Chain with eiBGP paths on egress PE Wrong Figure number ... should be Figure 3. Again pls consider switching to SVG. The picture is confusing ... it is correct but illustrates both per prefix VPN label (top OutLabel-List) and per VRF aggregate label (bottom OutLabel-List). I would recommend to edit it to remove the bottom BGP OutLable-List or if not then to add a description of both per prefix and aggregate labels to be present in the figure 3. 596 597 The example depicted in Figure 3 differs from the example in Figure 2 598 in two main aspects. First, as long as the primary path towards the 599 CE (external path) can be used for forwarding, it will be the only 600 path used for forwarding while the OutLabel- List contains both the 601 unlabeled (primary path) and the VPN label (backup path) advertised 602 by the backup path ePE2. The second aspect is presence of the label 603 leaf corresponding to the VPN prefix. This label leaf is used to 604 match VPN traffic arriving from the core. Note that the label leaf 605 shares the pathlist with the IP prefix. 606 607 4. Forwarding Behavior 608 609 This section explains how the forwarding plane uses the hierarchical 610 shared forwarding chain to forward a packet. 611 612 613 614 615 616 Bashandy, et al. Expires 19 August 2026 [Page 11] 617 618 Internet-Draft BGP Prefix Independent Convergence February 2026 619 620 621 When a packet arrives at a router, assume it matches a leaf. If not, "matches a leaf" is not clear which leaf ... Figure 1 in fact uses the exact same term "IP Leaf" to describe VPN route and IGP route ... 622 the packet is handled according to the local policy (such as silently 623 dropping the packet), which is beyond the scope of this document. A Not sure what this setence adds to the document except raises huge level of confusion. What policy ? why to drop the packet etc .... Recommend to remove it. This draft is not about life of a packet in the router :). 624 labeled packet matches a label leaf while an IP packet matches an IP 625 leaf. The forwarding engines walks the forwarding chain starting 626 from the leaf until the walk terminates on an adjacency. Thus when a 627 packet arrives, the chain is walked as follows: 628 629 1. Lookup the leaf based on the destination address or the label at 630 the top of the packet. 631 632 2. Retrieve the parent pathlist of the leaf. 633 634 3. Pick an outgoing path "Pi" from the list of resolved pic- paths 635 in the pathlist. The method by which the outgoing path is picked 636 is beyond the scope of this document (e.g. flow- preserving hash 637 exploiting entropy within the MPLS stack and IP header). Let the 638 "path-index" of the outgoing path "Pi" be "j". Remember that, as 639 described in the definition of the term pathlist in Section 1.1, 640 the path-index of a path may not always be identical the position 641 of the path in the pathlist. 642 643 4. If the prefix is labeled, use the "path-index" "j" to retrieve 644 the label "Lj" stored position j in the OutLabel-List and apply 645 the label action of the label on the packet (e.g. for VPN label 646 on the ingress PE, the label action is "push"). As mentioned in 647 Section 1.1 the value of the "path-index" stored in the pic- path "pic- " ? 648 may not necessarily be the same value of the location of the path 649 in the pathlist. 650 651 5. If the chosen path "Pi" is recursive, move to its parent prefix 652 and go to step 2. 653 654 6. If the chosen path is non-recursive move to its parent adjacency. 655 656 7. Encapsulate the packet in the layer string specified by the 657 adjacency and send the packet out. 658 659 Let's apply the above forwarding steps to the forwarding chain 660 depicted in Figure 2 in Section 2. Suppose a packet arrives at 661 ingress PE iPE from an external neighbor. Assume the packet matches 662 the VPN prefix VPN-IP1. While walking the forwarding chain, the 663 forwarding engine applies a hashing algorithm to choose the path and 664 the hashing at the BGP level chooses the first path in the BGP 665 pathlist while the hashing at the IGP level yields the second path in 666 the IGP pathlist. In that case, the packet will be sent out of 667 interface I2 with the label stack "IGP-L12,VPN-L11". 668 669 670 671 672 Bashandy, et al. Expires 19 August 2026 [Page 12] 673 674 Internet-Draft BGP Prefix Independent Convergence February 2026 675 676 677 5. Handling Platforms with Limited Levels of Hierarchy 678 679 This section describes the construction of the forwarding chain if a 680 platform does not support the number of recursion levels required to 681 resolve the NLRIs. There are two main design objectives. 682 683 * Being able to reduce the number of hierarchical levels from any 684 arbitrary value to a smaller arbitrary value that can be supported 685 by the forwarding engine. 686 687 * Minimal modifications to the forwarding algorithm due to such 688 reduction. 689 690 Appendix B provides details on how to handle limited hardware 691 692 capabilities. extra line 691 ? 693 694 6. Forwarding Chain Adjustment at a Failure 695 696 The hierarchical and shared structure of the forwarding chain 697 explained in the previous section allows modifying a small number of 698 forwarding chain objects to re-route traffic to a pre-calculated 699 equal-cost or backup path without the need to modify the possibly 700 very large number of BGP prefixes. This section goes over various 701 core and edge failure scenarios to illustrate how the FIB manager can 702 utilize the forwarding chain structure to achieve BGP prefix 703 independent convergence. 704 705 6.1. BGP-PIC core 706 707 This section describes the adjustments to the forwarding chain when a 708 core link or node fails but the BGP next-hop remains reachable. 709 710 There are two case: remote link failure and attached link failure. 711 Node failures are treated as link failures. 712 713 When a remote link or node fails, the IGP on the ingress PE receives 714 an advertisement indicating a topology change so IGP re-converges to 715 either find a new next-hop and/or outgoing interface or remove the 716 path completely from the IGP prefix used to resolve BGP next- hops. s/next- hops/next-hops/ or NEXT_HOPs. IMO if you are talking IGP reconvergence it should also be mentioned that IGP may use fast protection techniques FRR, LFA, TI-LFA and do not be subject to convergence. 717 IGP and/or LDP download the modified IGP leaves with modified 718 outgoing labels for the labeled core. 719 720 When a local link fails, FIB manager detects the failure almost 721 immediately. The FIB manager marks the impacted path(s) as unusable 722 so that only useable paths are used to forward packets. Hence only 723 IGP pathlists with paths using the failed local link need to be 724 modified. All other pathlists are not impacted. Note that in this 725 726 727 728 Bashandy, et al. Expires 19 August 2026 [Page 13] 729 730 Internet-Draft BGP Prefix Independent Convergence February 2026 731 732 733 particular case there is no need to backwalk (walk back the 734 forwarding chain) to IGP leaves to adjust the OutLabel-Lists because 735 FIB can rely on the path-index stored in the useable paths in the 736 pathlist to pick the right label. 737 738 It is noteworthy to mention that because FIB manager modifies the 739 forwarding chain starting from the IGP leaves only. BGP pathlists 740 and leaves are not modified. Hence traffic restoration occurs within 741 the time frame of IGP convergence, and, for local link failure, 742 assuming a backup path has been precomputed, within the timeframe of 743 local detection (e.g. 50ms). Examples of solutions that can pre- 744 compute backup paths are IP FRR [RFC5714] remote LFA [RFC7490], TI- 745 LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] and MRT [RFC7812] or EBGP 746 path having a backup path [bonaventure]. ok Here you mentioned it ... but it should said generally on top of BGP-PIC core that it depends on IGP convergence or protection. And list all options. As we are now in July 2026 we should update this draft to also inlcude UPA flooded trigger as this is already a standards track [RFC9929]. "IGP convergence" is no longer a single trigger for remote failure. 747 748 Let's apply the procedure mentioned in this subsection to the 749 forwarding chain depicted in Figure 2. Suppose a remote link failure 750 occurs and impacts the first ECMP IGP path to the remote BGP next- 751 hop. Upon IGP convergence, the IGP pathlist used by the BGP next-hop 752 is updated to reflect the new topology (one path instead of two) and 753 the new forwarding state is immediately available to all dependent 754 BGP prefixes. The same behavior would occur if the failure was local 755 such as an interface going down. As soon as the IGP convergence is 756 complete for the BGP next-hop IGP pic-route, all its BGP depending 757 routes benefit from the new pic- path. In fact, upon local failure, 758 if LFA protection is enabled for the IGP route to the BGP next-hop 759 and a backup path was pre- computed and installed in the pathlist, 760 upon the local interface failure, the LFA backup path is immediately 761 activated (e.g. sub- 50msec) and thus protection benefits all the 762 depending BGP traffic through the hierarchical forwarding dependency 763 between the routes. This entire section IMO deserves a rewrite. Not from BGP-PIC core but from IGP pov. IGP local protection/precomputed repairs should be a primary citizen not an add-on like this section seems to suggest. 764 765 6.2. BGP-PIC edge 766 767 This section describes the adjustments to the forwarding chains as a 768 result of edge node or edge link failure. 769 770 6.2.1. Adjusting Forwarding Chain in egress node failure 771 772 When a node fails, IGP on neighboring core nodes send updates 773 indicating that the edge node is no longer a direct neighbor. If the 774 node that failed is an egress node, such as ePE1 and ePE2 in 775 Figure 1, IGP running on an ingress node, such as iPE in Figure 1, 776 converges and the realizes that the egress node is no longer 777 reachable. As such IGP on the ingress node instructs FIB to remove 778 the IP and label leaves corresponding to the failed edge node from 779 FIB. So FIB manager on the ingress node performs the following 780 steps: 781 782 783 784 Bashandy, et al. Expires 19 August 2026 [Page 14] 785 786 Internet-Draft BGP Prefix Independent Convergence February 2026 787 788 789 * FIB manager deletes the IGP leaf corresponding to the failed edge 790 node 791 792 * FIB manager backwalks to all dependent BGP pathlists and marks 793 that path using the deleted IGP leaf as unresolved 794 795 * Note that there is no need to modify the possibly large number of 796 BGP leaves because each path in the pathlist carries its pic- path s/pic- path/pic-path/ ? 797 index and hence the correct outgoing label will be picked. 798 Consider for example the forwarding chain depicted in Figure 2. 799 If the 1st BGP path becomes unresolved, then the forwarding engine 800 will only use the second path for forwarding. Yet the path-index 801 of that single resolved path will still be 1 and hence the label 802 VPN-L21 will be pushed. 803 804 6.2.2. Adjusting Forwarding Chain on PE-CE link Failure 805 806 Suppose the link between an edge router and its external peer fails. 807 There are two scenarios (1) the edge node attached to the failed link 808 performs next-hop self (where BGP advertises the IP address of its 809 own loopback as next-hop) and (2) the edge node attached to the 810 failure advertises the IP address of the failed link as the next-hop 811 attribute to its IBGP peers. The entire document so far focused on using BGP as service overlay protocol. All figures and examples talk about use of VPN labels. In those cases BGP MUST set next-hop-self. So now the insert of BGP not setting next-hop self comes as a surprise ! Is it really talking about SAFI 1 now ? 812 813 In the first case, the rest of IBGP peers will remain unaware of the 814 link failure and will continue to forward traffic to the edge node 815 until the edge node attached to the failed link withdraws the BGP 816 prefixes. If the destination prefixes are multi-homed to another 817 IBGP peer, say ePE2, then FIB manager on the edge router detecting 818 the link failure applies the following steps to the forwarding chain 819 (see Figure 3): 820 821 * FIB manager backwalks to the BGP pathlists marks the path through 822 the failed link to the external peer as unresolved. 823 824 * Hence traffic will be forwarded using the backup path towards 825 ePE2. 826 827 * Labeled traffic arriving at the egress PE ePE1 matches the BGP 828 label leaf. 829 830 - The OutLabel-List attached to the BGP label leaf already 831 contains an entry corresponding to the backup path. 832 833 - The label entry in OutLabel-List corresponding to the internal 834 path to backup egress PE has a swap action to the label 835 advertised by the backup egress PE. 836 837 838 839 840 Bashandy, et al. Expires 19 August 2026 [Page 15] 841 842 Internet-Draft BGP Prefix Independent Convergence February 2026 843 844 845 - For an arriving label packet (e.g. VPN), the top label is 846 swapped with the label advertised by backup egress PE and the 847 packet is sent towards that the backup egress PE. 848 849 * Unlabeled traffic arriving at the egress PE ePE1 matches the BGP 850 IP leaf Unlabeled traffic arriving at the egress PE ePE1 ??? 851 852 - The OutLabel-List attached to the BGP label leaf already 853 contains an entry corresponding to the backup path. 854 855 - The label entry in OutLabel-List corresponding to the internal 856 path to backup egress PE has a push (instead of the swap action 857 in for the labeled traffic case) action to the label advertised 858 by the backup egress PE. 859 860 - For an arriving IP packet, the label advertised by backup 861 egress PE is pushed and the packet is sent towards that the 862 backup egress PE. 863 864 In the second case where the edge router uses the IP address of the 865 failed link as the BGP next-hop, the edge router will still perform 866 the previous steps. But, unlike the case of next-hop self, the IGP 867 on the failed edge node informs the rest of the IBGP peers that the 868 IP address of the failed link is no longer reachable. Hence the FIB 869 manager on IBGP peers will delete the IGP leaf corresponding to the 870 IP prefix of the failed link. The behavior of the IBGP peers will be 871 identical to the case of edge node failure outlined in Section 6.2.1. Well that requires flooding via entire domain rerunning SPF ... removal from RIB and FIB. Also for this to work link must be passive from IGP pov. Honestly I am not sure if this scenario needs to be described in this draft. 872 873 It is noteworthy to mention that because the edge link failure is 874 local to the edge router, sub-50 msec convergence can be achieved as 875 described in [bonaventure]. 876 877 Let's try to apply the case of next-hop self to the forwarding chain 878 depicted in Figure 3. After failure of the link between ePE1 and CE, 879 the forwarding engine will route traffic arriving from the core 880 towards VPN-NH2 with path-index=1. A packet arriving from the core 881 will contain the label VPN-L11 at top. The label VPN-L11 is swapped 882 with the label VPN-L21 and the packet is forwarded towards ePE2. 883 884 6.3. Handling Failures for Flattened Forwarding Chains 885 886 As explained in the in Section 5 if the number of hierarchy levels of 887 a platform cannot support the native number of hierarchy levels of a 888 recursive forwarding chain, the instantiated forwarding chain is 889 constructed by flattening two or more levels. Hence a 3-levels chain 890 in Figure 5 is flattened into the 2-levels chain in Figure 6. This document so far has 3 Figures. There is no Figure 5 nor 6. Appendix contains Figure 4 and 5 ... incorrectly numbered as figure 3 & 4. 891 892 893 894 895 896 Bashandy, et al. Expires 19 August 2026 [Page 16] 897 898 Internet-Draft BGP Prefix Independent Convergence February 2026 899 900 901 While reducing the benefits of BGP-PIC, flattening one hierarchy into 902 a shallower hierarchy does not always result in a complete loss of 903 the benefits of the BGP-PIC. To illustrate this fact suppose ASBR12 904 is no longer reachable in domain 1. If the platform supports the 905 full hierarchy depth, the forwarding chain is the one depicted in 906 Figure 5 and hence the FIB manager needs to backwalk one level to the Pls fix figure numbers. 907 pathlist shared by "ePE1" and "ePE2" and adjust it. If the platform 908 supports 2 levels of hierarchy, then a useable forwarding chain is 909 the one depicted in Figure 6. In that case, if ASBR12 is no longer Pls fix figure numbers. 910 reachable, the FIB manager has to backwalk to the two flattened 911 pathlists and updates both of them. 912 913 The main observation is that the loss of convergence speed due to the 914 loss of hierarchy depth depends on the structure of the forwarding 915 chain itself. To illustrate this fact, let's take two extremes. 916 Suppose the forwarding objects in level i+1 depend on the forwarding 917 objects in level i. If every object on level i+1 depends on a 918 separate object in level i, then flattening level i into level i+1 919 will not result in loss of convergence speed. Now let's take the 920 other extreme. Suppose "n" objects in level i+1 depend on 1 object 921 in level i. Now suppose FIB flattens level i into level i+1. If a 922 topology change results in modifying the single object in level i, 923 then FIB has to backwalk and modify "n" objects in the flattened 924 level, thereby losing all the benefit of BGP-PIC. Experience shows 925 that flattening forwarding chains usually results in moderate loss of 926 BGP-PIC benefits. Further analysis is needed to corroborate and 927 quantify this statement. You may also add an observation that in such cases where number of forwarding chains are limited a configuration change for example resulting in use of aggregate VPN labels or use of per site VPN labels vs per prefix labels may increase the benefits and shorten connectivity restoration time. I am a bit surprised this document does not mention types of VPN labels and their implications to BGP PIC. 928 929 7. Operational Properties 930 931 7.1. Failure Coverage 932 933 BGP-PIC provides prefix-independent convergence for failures that 934 affect shared forwarding dependencies, such as the loss of a next 935 hop, an IGP path, or an adjacency used by multiple BGP prefixes. By 936 precomputing and installing alternate forwarding paths and leveraging 937 shared hierarchical forwarding objects, BGP-PIC enables traffic to be 938 rerouted without requiring per-prefix BGP best-path recomputation. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Pls kindly add: "without requiring per-prefix BGP best-path recomputation for connectivity restoration." Otherwise as written reader may assume BGP does not need to run best path at all upon failure which would be cleary incorrect. 939 940 Failures that do not impact shared forwarding objects, or that 941 require BGP policy re-evaluation, may still rely on conventional BGP 942 convergence behavior. I would not mention "BGP policy re-evaluation". When BGP gives to RIB/FIB additional active or backup paths those already are screened by BGP policy. 943 944 945 946 947 948 949 950 951 952 Bashandy, et al. Expires 19 August 2026 [Page 17] 953 954 Internet-Draft BGP Prefix Independent Convergence February 2026 955 956 957 7.2. Convergence Characteristics 958 959 The primary convergence characteristic of BGP-PIC is that forwarding 960 convergence time is independent of the number of affected BGP 961 prefixes. Upon a failure, only a limited number of shared forwarding 962 objects need to be updated. Compared with traditional BGP 963 convergence, where forwarding updates scale with the number of 964 impacted prefixes and may result in prolonged convergence in large 965 routing tables. 966 967 7.3. Fast Local Repair 968 969 BGP-PIC enables forwarding repair that is independent of BGP control- 970 plane convergence. Backup forwarding paths are computed and 971 installed in advance, allowing the forwarding plane to redirect 972 traffic immediately upon detection of a local failure. 973 974 When the failure is local (a local IGP next-hop failure or a local 975 EBGP next-hop failure), a pre-computed and pre-installed backup is 976 activated by a local-protection mechanism that does not depend on the 977 number of BGP destinations impacted by the failure. Sub-50msec is 978 thus possible even if millions of BGP prefixes are impacted. 979 980 When the failure is remote (a remote IGP failure not impacting the 981 BGP next-hop or a remote BGP next-hop failure), an alternate pic- 982 path is activated upon IGP convergence. All the impacted BGP 983 destinations benefit from a working alternate path as soon as the IGP 984 convergence occurs for their impacted BGP next-hop even if millions 985 of BGP routes are impacted. 986 987 Appendix D puts the BGP-PIC benefits in perspective by providing some 988 results using actual numbers. 989 990 7.4. Configuration Free 991 992 The BGP-PIC solution depends on internal structures and procedures 993 and does not require any configuration and operator involvement. Is this universally true ? How about bgp knobs: "bgp convergence local" or "protection local-prefixes" 994 995 7.5. Incremental Deployment 996 997 As soon as one router supports BGP-PIC solution, it is possible to 998 benefit from all its benefits (most notably convergence that does not 999 depend in the number of prefixes) without any requirement for other 1000 routers to support BGP-PIC. 1001 1002 1003 1004 1005 1006 1007 1008 Bashandy, et al. Expires 19 August 2026 [Page 18] 1009 1010 Internet-Draft BGP Prefix Independent Convergence February 2026 1011 1012 1013 8. Security Considerations 1014 1015 The behavior described in this document is internal functionality to 1016 a router that result in significant improvement to convergence time 1017 as well as reduction in CPU and memory used by FIB while not showing 1018 change in basic routing and forwarding functionality. As such no 1019 additional security risk is introduced by using the mechanisms 1020 described in this document. 1021 1022 9. IANA Considerations 1023 1024 This document has no IANA actions. 1025 1026 10. References 1027 1028 10.1. Normative References 1029 1030 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1031 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1032 DOI 10.17487/RFC4271, January 2006, 1033 <https://www.rfc-editor.org/info/rfc4271>. 1034 1035 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1036 Label Switching Architecture", RFC 3031, 1037 DOI 10.17487/RFC3031, January 2001, 1038 <https://www.rfc-editor.org/info/rfc3031>. 1039 1040 10.2. Informative References 1041 1042 [I-D.ietf-idr-best-external] 1043 Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. 1044 Gredler, "Advertisement of the best external route in 1045 BGP", Work in Progress, Internet-Draft, draft-ietf-idr- 1046 best-external-05, 3 January 2012, 1047 <https://datatracker.ietf.org/doc/html/draft-ietf-idr- 1048 best-external-05>. 1049 1050 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1051 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 1052 <https://www.rfc-editor.org/info/rfc5565>. 1053 1054 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1055 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1056 2006, <https://www.rfc-editor.org/info/rfc4364>. 1057 1058 1059 1060 1061 1062 1063 1064 Bashandy, et al. Expires 19 August 2026 [Page 19] 1065 1066 Internet-Draft BGP Prefix Independent Convergence February 2026 1067 1068 1069 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1070 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1071 Provider Edge Routers (6PE)", RFC 4798, 1072 DOI 10.17487/RFC4798, February 2007, 1073 <https://www.rfc-editor.org/info/rfc4798>. 1074 1075 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1076 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1077 October 2007, <https://www.rfc-editor.org/info/rfc5036>. 1078 1079 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1080 "Advertisement of Multiple Paths in BGP", RFC 7911, 1081 DOI 10.17487/RFC7911, July 2016, 1082 <https://www.rfc-editor.org/info/rfc7911>. 1083 1084 [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., 1085 and K. Kumaki, "Distribution of Diverse BGP Paths", 1086 RFC 6774, DOI 10.17487/RFC6774, November 2012, 1087 <https://www.rfc-editor.org/info/rfc6774>. 1088 1089 [I-D.pmohapat-idr-fast-conn-restore] 1090 Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk, 1091 "Fast Connectivity Restoration Using BGP Add-path", Work 1092 in Progress, Internet-Draft, draft-pmohapat-idr-fast-conn- 1093 restore-03, 22 January 2013, 1094 <https://datatracker.ietf.org/doc/html/draft-pmohapat-idr- 1095 fast-conn-restore-03>. 1096 1097 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1098 Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., 1099 Decraene, B., and D. Voyer, "Topology Independent Fast 1100 Reroute using Segment Routing", Work in Progress, 1101 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 1102 21, 12 February 2025, 1103 <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg- 1104 segment-routing-ti-lfa-21>. 1105 1106 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1107 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1108 <https://www.rfc-editor.org/info/rfc5714>. 1109 1110 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1111 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1112 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1113 <https://www.rfc-editor.org/info/rfc7490>. 1114 1115 1116 1117 1118 1119 1120 Bashandy, et al. Expires 19 August 2026 [Page 20] 1121 1122 Internet-Draft BGP Prefix Independent Convergence February 2026 1123 1124 1125 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1126 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1127 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1128 <https://www.rfc-editor.org/info/rfc7812>. 1129 1130 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1131 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1132 <https://www.rfc-editor.org/info/rfc8277>. 1133 1134 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1135 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1136 Routing with the MPLS Data Plane", RFC 8660, 1137 DOI 10.17487/RFC8660, December 2019, 1138 <https://www.rfc-editor.org/info/rfc8660>. 1139 1140 [RFC9107] Raszuk, R., Ed., Decraene, B., Ed., Cassar, C., Åman, E., 1141 and K. Wang, "BGP Optimal Route Reflection (BGP ORR)", 1142 RFC 9107, DOI 10.17487/RFC9107, August 2021, 1143 <https://www.rfc-editor.org/info/rfc9107>. 1144 1145 Appendix A. Acknowledgments 1146 1147 Special thanks to Neeraj Malhotra and Yuri Tsier for the valuable 1148 help 1149 1150 Special thanks to Bruno Decraene, Theresa Enghardt, Ines Robles, Luc 1151 Andre Burdet, and Alvaro Retana for the valuable comments 1152 1153 This document was prepared using 2-Word-v2.0.template.dot. 1154 1155 Appendix B. Handling Platforms with Limited Levels of Hierarchy 1156 1157 This section provides additional details on how to handle platforms 1158 with limited number of hierarchical levels. 1159 1160 Let's consider a pathlist associated with the leaf "R1" consisting of 1161 the list of paths <P1, P2,..., Pn>. Assume that the leaf "R1" has an 1162 OutLabel-list <L1, L2,..., Ln>. Suppose the path Pi is a recursive 1163 path that resolves via a prefix represented by the leaf "R2". The 1164 leaf "R2" itself is pointing to a pathlist consisting of the paths 1165 <Q1, Q2,..., Qm>. 1166 1167 If the platform supports the number of hierarchy levels of the 1168 forwarding chain, then a packet that uses the path "Pi" will be 1169 forwarded according to the steps in Section 4. 1170 1171 1172 1173 1174 1175 1176 Bashandy, et al. Expires 19 August 2026 [Page 21] 1177 1178 Internet-Draft BGP Prefix Independent Convergence February 2026 1179 1180 1181 Suppose the platform cannot support the number of hierarchy levels in 1182 the forwarding chain. FIB manager needs to reduce the number of 1183 hierarchy levels when programming the forwarding chain in the FIB. 1184 The idea of reducing the number of hierarchy levels is to "flatten" 1185 two chain levels into a single level. The "flattening" steps are as 1186 follows 1187 1188 1. FIB manager walks to the parent of "Pi", which is the leaf "R2". 1189 1190 2. FIB manager extracts the parent pathlist of the leaf "R2", which 1191 is <Q1, Q2,..., Qm>. 1192 1193 3. FIB manager also extracts the OutLabel-list of R2 associated with 1194 the leaf "R2". Remember that the OutLabel-list of R2 is <L1, 1195 L2,..., Lm>. 1196 1197 4. FIB manager replaces the path "Pi", with the list of pic- paths 1198 <Q1, Q2,..., Qm>. 1199 1200 5. Hence the path list <P1, P2,..., Pn> now becomes "<P1, 1201 P2,...,Pi-1, Q1, Q2,..., Qm, Pi+1, Pn>. 1202 1203 1. The path-index stored inside the locations "Q1", "Q2", ..., "Qm" 1204 must all be "i" because the index "i" refers to the label "Li" 1205 associated with leaf "R1". 1206 1207 2. FIB manager attaches an OutLabel-list with the new pathlist as 1208 follows: <Unlabeled,..., Unlabeled, L1, L2,..., Lm, Unlabeled, 1209 ..., Unlabeled>. The size of the label list associated with the 1210 flattened pathlist equals the size of the pathlist. Thus there 1211 is a 1-1 mapping between every path in the "flattened" pathlist 1212 and the OutLabel-list associated with it. 1213 1214 It is noteworthy to mention that the labels in the OutLabel-list 1215 associated with the "flattened" pathlist may be stored in the same 1216 memory location as the path itself to avoid additional memory access. 1217 1218 The same steps can be applied to all paths in the pathlist <P1, 1219 P2,..., Pn> so that all paths are "flattened" thereby reducing the 1220 number of hierarchical levels by one. Note that that "flattening" a 1221 pathlist pulls in all paths of the parent pic- paths, a desired 1222 feature to utilize all paths at all levels. A platform that has a 1223 limit on the number of paths in a pathlist for any given leaf may 1224 choose to reduce the number paths using methods that are beyond the 1225 scope of this document. 1226 1227 1228 1229 1230 1231 1232 Bashandy, et al. Expires 19 August 2026 [Page 22] 1233 1234 Internet-Draft BGP Prefix Independent Convergence February 2026 1235 1236 1237 The steps can be recursively applied to other paths at the same 1238 levels or other levels to recursively reduce the number of 1239 hierarchical levels to an arbitrary value so as to accommodate the 1240 capability of the forwarding engine. 1241 1242 Because a flattened pathlist may have an associated OutLabel-list the 1243 forwarding behavior has to be slightly modified. The modification is 1244 done by adding the following step right after step 4 in Section 4. 1245 1246 1. If there is an OutLabel-list associated with the pathlist, then 1247 if the path "Pi" is chosen by the hashing algorithm, retrieve the 1248 label at location "i" in that OutLabel-list and apply the label 1249 action of that label on the packet. 1250 1251 The steps in this Section to are applied to an example in the next 1252 Section. 1253 1254 Appendix C. Example: Flattening a forwarding chain. 1255 1256 This example uses a case of inter-AS option C [RFC4364] where there 1257 are 3 levels of hierarchy. Figure 4 illustrates the sample topology. 1258 The Autonomous System Border Routers (ASBRs) on the ingress domain 1259 (Domain 1) use BGP to advertise the core routers (ASBRs and ePEs) of 1260 the egress domain (Domain 2) to the iPE. The end result is that the 1261 ingress PE (iPE) has 2 levels of recursion for the VPN prefixes VPN- 1262 IP1 and VPN-IP2. 1263 ... 1287 1288 Bashandy, et al. Expires 19 August 2026 [Page 23] 1289 1290 Internet-Draft BGP Prefix Independent Convergence February 2026 1291 1292 1293 Domain 1 Domain 2 1294 +-------------+ +-------------+ 1295 | | | | 1296 | LDP/SR Core | | LDP/SR core | 1297 | | | | 1298 | (192.0.2.4) | | 1299 | ASBR11-------ASBR21........ePE1(192.0.2.1) 1300 | | \ / | . . |\ 1301 | | \ / | . . | \ 1302 | | \ / | . . | \ 1303 | | \/ | .. | \VPN-IP1(198.51.100.0/24) 1304 | | /\ | . . | /VRF "Blue" ASN: 65000 1305 | | / \ | . . | / 1306 | | / \ | . . | / 1307 | | / \ | . . |/ 1308 iPE ASBR12-------ASBR22........ePE2 (192.0.2.2) 1309 | (192.0.2.5) | |\ 1310 | | | | \ 1311 | | | | \ 1312 | | | | \VRF "Blue" ASN: 65000 1313 | | | | /VPN-IP2(203.0.113.0/24) 1314 | | | | / 1315 | | | | / 1316 | | | |/ 1317 | ASBR13-------ASBR23........ePE3(192.0.2.3) 1318 | (192.0.2.6) | | 1319 | | | | 1320 | | | | 1321 +-------------+ +-------------+ 1322 <=========== <========= <============ 1323 Advertise ePEx Advertise Redistribute 1324 Using IBGP-LU ePEx Using ePEx routes 1325 EBGP-LU into BGP 1326 1327 Figure 3: Sample 3-level hierarchy topology Wrong Figure number ... pls consider SVG. 1328 1329 The following assumptions about connectivity are made: 1330 1331 * In "Domain 2", both ASBR21 and ASBR22 can reach both ePE1 and ePE2 1332 using the same metric. 1333 1334 * In "Domain 2", only ASBR23 can reach ePE3. No that's a partitioned domain. This is BROKEN !!!! As this is steady state topology please do not use such broken networks for descritpion. 1335 1336 * In "Domain 1", iPE (the ingress PE) can reach ASBR11, ASBR12, and 1337 ASBR13 via IGP using the same metric. 1338 1339 The following assumptions are made about the labels: 1340 1341 1342 1343 1344 Bashandy, et al. Expires 19 August 2026 [Page 24] 1345 1346 Internet-Draft BGP Prefix Independent Convergence February 2026 1347 1348 1349 * The VPN labels advertised by ePE1 and ePE2 for prefix VPN-IP1 are 1350 VPN-L11 and VPN-L21, respectively. 1351 1352 * The VPN labels advertised by ePE2 and ePE3 for prefix VPN-IP2 are 1353 VPN-L22 and VPN-L32, respectively. 1354 1355 * The labels advertised by ASBR11 to iPE using BGP-LU for the egress 1356 PEs ePE1 and ePE2 are LASBR111(ePE1) and LASBR112(ePE2), 1357 respectively. 1358 1359 * The labels advertised by ASBR12 to iPE using BGP-LU for the egress 1360 PEs ePE1 and ePE2 are LASBR121(ePE1) and LASBR122(ePE2), 1361 respectively. 1362 1363 * The label advertised by ASBR13 to iPE using BGP-LU for the egress 1364 PE ePE3 is LASBR13(ePE3). Again inconsistent LU label naming. ASBR13 should be advertising LASBR133(ePE3) not LASBR13. Frankly if the above is inteneded picture needs to be fixed. The correct picture should look like this: Domain 1 Domain 2 +-------------+ +-------------+ | | | | | LDP/SR Core | | LDP/SR core | | | | | | (192.0.2.4) | | | ASBR11-------ASBR21........ePE1(192.0.2.1) | | \ / | . . |\ | | \ / | . . | \ | | \ / | . . | \ | | \/ | .. | \VPN-IP1(198.51.100.0/24) | | /\ | . . | /VRF "Blue" ASN: 65000 | | / \ | . . | / | | / \ | . . | / | | / \ | . . |/ iPE ASBR12-------ASBR22........ePE2 (192.0.2.2) | (192.0.2.5) | |\ | | | | \ | | | | \ | | +-------------+ \VRF "Blue" ASN: 65000 | | +-------------+ /VPN-IP2(203.0.113.0/24) | | | Domain 3 | / | | | | / | | | |/ | ASBR13-------ASBR23........ePE3(192.0.2.3) | (192.0.2.6) | | | | | | | | | | +-------------+ +-------------+ <=========== <========= <============ Advertise ePEx Advertise Redistribute Using IBGP-LU ePEx Using ePEx routes EBGP-LU into BGP 1365 1366 * The IGP labels advertised by the next hops directly connected to 1367 iPE towards ASBR11, ASBR12, and ASBR13 in the core of domain 1 are 1368 IGP-L11, IGP-L12, and IGP-L13, respectively. 1369 1370 * Both the routers ASBR21 and ASBR22 of Domain 2 advertise the same 1371 label LASBR21 and LASBR22 for the egress PEs ePE1 and ePE2, 1372 respectively, to the routers ASBR11 and ASBR22 of Domain 1. In BGP LU (SAFI 4) ? 1373 1374 * The router ASBR23 of Domain 2 advertises the label LASBR23 for the 1375 egress PE ePE3 to the router ASBR13 of Domain 1. Pls do consider making it as per suggestion Domain 3. 1376 1377 Based on these connectivity assumptions and the topology in Figure 4, 1378 the routing table on iPE is You mean in the VRF after import ? 1379 1380 65000: 198.51.100.0/24 1381 via ePE1 (192.0.2.1), VPN Label: VPN-L11 1382 via ePE2 (192.0.2.2), VPN Label: VPN-L21 1383 65000: 203.0.113.0/24 1384 via ePE2 (192.0.2.2), VPN Label: VPN-L22 1385 via ePE3 (192.0.2.3), VPN Label: VPN-L32 1386 1387 192.0.2.1/32 (ePE1) 1388 via ASBR11, Label: LASBR111(ePE1) via ASBR12, Label: 1389 LASBR121(ePE1) Messed up & incomplete. why is "via ASBR12" ? where is the path to 192.0.2.1/32 (ePE1) via ASBR12 1390 1391 192.0.2.2/32 (ePE2) 1392 via ASBR11, Label: LASBR112(ePE2) via ASBR12, Label: 1393 LASBR122(ePE2) Messed up & incomplete. why is "via ASBR12" ? where is the path to 192.0.2.2/32 (ePE1) via ASBR12 1394 1395 192.0.2.3/32 (ePE3) 1396 Via ASBR13, Label: LASBR13(ePE3) 1397 1398 1399 1400 Bashandy, et al. Expires 19 August 2026 [Page 25] 1401 1402 Internet-Draft BGP Prefix Independent Convergence February 2026 1403 1404 1405 192.0.2.4/32 (ASBR11) 1406 via Core, Label: IGP-L11 1407 192.0.2.5/32 (ASBR12) 1408 via Core, Label: IGP-L12 1409 192.0.2.6/32 (ASBR13) 1410 via Core, Label: IGP-L13 1411 1412 The diagram in Figure 5 illustrates the forwarding chain in iPE 1413 assuming that the forwarding hardware in iPE supports 3 levels of 1414 hierarchy. The leaves corresponding to the ASBRs on domain 1 1415 (ASBR11, ASBR12, and ASBR13) are at the bottom of the hierarchy. 1416 There are few important points: 1417 1418 * Because the hardware supports the required depth of hierarchy, the 1419 sizes of a pathlist equal the size of the label list associated 1420 with the leaves using this pathlist. 1421 1422 * The path-index inside the pathlist entry indicates the label that 1423 will be picked from the OutLabel-List associated with the child 1424 leaf if that path is chosen by the forwarding engine hashing 1425 function. 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 Bashandy, et al. Expires 19 August 2026 [Page 26] 1457 1458 Internet-Draft BGP Prefix Independent Convergence February 2026 1459 1460 1461 OutLabel-List OutLabel-List 1462 For VPN-IP1 For VPN-IP2 1463 +------------+ +--------+ +-------+ +------------+ 1464 | VPN-L11 |<---| VPN-IP1| |VPN-IP2|-->| VPN-L22 | 1465 +------------+ +---+----+ +---+---+ +------------+ 1466 | VPN-L21 | | | | VPN-L32 | 1467 +------------+ | | +------------+ 1468 | | 1469 V V 1470 +---+---+ +---+---+ 1471 | 0 | 1 | | 0 | 1 | 1472 +-|-+-\-+ +-/-+-\-+ 1473 | \ / \ 1474 | \ / \ 1475 | \ / \ 1476 | \ / \ 1477 v \ / \ 1478 +-----+ +-----+ +-----+ 1479 +----+ ePE1| |ePE2 +-----+ | ePE3+-----+ 1480 | +--+--+ +-----+ | +--+--+ | 1481 v | / v | v 1482 +--------------+ | / +--------------+ | +-------------+ 1483 |LASBR111(ePE1)| | / |LASBR112(ePE2)| | |LASBR13(ePE3)| 1484 +--------------+ | / +--------------+ | +-------------+ 1485 |LASBR121(ePE1)| | / |LASBR122(ePE2)| | OutLabel-List 1486 +--------------+ | / +--------------+ | For ePE3 1487 OutLabel-List | / OutLabel-List | 1488 For ePE1 | / For ePE2 | 1489 | / | 1490 | / | 1491 | / | 1492 v v v 1493 +---+---+ Shared pathlist +---+ pathlist 1494 | 0 | 1 | For ePE1 and ePE2 | 0 | For ePE3 1495 +-|-+-\-+ +-|-+ 1496 | \ | 1497 | \ | 1498 | \ | 1499 | \ | 1500 v v v 1501 +------+ +------+ +------+ 1502 +---+ASBR11| |ASBR12+--+ |ASBR13+---+ 1503 | +------+ +------+ | +------+ | 1504 v v v 1505 +-------+ +-------+ +-------+ 1506 |IGP-L11| |IGP-L12| |IGP-L13| 1507 +-------+ +-------+ +-------+ 1508 1509 1510 1511 1512 Bashandy, et al. Expires 19 August 2026 [Page 27] 1513 1514 Internet-Draft BGP Prefix Independent Convergence February 2026 1515 1516 1517 Figure 4: Forwarding Chain for hardware supporting 3 Levels 1518 1519 Now suppose the hardware on iPE (the ingress PE) supports 2 levels of 1520 hierarchy only. In that case, the 3-levels forwarding chain in 1521 Figure 5 needs to be "flattened" into 2 levels only. 1522 1523 OutLabel-List OutLabel-List 1524 For VPN-IP1 For VPN-IP2 1525 +------------+ +-------+ +-------+ +------------+ 1526 | VPN-L11 |<---|VPN-IP1| | VPN-IP2|--->| VPN-L22 | 1527 +------------+ +---+---+ +---+---+ +------------+ 1528 | VPN-L21 | | | | VPN-L32 | 1529 +------------+ | | +------------+ 1530 | | 1531 | | 1532 | | 1533 Flattened | | Flattened 1534 pathlist V V pathlist 1535 +===+===+ +===+===+===+ +==============+ 1536 +--------+ 0 | 1 | | 0 | 0 | 1 +---->|LASBR112(ePE2)| 1537 | +=|=+=\=+ +=/=+=/=+=\=+ +==============+ 1538 v | \ / / \ |LASBR122(ePE2)| 1539 +==============+ | \ +-----+ / \ +==============+ 1540 |LASBR111(ePE1)| | \/ / \ |LASBR13(ePE3) | 1541 +==============+ | /\ / \ +==============+ 1542 |LASBR121(ePE1)| | / \ / \ 1543 +==============+ | / \ / \ 1544 | / \ / \ 1545 | / + + \ 1546 | + | | \ 1547 | | | | \ 1548 v v v v v 1549 +------+ +------+ +------+ 1550 +----|ASBR11| |ASBR12+---+ |ASBR13+---+ 1551 | +------+ +------+ | +------+ | 1552 v v v 1553 +-------+ +-------+ +-------+ 1554 |IGP-L11| |IGP-L12| |IGP-L13| 1555 +-------+ +-------+ +-------+ 1556 1557 Figure 5: Flattening 3 levels to 2 levels of Hierarchy on iPE 1558 1559 Figure 6 represents one way to "flatten" a 3 levels hierarchy into 1560 two levels. There are a few important points: 1561 1562 1563 1564 1565 1566 1567 1568 Bashandy, et al. Expires 19 August 2026 [Page 28] 1569 1570 Internet-Draft BGP Prefix Independent Convergence February 2026 1571 1572 1573 * As mentioned in Appendix B, a flattened pathlist may have label 1574 lists associated with them. The size of the label list associated 1575 with a flattened pathlist equals the size of the pathlist. Hence 1576 it is possible that an implementation includes these label lists 1577 in the flattened pathlist itself. 1578 1579 * Again as mentioned in Appendix B, the size of a flattened pathlist 1580 may not be equal to the size of the OutLabel-lists of leaves using 1581 the flattened pathlist. So the indices inside a flattened 1582 pathlist still indicate the label index in the OutLabel-Lists of 1583 the leaves using that pathlist. Because the size of the flattened 1584 pathlist may be different from the size of the OutLabel-lists of 1585 the leaves, the indices may be repeated. 1586 1587 * Let's take a look at the flattened pathlist used by the prefix 1588 "VPN-IP2". The pathlist associated with the prefix "VPN-IP2" has 1589 three entries. 1590 1591 - The first and second entry have index "0". This is because 1592 both entries correspond to ePE2. Thus when hashing performed 1593 by the forwarding engine results in using the first or the 1594 second entry in the pathlist, the forwarding engine will pick 1595 the correct VPN label "VPN-L22", which is the label advertised 1596 by ePE2 for the prefix "VPN-IP2". 1597 1598 - The third entry has the index "1". This is because the third 1599 entry corresponds to ePE3. Thus when the hashing is performed 1600 by the forwarding engine results in using the third entry in 1601 the flattened pathlist, the forwarding engine will pick the 1602 correct VPN label "VPN-L32", which is the label advertised by 1603 "ePE3" for the prefix "VPN-IP2". 1604 1605 Now let's try and apply the forwarding steps in Section 4 together 1606 with the additional step in Section Appendix B to the flattened 1607 forwarding chain illustrated in Figure 6. 1608 1609 * Suppose a packet arrives at "iPE" and matches the VPN prefix "VPN- 1610 IP2". 1611 1612 * The forwarding engine walks to the parent of the "VPN-IP2", which 1613 is the flattened pathlist and applies a hashing algorithm to pick 1614 a path. 1615 1616 * Suppose the hashing by the forwarding engine picks the second path 1617 in the flattened pathlist associated with the leaf "VPN-IP2". 1618 1619 * Because the second path has the index "0", the label "VPN-L22" is 1620 pushed on the packet. 1621 1622 1623 1624 Bashandy, et al. Expires 19 August 2026 [Page 29] 1625 1626 Internet-Draft BGP Prefix Independent Convergence February 2026 1627 1628 1629 * Next the forwarding engine picks the second label from the 1630 OutLabel-List associated with the flattened pathlist resulting in 1631 "LASBR122(ePE2)" being the next pushed label. 1632 1633 * The forwarding engine now moves to the parent of the flattened 1634 pathlist corresponding to the second path. The parent is the IGP 1635 label leaf corresponding to "ASBR12". 1636 1637 * So the packet is forwarded towards the ASBR "ASBR12" and the IGP 1638 label at the top will be "IGP-L12". 1639 1640 Based on the above steps, a packet arriving at iPE and destined to 1641 the prefix VPN-L22 reaches its destination as follows: 1642 1643 o iPE sends the packet along the shortest path towards ASBR12 1644 with the following label stack starting from the top: {L12, 1645 LASBR122(ePE2), VPN-L22}. 1646 1647 o The penultimate hop of ASBR12 pops the top label "L12". Hence the 1648 packet arrives at ASBR12 with the remaining label stack 1649 {LASBR122(ePE2), VPN-L22} where "LASBR12(ePE2)" is the top label. 1650 1651 o ASBR12 swaps "LASBR122(ePE2)" with the label "LASBR22(ePE2)", 1652 which is the label advertised by ASBR22 for the ePE2 (the egress 1653 PE). 1654 1655 o ASBR22 receives the packet with "LASBR22(ePE2)" at the top. 1656 1657 o Hence ASBR22 swaps "LASBR22(ePE2)" with the IGP label for ePE2 1658 advertised by the next-hop towards ePE2 in domain 2, and sends 1659 the packet along the shortest path towards ePE2. 1660 1661 o The penultimate hop of ePE2 pops the top label. Hence ePE2 1662 receives the packet with the top label VPN-L22 at the top 1663 1664 o ePE2 pops "VPN-L22" and sends the packet as a pure IP packet 1665 towards the destination VPN-IP2. 1666 1667 Appendix D. Perspective 1668 1669 The following table puts the BGP-PIC benefits in perspective assuming There no table. 1670 1671 * 1M impacted BGP prefixes 1672 1673 * IGP convergence ~ 500 msec 1674 1675 * local protection ~ 50msec 1676 1677 1678 1679 1680 Bashandy, et al. Expires 19 August 2026 [Page 30] 1681 1682 Internet-Draft BGP Prefix Independent Convergence February 2026 1683 1684 1685 * FIB Update per BGP destination ~ 100usec conservative, 1686 1687 ~ 10usec optimistic 1688 1689 * BGP best route recalculation per BGP destination 1690 1691 ~ 10usec optimistic, 1692 1693 ~ 100usec optimistic 1694 1695 Without PIC With PIC 1696 1697 Local IGP Failure 10 to 100sec 50msec 1698 1699 1700 Local BGP Failure 100 to 200sec 50msec 1701 1702 1703 Remote IGP Failure 10 to 100sec 500msec 1704 1705 1706 Local BGP Failure 100 to 200sec 500msec 1707 1708 Upon local IGP next-hop failure or remote IGP next-hop failure, the 1709 existing primary BGP next-hop is intact and usable hence the 1710 resiliency only depends on the ability of the FIB mechanism to 1711 reflect the new path to the BGP next-hop to the depending BGP 1712 destinations. Without BGP-PIC, a conservative back-of-the-envelope 1713 estimation for this FIB update is 100usec per BGP destination. An 1714 optimistic estimation is 10usec per entry. 1715 1716 Upon local BGP next-hop failure or remote BGP next-hop failure, 1717 without the BGP-PIC mechanism, a new BGP Best-Path needs to be 1718 recomputed and new updates need to be sent to peers. This depends on 1719 BGP processing time that will be shared between best-path 1720 computation, RIB update and peer update. A conservative back-of-the- 1721 envelope estimation for this is 200usec per BGP destination. An 1722 optimistic estimation is 100usec per entry. 1723 1724 Authors' Addresses 1725 1726 Ahmed Bashandy (editor) 1727 HPE 1728 United States of America 1729 Email: abashandy.ietf@gmail.com 1730 1731 1732 1733 1734 1735 1736 Bashandy, et al. Expires 19 August 2026 [Page 31] 1737 1738 Internet-Draft BGP Prefix Independent Convergence February 2026 1739 1740 1741 Clarence Filsfils 1742 Cisco Systems 1743 Email: cfilsfil@cisco.com 1744 1745 1746 Pradosh Mohapatra 1747 Sproute Networks 1748 United States of America 1749 Email: mpradosh@yahoo.com 1750 1751 1752 Yingzhen Qu (editor) 1753 Futurewei Technologies 1754 United States of America 1755 Email: yingzhen.ietf@gmail.com 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 Bashandy, et al. Expires 19 August 2026 [Page 32]