idnits 2.17.1 draft-ietf-rtgwg-segment-routing-ti-lfa-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2022) is 825 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Adjacency' is mentioned on line 582, but not defined == Missing Reference: 'Node' is mentioned on line 582, but not defined == Outdated reference: A later version (-16) exists of draft-bashandy-rtgwg-segment-routing-uloop-12 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Litkowski 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Bashandy 5 Expires: July 25, 2022 Individual 6 C. Filsfils 7 Cisco Systems 8 P. Francois 9 INSA Lyon 10 B. Decraene 11 Orange 12 D. Voyer 13 Bell Canada 14 January 21, 2022 16 Topology Independent Fast Reroute using Segment Routing 17 draft-ietf-rtgwg-segment-routing-ti-lfa-08 19 Abstract 21 This document presents Topology Independent Loop-free Alternate Fast 22 Re-route (TI-LFA), aimed at providing protection of node and 23 adjacency segments within the Segment Routing (SR) framework. This 24 Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being 25 LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding 26 (DLFA). It extends these concepts to provide guaranteed coverage in 27 any two connected network using a link-state IGP. A key aspect of 28 TI-LFA is the FRR path selection approach establishing protection 29 over the expected post-convergence paths from the point of local 30 repair, reducing the operational need to control the tie-breaks among 31 various FRR options. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 25, 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Conventions used in this document . . . . . . . . . . . . 8 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Base principle . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. Intersecting P-Space and Q-Space with post-convergence paths 9 73 5.1. Extended P-Space property computation for a resource X, 74 over post-convergence paths . . . . . . . . . . . . . . . 9 75 5.2. Q-Space property computation for a resource X, over 76 post-convergence paths . . . . . . . . . . . . . . . . . 10 77 5.3. Scaling considerations when computing Q-Space . . . . . . 10 78 6. TI-LFA Repair path . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. FRR path using a direct neighbor . . . . . . . . . . . . 10 80 6.2. FRR path using a PQ node . . . . . . . . . . . . . . . . 11 81 6.3. FRR path using a P node and Q node that are adjacent . . 11 82 6.4. Connecting distant P and Q nodes along post-convergence 83 paths . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7. Building TI-LFA repair lists . . . . . . . . . . . . . . . . 11 85 7.1. Link protection . . . . . . . . . . . . . . . . . . . . . 11 86 7.1.1. The active segment is a node segment . . . . . . . . 12 87 7.1.2. The active segment is an adjacency segment . . . . . 12 88 7.2. Dataplane specific considerations . . . . . . . . . . . . 13 89 7.2.1. MPLS dataplane considerations . . . . . . . . . . . . 13 90 7.2.2. SRv6 dataplane considerations . . . . . . . . . . . . 13 91 8. TI-LFA and SR algorithms . . . . . . . . . . . . . . . . . . 14 92 9. Usage of Adjacency segments in the repair list . . . . . . . 15 93 10. Analysis based on real network topologies . . . . . . . . . . 15 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 97 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 15.2. Informative References . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Acronyms 105 o DLFA: Remote LFA with Directed forwarding. 107 o FRR: Fast Re-route. 109 o IGP: Interior Gateway Protocol. 111 o LFA: Loop-Free Alternate. 113 o LSDB: Link State DataBase. 115 o PLR: Point of Local Repair. 117 o RL: Repair list. 119 o RLFA: Remote LFA. 121 o RSPT: Reverse Shortest Path Tree. 123 o SID: Segment Identifier. 125 o SLA: Service Level Agreement. 127 o SPF: Shortest Path First. 129 o SPT: Shortest Path Tree. 131 o SR: Segment Routing. 133 o SRGB: Segment Routing Global Block. 135 o SRLG: Shared Risk Link Group. 137 o TI-LFA: Topology Independant LFA. 139 2. Introduction 141 Segment Routing aims at supporting services with tight SLA guarantees 142 [RFC8402]. By relying on SR this document provides a local repair 143 mechanism for standard link-state IGP shortest path capable of 144 restoring end-to-end connectivity in the case of a sudden directly 145 connected failure of a network component. Non-SR mechanisms for 146 local repair are beyond the scope of this document. Non-local 147 failures are addressed in a separate document 148 [I-D.bashandy-rtgwg-segment-routing-uloop]. 150 The term topology independent (TI) refers to the ability to provide a 151 loop free backup path irrespective of the topologies used in the 152 network. This provides a major improvement compared to LFA [RFC5286] 153 and remote LFA [RFC7490] which cannot provide a complete protection 154 coverage in some topologies as described in [RFC6571]. 156 For each destination in the network, TI-LFA pre-installs a backup 157 forwarding entry for each protected destination ready to be activated 158 upon detection of the failure of a link used to reach the 159 destination. TI-LFA provides protection in the event of any one of 160 the following: single link failure, single node failure, or single 161 SRLG failure. In link failure mode, the destination is protected 162 assuming the failure of the link. In node protection mode, the 163 destination is protected assuming that the neighbor connected to the 164 primary link has failed. In SRLG protecting mode, the destination is 165 protected assuming that a configured set of links sharing fate with 166 the primary link has failed (e.g. a linecard or a set of links 167 sharing a common transmission pipe). 169 Protection techniques outlined in this document are limited to 170 protecting links, nodes, and SRLGs that are within a link-state IGP 171 area. Protecting domain exit routers and/or links attached to 172 another routing domains are beyond the scope of this document 174 Thanks to SR, TI-LFA does not require the establishment of TLDP 175 sessions with remote nodes in order to take advantage of the 176 applicability of remote LFAs (RLFA) [RFC7490][RFC7916] or remote LFAs 177 with directed forwarding (DLFA)[RFC5714]. All the Segment 178 Identifiers (SIDs) are available in the link state database (LSDB) of 179 the IGP. As a result, preferring LFAs over RLFAs or DLFAs, as well 180 as minimizing the number of RLFA or DLFA repair nodes is not required 181 anymore. 183 Thanks to SR, there is no need to create state in the network in 184 order to enforce an explicit FRR path. This relieves the nodes 185 themselves from having to maintain extra state, and it relieves the 186 operator from having to deploy an extra protocol or extra protocol 187 sessions just to enhance the protection coverage. 189 [RFC7916] raised several operational considerations when using LFA or 190 remote LFA. [RFC7916] Section 3 presents a case where a high 191 bandwidth link between two core routers is protected through a PE 192 router connected with low bandwidth links. In such a case, 193 congestion may happen when the FRR backup path is activated. 195 [RFC7916] introduces a local policy framework to let the operator 196 tuning manually the best alternate election based on its own 197 requirements. 199 From a network capacity planning point of view, it is often assumed 200 that if a link L fails on a particular node X, the bandwidth consumed 201 on L will be spread over some of the remaining links of X. The 202 remaining links to be used are determined by the IGP routing 203 considering that the link L has failed (we assume that the traffic 204 uses the post-convergence path starting from the node X). In 205 Figure 1, we consider a network with all metrics equal to 1 except 206 the metrics on links used by PE1, PE2 and PE3 which are 1000. An 207 easy network capacity planning method is to consider that if the link 208 L (X-B) fails, the traffic actually flowing through L will be spread 209 over the remaining links of X (X-H, X-D, X-A). Considering the IGP 210 metrics, only X-H and X-D can be used in reality to carry the traffic 211 flowing through the link L. As a consequence, the bandwidth of links 212 X-H and X-D is sized according to this rule. We should observe that 213 this capacity planning policy works, however it is not fully 214 accurate. 216 In Figure 1, considering that the source of traffic is only from PE1 217 and PE4, when the link L fails, depending on the convergence speed of 218 the nodes, X may reroute its forwarding entries to the remote PEs 219 onto X-H or X-D; however in a similar timeframe, PE1 will also 220 reroute a subset of its traffic (the subset destined to PE2) out of 221 its nominal path reducing the quantity of traffic received by X. The 222 capacity planning rule presented previously has the drawback of 223 oversizing the network, however it allows to prevent any transient 224 congestion (when for example X reroutes traffic before PE1 does). 226 H --- I --- J 227 | | \ 228 PE4 | | PE3 229 \ | (L) | / 230 A --- X --- B --- G 231 / | | \ 232 PE1 | | PE2 233 \ | | / 234 C --- D --- E --- F 236 Figure 1 238 Based on this assumption, in order to facilitate the operation of 239 FRR, and limit the implementation of local FRR policies, it looks 240 interesting to steer the traffic onto the post-convergence path from 241 the PLR point of view during the FRR phase. In our example, when 242 link L fails, X switches the traffic destined to PE3 and PE2 on the 243 post-convergence paths. This is perfectly inline with the capacity 244 planning rule that was presented before and also inline with the fact 245 X may converge before PE1 (or any other upstream router) and may 246 spread the X-B traffic onto the post-convergence paths rooted at X. 248 It should be noted, that some networks may have a different capacity 249 planning rule, leading to an allocation of less bandwidth on X-H and 250 X-D links. In such a case, using the post-convergence paths rooted 251 at X during FRR may introduce some congestion on X-H and X-D links. 252 However it is important to note, that a transient congestion may 253 possibly happen, even without FRR activated, for instance when X 254 converges before the upstream routers. Operators are still free to 255 use the policy framework defined in [RFC7916] if the usage of the 256 post-convergence paths rooted at the PLR is not suitable. 258 Readers should be aware that FRR protection is pre-computing a backup 259 path to protect against a particular type of failure (link, node, 260 SRLG). When using the post-convergence path as FRR backup path, the 261 computed post-convergence path is the one considering the failure we 262 are protecting against. This means that FRR is using an expected 263 post-convergence path, and this expected post-convergence path may be 264 actually different from the post-convergence path used if the failure 265 that happened is different from the failure FRR was protecting 266 against. As an example, if the operator has implemented a protection 267 against a node failure, the expected post-convergence path used 268 during FRR will be the one considering that the node has failed. 269 However, even if a single link is failing or a set of links is 270 failing (instead of the full node), the node-protecting post- 271 convergence path will be used. The consequence is that the path used 272 during FRR is not optimal with respect to the failure that has 273 actually occurred. 275 Another consideration to take into account is: while using the 276 expected post-convergence path for SR traffic using node segments 277 only (for instance, PE to PE traffic using shortest path) has some 278 advantages, these advantages reduce when SR policies 279 ([I-D.ietf-spring-segment-routing-policy]) are involved. A segment- 280 list used in an SR policy is computed to obey a set of path 281 constraints defined locally at the head-end or centrally in a 282 controller. TI-LFA cannot be aware of such path constraints and 283 there is no reason to expect the TI-LFA backup path protecting one 284 the segments in that segment list to obey those constraints. When SR 285 policies are used and the operator wants to have a backup path which 286 still follows the policy requirements, this backup path should be 287 computed as part of the SR policy in the ingress node (or central 288 controller) and the SR policy should not rely on local protection. 290 Another option could be to use FlexAlgo ([I-D.ietf-lsr-flex-algo]) to 291 express the set of constraints and use a single node segment 292 associated with a FlexAlgo to reach the destination. When using a 293 node segment associated with a FlexAlgo, TI-LFA keeps providing an 294 optimal backup by applying the appropriate set of constraints. The 295 relationship between TI-LFA and the SR-algorithm is detailed in 296 Section 8. 298 Thanks to SR and the combination of Adjacency segments and Node 299 segments, the expression of the expected post-convergence path rooted 300 at the PLR is facilitated and does not create any additional state on 301 intermediate nodes. The easiest way to express the expected post- 302 convergence path in a loop-free manner is to encode it as a list of 303 adjacency segments. However, this may create a long SID list that 304 some hardware may not be able to push. One of the challenges of TI- 305 LFA is to encode the expected post-convergence path by combining 306 adjacency segments and node segments. Each implementation will be 307 free to have its own SID list compression optimization algorithm. 308 This document details the basic concepts that could be used to build 309 the SR backup path as well as the associated dataplane procedures. 311 L ____ 312 S----F--{____}----D 313 /\ | / 314 | | | _______ / 315 |__}---Q{_______} 317 Figure 2: TI-LFA Protection 319 We use Figure 2 to illustrate the TI-LFA approach. 321 The Point of Local Repair (PLR), S, needs to find a node Q (a repair 322 node) that is capable of safely forwarding the traffic to a 323 destination D affected by the failure of the protected link L, a set 324 of links including L (SRLG), or the node F itself. The PLR also 325 needs to find a way to reach Q without being affected by the 326 convergence state of the nodes over the paths it wants to use to 327 reach Q: the PLR needs a loop-free path to reach Q. 329 Section 3 defines the main notations used in the document. They are 330 in line with [RFC5714]. 332 Section 5 suggests to compute the P-Space and Q-Space properties 333 defined in Section 3, for the specific case of nodes lying over the 334 post-convergence paths towards the protected destinations. 336 Using the properties defined in Section 5, Section 6 describes how to 337 compute protection lists that encode a loop-free post-convergence 338 path towards the destination. 340 Section 7 defines the segment operations to be applied by the PLR to 341 ensure consistency with the forwarding state of the repair node. 343 By applying the algorithms specified in this document to actual 344 service providers and large enterprise networks, we provide real life 345 measurements for the number of SIDs used by repair paths. Section 10 346 summarizes these measurements. 348 2.1. Conventions used in this document 350 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 351 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 352 "OPTIONAL" in this document are to be interpreted as described in BCP 353 14 [RFC2119] [RFC8174] when, and only when, they appear in all 354 capitals, as shown here. 356 3. Terminology 358 We define the main notations used in this document as the following. 360 We refer to "old" and "new" topologies as the LSDB state before and 361 after the considered failure. 363 SPT_old(R) is the Shortest Path Tree rooted at node R in the initial 364 state of the network. 366 SPT_new(R, X) is the Shortest Path Tree rooted at node R in the state 367 of the network after the resource X has failed. 369 PLR stands for "Point of Local Repair". It is the router that 370 applies fast traffic restoration after detecting failure in a 371 directly attached link, set of links, and/or node. 373 Similar to [RFC7490], we use the concept of P-Space and Q-Space for 374 TI-LFA. 376 The P-space P(R,X) of a router R w.r.t. a resource X (e.g. a link 377 S-F, a node F, or a SRLG) is the set of routers reachable from R 378 using the pre-convergence shortest paths without any of those paths 379 (including equal-cost path splits) transiting through X. 381 Consider the set of neighbors of a router R and a resource X. 382 Exclude from that set of neighbors that are reachable from R using X. 383 The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the 384 union of the P-spaces of the neighbors in that reduced set of 385 neighbors w.r.t. the resource X. 387 The Q-space Q(R,X) of a router R w.r.t. a resource X is the set of 388 routers from which R can be reached without any path (including 389 equal-cost path splits) transiting through X. 391 A symmetric network is a network such that the IGP metric of each 392 link is the same in both directions of the link. 394 4. Base principle 396 The basic algorithm to compute the repair path is to pre-compute 397 SPT_new(R,X) and for each destination, encode the repair path as a 398 loop-free SID list. One way to provide a loop-free SID list is to 399 use adjacency SIDs only. However, this approach may create very long 400 SID lists that hardware may not be able to handle due to MSD (Maximum 401 SID Depth) limitations. 403 An implementation is free to use any local optimization to provide 404 smaller SID lists by combining Node SIDs and Adjacency SIDs. In 405 addition, the usage of Node-SIDs allow to maximize ECMPs over the 406 backup path. These optimizations are out of scope of this document, 407 however the subsequent sections provide some guidance on how to 408 leverage P-Spaces and Q-Spaces to optimize the size of the SID list. 410 5. Intersecting P-Space and Q-Space with post-convergence paths 412 One of the challenges of defining an SR path following the expected 413 post-convergence path is to reduce the size of the segment list. In 414 order to reduce this segment list, an implementation MAY determine 415 the P-Space/Extended P-Space and Q-Space properties (defined in 416 [RFC7490]) of the nodes along the expected post-convergence path from 417 the PLR to the protected destination and compute an SR-based explicit 418 path from P to Q when they are not adjacent. Such properties will be 419 used in Section 6 to compute the TI-LFA repair list. 421 5.1. Extended P-Space property computation for a resource X, over post- 422 convergence paths 424 We want to determine which nodes on the post-convergence path from 425 the PLR R to the destination D are in the extended P-space of R 426 w.r.t. resource X (X can be a link or a set of links adjacent to the 427 PLR, or a neighbor node of the PLR). 429 This can be found by intersecting the set of nodes belonging to the 430 post-convergence path from R to D, assuming the failure of X, with 431 P'(R, X). 433 5.2. Q-Space property computation for a resource X, over post- 434 convergence paths 436 We want to determine which nodes on the post-convergence path from 437 the PLR R to the destination D are in the Q-Space of destination D 438 w.r.t. resource X (X can be a link or a set of links adjacent to the 439 PLR, or a neighbor node of the PLR). 441 This can be found by intersecting the set of nodes belonging to the 442 post-convergence path from R to D, assuming the failure of X, with 443 Q(D, X). 445 5.3. Scaling considerations when computing Q-Space 447 [RFC7490] raises scaling concerns about computing a Q-Space per 448 destination. Similar concerns may affect TI-LFA computation if an 449 implementation tries to compute a reverse Shortest Path Tree 450 ([RFC7490]) for every destination in the network to determine the 451 Q-Space. It will be up to each implementation to determine the good 452 tradeoff between scaling and accuracy of the optimization. 454 6. TI-LFA Repair path 456 The TI-LFA repair path (RP) consists of an outgoing interface and a 457 list of segments (repair list (RL)) to insert on the SR header. The 458 repair list encodes the explicit post-convergence path to the 459 destination, which avoids the protected resource X and, at the same 460 time, is guaranteed to be loop-free irrespective of the state of FIBs 461 along the nodes belonging to the explicit path. Thus, there is no 462 need for any co-ordination or message exchange between the PLR and 463 any other router in the network. 465 The TI-LFA repair path is found by intersecting P(S,X) and Q(D,X) 466 with the post-convergence path to D and computing the explicit SR- 467 based path EP(P, Q) from P to Q when these nodes are not adjacent 468 along the post convergence path. The TI-LFA repair list is expressed 469 generally as (Node_SID(P), EP(P, Q)). 471 Most often, the TI-LFA repair list has a simpler form, as described 472 in the following sections. Section 10 provides statistics for the 473 number of SIDs in the explicit path to protect against various 474 failures. 476 6.1. FRR path using a direct neighbor 478 When a direct neighbor is in P(S,X) and Q(D,x) and on the post- 479 convergence path, the outgoing interface is set to that neighbor and 480 the repair segment list SHOULD be empty. 482 This is comparable to a post-convergence LFA FRR repair. 484 6.2. FRR path using a PQ node 486 When a remote node R is in P(S,X) and Q(D,x) and on the post- 487 convergence path, the repair list MUST be made of a single node 488 segment to R and the outgoing interface SHOULD be set to the outgoing 489 interface used to reach R. 491 This is comparable to a post-convergence RLFA repair tunnel. 493 6.3. FRR path using a P node and Q node that are adjacent 495 When a node P is in P(S,X) and a node Q is in Q(D,x) and both are on 496 the post-convergence path and both are adjacent to each other, the 497 repair list SHOULD be made of two segments: A node segment to P (to 498 be processed first), followed by an adjacency segment from P to Q. 500 This is comparable to a post-convergence DLFA (LFA with directed 501 forwarding) repair tunnel. 503 6.4. Connecting distant P and Q nodes along post-convergence paths 505 In some cases, there is no adjacent P and Q node along the post- 506 convergence path. As mentioned in Section 4, a list of adjacency 507 SIDs can be used to encode the path between P and Q. However, the 508 PLR can perform additional computations to compute a list of segments 509 that represent a loop-free path from P to Q. How these computations 510 are done is out of scope of this document and is left to 511 implementation. 513 7. Building TI-LFA repair lists 515 The following sections describe how to build the repair lists using 516 the terminology defined in [RFC8402]. The procedures described in 517 Section 7.1 are equally applicable to both SR-MPLS and SRv6 518 dataplane, while the dataplane-specific considerations are described 519 in Section 7.2. 521 7.1. Link protection 523 In this section, we explain how a protecting router S processes the 524 active segment of a packet upon the failure of its primary outgoing 525 interface for the packet, S-F. 527 7.1.1. The active segment is a node segment 529 The active segment MUST be kept on the SR header unchanged and the 530 repair list MUST be added. The active segment becomes the first 531 segment of the repair list. The way the repair list is added depends 532 on the dataplane used (see Section 7.2). 534 7.1.2. The active segment is an adjacency segment 536 We define hereafter the FRR behavior applied by S for any packet 537 received with an active adjacency segment S-F for which protection 538 was enabled. As protection has been enabled for the segment S-F and 539 signaled in the IGP (for instance using protocol extensions from 540 [RFC8667] and [RFC8665]), any SR policy using this segment knows that 541 it may be transiently rerouted out of S-F in case of S-F failure. 543 The simplest approach for link protection of an adjacency segment S-F 544 is to create a repair list that will carry the traffic to F. To do 545 so, one or more "PUSH" operations are performed. If the repair list, 546 while avoiding S-F, terminates on F, S only pushes segments of the 547 repair list. Otherwise, S pushes a node segment of F, followed by 548 the segments of the repair list. For details on the "NEXT" and 549 "PUSH" operations, refer to [RFC8402]. 551 This method which merges back the traffic at the remote end of the 552 adjacency segment has the advantage of keeping as much as possible 553 the traffic on the pre-failure path. As stated in Section 2, when SR 554 policies are involved and a strict compliance of the policy is 555 required, an end-to-end protection should be preferred over a local 556 repair mechanism. However, this method may not provide the expected 557 post-convergence path to the final destination as the expected post- 558 convergence path may not go through F. Another method requires to 559 look to the next segment in the segment list. 561 We distinguish the case where this active segment is followed by 562 another adjacency segment from the case where it is followed by a 563 node segment. 565 7.1.2.1. Protecting [Adjacency, Adjacency] segment lists 567 If the next segment in the list is an Adjacency segment, then the 568 packet has to be conveyed to F. 570 To do so, S MUST apply a "NEXT" operation on Adj(S-F) and then one or 571 more "PUSH" operations. If the repair list, while avoiding S-F, 572 terminates on F, S only pushes the segments of the repair list. 573 Otherwise, S pushes a node segment of F, followed by the segments of 574 the repair list. For details on the "NEXT" and "PUSH" operations, 575 refer to [RFC8402]. 577 Upon failure of S-F, a packet reaching S with a segment list matching 578 [adj(S-F),adj(F-M),...] will thus leave S with a segment list 579 matching [RL(F),node(F),adj(F-M),...], where RL(F) is the repair path 580 for destination F. 582 7.1.2.2. Protecting [Adjacency, Node] segment lists 584 If the next segment in the stack is a node segment, say for node T, 585 the segment list on the packet matches [adj(S-F),node(T),...]. 587 In this case, S MUST apply a "NEXT" operation on the Adjacency 588 segment related to S-F, followed by a "PUSH" of a repair list 589 redirecting the traffic to a node Q, whose path to node segment T is 590 not affected by the failure. 592 Upon failure of S-F, packets reaching S with a segment list matching 593 [adj(S-F), node(T), ...], would leave S with a segment list matching 594 [RL(Q),node(T), ...]. 596 7.2. Dataplane specific considerations 598 7.2.1. MPLS dataplane considerations 600 MPLS dataplane for Segment Routing is described in [RFC8660]. 602 The following dataplane behaviors apply when creating a repair list 603 using an MPLS dataplane: 605 1. If the active segment is a node segment that has been signaled 606 with penultimate hop popping and the repair list ends with an 607 adjacency segment terminating on the tail-end of the active 608 segment, then the active segment MUST be popped before pushing 609 the repair list. 611 2. If the active segment is a node segment but the other conditions 612 in 1. are not met, the active segment MUST be popped then pushed 613 again with a label value computed according to the SRGB of Q, 614 where Q is the endpoint of the repair list. Finally, the repair 615 list MUST be pushed. 617 7.2.2. SRv6 dataplane considerations 619 SRv6 dataplane and programming instructions are described 620 respectively in [RFC8754] and [RFC8986]. 622 The TI-LFA path computation algorithm is the same as in the SR-MPLS 623 dataplane. Note however that the Adjacency SIDs are typically 624 globally routed. In such case, there is no need for a preceding 625 Prefix SID and the resulting repair list is likely shorter. 627 If the traffic is protected at a Transit Node, then an SRv6 SID list 628 is added on the packet to apply the repair list. The addition of the 629 repair list follows the headend behaviors as specified in section 5 630 of [RFC8986]. 632 If the traffic is protected at an SR Segment Endpoint Node, first the 633 Segment Endpoint packet processing is executed. Then the packet is 634 protected as if its were a transit packet. 636 8. TI-LFA and SR algorithms 638 SR allows an operator to bind an algorithm to a prefix SID (as 639 defined in [RFC8402]. The algorithm value dictates how the path to 640 the prefix is computed. The SR default algorithm is known has the 641 "Shortest Path" algorithm. The SR default algorithm allows an 642 operator to override the IGP shortest path by using local policies. 643 When TI-LFA uses Node-SIDs associated with the default algorithm, 644 there is no guarantee that the path will be loop-free as a local 645 policy may have overriden the expected IGP path. As the local 646 policies are defined by the operator, it becomes the responsibility 647 of this operator to ensure that the deployed policies do not affect 648 the TI-LFA deployment. It should be noted that such situation can 649 already happen today with existing mechanisms as remote LFA. 651 [I-D.ietf-lsr-flex-algo] defines a flexible algorithm (FlexAlgo) 652 framework to be associated with Prefix SIDs. FlexAlgo allows a user 653 to associate a constrained path to a Prefix SID rather than using the 654 regular IGP shortest path. An implementation MAY support TI-LFA to 655 protect Node-SIDs associated to a FlexAlgo. In such a case, rather 656 than computing the expected post-convergence path based on the 657 regular SPF, an implementation SHOULD use the constrained SPF 658 algorithm bound to the FlexAlgo (using the Flex Algo Definition) 659 instead of the regular Dijkstra in all the SPF/rSPF computations that 660 are occurring during the TI-LFA computation. This includes the 661 computation of the P-Space and Q-Space as well as the post- 662 convergence path. An implementation MUST only use Node-SIDs bound to 663 the FlexAlgo and/or Adj-SIDs that are unprotected to build the repair 664 list. 666 9. Usage of Adjacency segments in the repair list 668 The repair list of segments computed by TI-LFA may contain one or 669 more adjacency segments. An adjacency segment may be protected or 670 not protected. 672 S --- R2 --- R3 --- R4 --- R5 --- D 673 \ | \ / 674 R7 -- R8 675 | | 676 R9 -- R10 678 Figure 3 680 In Figure 3, all the metrics are equal to 1 except 681 R2-R7,R7-R8,R8-R4,R7-R9 which have a metric of 1000. Considering R2 682 as a PLR to protect against the failure of node R3 for the traffic 683 S->D, the repair list computed by R2 will be [adj(R7-R8),adj(R8-R4)] 684 and the outgoing interface will be to R7. If R3 fails, R2 pushes the 685 repair list onto the incoming packet to D. During the FRR, if R7-R8 686 fails and if TI-LFA has picked a protected adjacency segment for 687 adj(R7-R8), R7 will push an additional repair list onto the packet 688 following the procedures defined in Section 7. 690 To avoid the possibility of this double FRR activation, an 691 implementation of TI-LFA MAY pick only non protected adjacency 692 segments when building the repair list. However, this is important 693 to note that FRR in general is intended to protect for a single pre- 694 planned failure. If the failure that happens is worse than expected 695 or multiple failures happen, FRR is not guaranteed to work. In such 696 a case, fast IGP convergence remains important to restore traffic as 697 quickly as possible. 699 10. Analysis based on real network topologies 701 This section presents analysis performed on real service provider and 702 large enterprise network topologies. The objective of the analysis 703 is to assess the number of SIDs required in an explicit path when the 704 mechanisms described in this document are used to protect against the 705 failure scenarios within the scope of this document. The number of 706 segments described in this section are applicable to instantiating 707 segment routing over the MPLS forwarding plane. 709 The measurement below indicate that for link and local SRLG 710 protection, a 1 SID repair path delivers more than 99% coverage. For 711 node protection a 2 SIDs repair path yields 99% coverage. 713 Table 1 below lists the characteristics of the networks used in our 714 measurements. The number of links refers to the number of 715 "bidirectional" links (not directed edges of the graph). The 716 measurements are carried out as follows: 718 o For each network, the algorithms described in this document are 719 applied to protect all prefixes against link, node, and local SRLG 720 failure 722 o For each prefix, the number of SIDs used by the repair path is 723 recored 725 o The percentage of number of SIDs are listed in Tables 2A/B, 3A/B, 726 and 4A/B 728 The measurements listed in the tables indicate that for link and 729 local SRLG protection, 1 SID repair paths are sufficient to protect 730 more than 99% of the prefix in almost all cases. For node protection 731 2 SIDs repair paths yield 99% coverage. 733 +-------------+------------+------------+------------+------------+ 734 | Network | Nodes | Links |Node-to-Link| SRLG info? | 735 | | | | Ratio | | 736 +-------------+------------+------------+------------+------------+ 737 | T1 | 408 | 665 | 1.63 | Yes | 738 +-------------+------------+------------+------------+------------+ 739 | T2 | 587 | 1083 | 1.84 | No | 740 +-------------+------------+------------+------------+------------+ 741 | T3 | 93 | 401 | 4.31 | Yes | 742 +-------------+------------+------------+------------+------------+ 743 | T4 | 247 | 393 | 1.59 | Yes | 744 +-------------+------------+------------+------------+------------+ 745 | T5 | 34 | 96 | 2.82 | Yes | 746 +-------------+------------+------------+------------+------------+ 747 | T6 | 50 | 78 | 1.56 | No | 748 +-------------+------------+------------+------------+------------+ 749 | T7 | 82 | 293 | 3.57 | No | 750 +-------------+------------+------------+------------+------------+ 751 | T8 | 35 | 41 | 1.17 | Yes | 752 +-------------+------------+------------+------------+------------+ 753 | T9 | 177 | 1371 | 7.74 | Yes | 754 +-------------+------------+------------+------------+------------+ 755 Table 1: Data Set Definition 757 The rest of this section presents the measurements done on the actual 758 topologies. The convention that we use is as follows 759 o 0 SIDs: the calculated repair path starts with a directly 760 connected neighbor that is also a loop free alternate, in which 761 case there is no need to explicitly route the traffic using 762 additional SIDs. This scenario is described in Section 6.1. 764 o 1 SIDs: the repair node is a PQ node, in which case only 1 SID is 765 needed to guarantee loop-freeness. This scenario is covered in 766 Section 6.2. 768 o 2 or more SIDs: The repair path consists of 2 or more SIDs as 769 described in Section 6.3 and Section 6.4. We do not cover the 770 case for 2 SIDs (Section 6.3) separately because there was no 771 granularity in the result. Also we treat the node-SID+adj-SID and 772 node-SID + node-SID the same because they do not differ from the 773 data plane point of view. 775 Table 2A and 2B below summarize the measurements on the number of 776 SIDs needed for link protection 778 +-------------+------------+------------+------------+------------+ 779 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 780 +-------------+------------+------------+------------+------------+ 781 | T1 | 74.3% | 25.3% | 0.5% | 0.0% | 782 +-------------+------------+------------+------------+------------+ 783 | T2 | 81.1% | 18.7% | 0.2% | 0.0% | 784 +-------------+------------+------------+------------+------------+ 785 | T3 | 95.9% | 4.1% | 0.1% | 0.0% | 786 +-------------+------------+------------+------------+------------+ 787 | T4 | 62.5% | 35.7% | 1.8% | 0.0% | 788 +-------------+------------+------------+------------+------------+ 789 | T5 | 85.7% | 14.3% | 0.0% | 0.0% | 790 +-------------+------------+------------+------------+------------+ 791 | T6 | 81.2% | 18.7% | 0.0% | 0.0% | 792 +-------------+------------+------------+------------+------------+ 793 | T7 | 98.9% | 1.1% | 0.0% | 0.0% | 794 +-------------+------------+------------+------------+------------+ 795 | T8 | 94.1% | 5.9% | 0.0% | 0.0% | 796 +-------------+------------+------------+------------+------------+ 797 | T9 | 98.9% | 1.0% | 0.0% | 0.0% | 798 +-------------+------------+------------+------------+------------+ 799 Table 2A: Link protection (repair size distribution) 801 +-------------+------------+------------+------------+------------+ 802 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 803 +-------------+------------+------------+------------+------------+ 804 | T1 | 74.2% | 99.5% | 99.9% | 100.0% | 805 +-------------+------------+------------+------------+------------+ 806 | T2 | 81.1% | 99.8% | 100.0% | 100.0% | 807 +-------------+------------+------------+------------+------------+ 808 | T3 | 95.9% | 99.9% | 100.0% | 100.0% | 809 +-------------+------------+------------+------------+------------+ 810 | T4 | 62.5% | 98.2% | 100.0% | 100.0% | 811 +-------------+------------+------------+------------+------------+ 812 | T5 | 85.7% | 100.0% | 100.0% | 100.0% | 813 +-------------+------------+------------+------------+------------+ 814 | T6 | 81.2% | 99.9% | 100.0% | 100.0% | 815 +-------------+------------+------------+------------+------------+ 816 | T7 | 98,8% | 100.0% | 100.0% | 100.0% | 817 +-------------+------------+------------+------------+------------+ 818 | T8 | 94,1% | 100.0% | 100.0% | 100.0% | 819 +-------------+------------+------------+------------+------------+ 820 | T9 | 98,9% | 100.0% | 100.0% | 100.0% | 821 +-------------+------------+------------+------------+------------+ 822 Table 2B: Link protection repair size cumulative distribution 823 Table 3A and 3B summarize the measurements on the number of SIDs 824 needed for local SRLG protection. 826 +-------------+------------+------------+------------+------------+ 827 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 828 +-------------+------------+------------+------------+------------+ 829 | T1 | 74.2% | 25.3% | 0.5% | 0.0% | 830 +-------------+------------+------------+------------+------------+ 831 | T2 | No SRLG Information | 832 +-------------+------------+------------+------------+------------+ 833 | T3 | 93.6% | 6.3% | 0.0% | 0.0% | 834 +-------------+------------+------------+------------+------------+ 835 | T4 | 62.5% | 35.6% | 1.8% | 0.0% | 836 +-------------+------------+------------+------------+------------+ 837 | T5 | 83.1% | 16.8% | 0.0% | 0.0% | 838 +-------------+------------+------------+------------+------------+ 839 | T6 | No SRLG Information | 840 +-------------+---------------------------------------------------+ 841 | T7 | No SRLG Information | 842 +-------------+------------+------------+------------+------------+ 843 | T8 | 85.2% | 14.8% | 0.0% | 0.0% | 844 +-------------+------------+------------+------------+------------+ 845 | T9 | 98,9% | 1.1% | 0.0% | 0.0% | 846 +-------------+------------+------------+------------+------------+ 847 Table 3A: Local SRLG protection repair size distribution 849 +-------------+------------+------------+------------+------------+ 850 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 851 +-------------+------------+------------+------------+------------+ 852 | T1 | 74.2% | 99.5% | 99.9% | 100.0% | 853 +-------------+------------+------------+------------+------------+ 854 | T2 | No SRLG Information | 855 +-------------+------------+------------+------------+------------+ 856 | T3 | 93.6% | 99.9% | 100.0% | 0.0% | 857 +-------------+------------+------------+------------+------------+ 858 | T4 | 62.5% | 98.2% | 100.0% | 100.0% | 859 +-------------+------------+------------+------------+------------+ 860 | T5 | 83.1% | 100.0% | 100.0% | 100.0% | 861 +-------------+------------+------------+------------+------------+ 862 | T6 | No SRLG Information | 863 +-------------+---------------------------------------------------+ 864 | T7 | No SRLG Information | 865 +-------------+------------+------------+------------+------------+ 866 | T8 | 85.2% | 100.0% | 100.0% | 100.0% | 867 +-------------+------------+------------+------------+------------+ 868 | T9 | 98.9% | 100.0% | 100.0% | 100.0% | 869 +-------------+------------+------------+------------+------------+ 870 Table 3B: Local SRLG protection repair size Cumulative distribution 871 The remaining two tables summarize the measurements on the number of 872 SIDs needed for node protection. 874 +---------+----------+----------+----------+----------+----------+ 875 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 876 +---------+----------+----------+----------+----------+----------+ 877 | T1 | 49.8% | 47.9% | 2.1% | 0.1% | 0.0% | 878 +---------+----------+----------+----------+----------+----------+ 879 | T2 | 36,5% | 59.6% | 3.6% | 0.2% | 0.0% | 880 +---------+----------+----------+----------+----------+----------+ 881 | T3 | 73.3% | 25.6% | 1.1% | 0.0% | 0.0% | 882 +---------+----------+----------+----------+----------+----------+ 883 | T4 | 36.1% | 57.3% | 6.3% | 0.2% | 0.0% | 884 +---------+----------+----------+----------+----------+----------+ 885 | T5 | 73.2% | 26.8% | 0% | 0% | 0% | 886 +---------+----------+----------+----------+----------+----------+ 887 | T6 | 78.3% | 21.3% | 0.3% | 0% | 0% | 888 +---------+----------+----------+----------+----------+----------+ 889 | T7 | 66.1% | 32.8% | 1.1% | 0% | 0% | 890 +---------+----------+----------+----------+----------+----------+ 891 | T8 | 59.7% | 40.2% | 0% | 0% | 0% | 892 +---------+----------+----------+----------+----------+----------+ 893 | T9 | 98.9% | 1.0% | 0% | 0% | 0% | 894 +---------+----------+----------+----------+----------+----------+ 895 Table 4A: Node protection (repair size distribution) 897 +---------+----------+----------+----------+----------+----------+ 898 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 899 +---------+----------+----------+----------+----------+----------+ 900 | T1 | 49.7% | 97.6% | 99.8% | 99.9% | 100% | 901 +---------+----------+----------+----------+----------+----------+ 902 | T2 | 36.5% | 96.1% | 99.7% | 99.9% | 100% | 903 +---------+----------+----------+----------+----------+----------+ 904 | T3 | 73.3% | 98.9% | 99.9% | 100.0% | 100% | 905 +---------+----------+----------+----------+----------+----------+ 906 | T4 | 36.1% | 93.4% | 99.8% | 99.9% | 100% | 907 +---------+----------+----------+----------+----------+----------+ 908 | T5 | 73.2% | 100.0% | 100.0% | 100.0% | 100% | 909 +---------+----------+----------+----------+----------+----------+ 910 | T6 | 78.4% | 99.7% | 100.0% | 100.0% | 100% | 911 +---------+----------+----------+----------+----------+----------+ 912 | T7 | 66.1% | 98.9% | 100.0% | 100.0% | 100% | 913 +---------+----------+----------+----------+----------+----------+ 914 | T8 | 59.7% | 100.0% | 100.0% | 100.0% | 100% | 915 +---------+----------+----------+----------+----------+----------+ 916 | T9 | 98.9% | 100.0% | 100.0% | 100.0% | 100% | 917 +---------+----------+----------+----------+----------+----------+ 918 Table 4B: Node protection (repair size cumulative distribution) 920 11. Security Considerations 922 The techniques described in this document are internal 923 functionalities to a router that result in the ability to guarantee 924 an upper bound on the time taken to restore traffic flow upon the 925 failure of a directly connected link or node. As these techniques 926 steer traffic to the post-convergence path as quickly as possible, 927 this serves to minimize the disruption associated with a local 928 failure which can be seen as a modest security enhancement. The 929 protection mechanisms does not protect external destinations, but 930 rather provides quick restoration for destination that are internal 931 to a routing domain. 933 Security considerations described in [RFC5286] and [RFC7490] apply to 934 this document. Similarly, as the solution described in the document 935 is based on Segment Routing technology, reader should be aware of the 936 security considerations related to this technology ([RFC8402]) and 937 its dataplane instantiations ([RFC8660], [RFC8754] and [RFC8986]). 938 However, this document does not introduce additional security 939 concern. 941 12. IANA Considerations 943 No requirements for IANA 945 13. Contributors 947 In addition to the authors listed on the front page, the following 948 co-authors have also contributed to this document: 950 Francois Clad, Cisco Systems 951 Pablo Camarillo, Cisco Systems 953 14. Acknowledgments 955 We would like to thank Les Ginsberg, Stewart Bryant, Alexander 956 Vainsthein, Chris Bowers, Shraddha Hedge for their valuable comments. 958 15. References 960 15.1. Normative References 962 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 963 Requirement Levels", BCP 14, RFC 2119, 964 DOI 10.17487/RFC2119, March 1997, 965 . 967 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 968 Horneffer, M., and P. Sarkar, "Operational Management of 969 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 970 July 2016, . 972 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 973 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 974 May 2017, . 976 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 977 Decraene, B., Litkowski, S., and R. Shakir, "Segment 978 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 979 July 2018, . 981 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 982 Decraene, B., Litkowski, S., and R. Shakir, "Segment 983 Routing with the MPLS Data Plane", RFC 8660, 984 DOI 10.17487/RFC8660, December 2019, 985 . 987 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 988 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 989 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 990 . 992 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 993 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 994 (SRv6) Network Programming", RFC 8986, 995 DOI 10.17487/RFC8986, February 2021, 996 . 998 15.2. Informative References 1000 [I-D.bashandy-rtgwg-segment-routing-uloop] 1001 Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., 1002 Francois, P., and P. Psenak, "Loop avoidance using Segment 1003 Routing", draft-bashandy-rtgwg-segment-routing-uloop-12 1004 (work in progress), December 2021. 1006 [I-D.ietf-lsr-flex-algo] 1007 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1008 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1009 algo-18 (work in progress), October 2021. 1011 [I-D.ietf-spring-segment-routing-policy] 1012 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1013 P. Mattes, "Segment Routing Policy Architecture", draft- 1014 ietf-spring-segment-routing-policy-14 (work in progress), 1015 October 2021. 1017 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1018 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1019 DOI 10.17487/RFC5286, September 2008, 1020 . 1022 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1023 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1024 . 1026 [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 1027 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 1028 Alternate (LFA) Applicability in Service Provider (SP) 1029 Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, 1030 . 1032 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1033 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1034 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1035 . 1037 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1038 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1039 Extensions for Segment Routing", RFC 8665, 1040 DOI 10.17487/RFC8665, December 2019, 1041 . 1043 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1044 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1045 Extensions for Segment Routing", RFC 8667, 1046 DOI 10.17487/RFC8667, December 2019, 1047 . 1049 Authors' Addresses 1051 Stephane Litkowski 1052 Cisco Systems 1053 France 1055 Email: slitkows@cisco.com 1057 Ahmed Bashandy 1058 Individual 1060 Email: abashandy.ietf@gmail.com 1062 Clarence Filsfils 1063 Cisco Systems 1064 Brussels 1065 Belgium 1067 Email: cfilsfil@cisco.com 1069 Pierre Francois 1070 INSA Lyon 1072 Email: pierre.francois@insa-lyon.fr 1074 Bruno Decraene 1075 Orange 1076 Issy-les-Moulineaux 1077 France 1079 Email: bruno.decraene@orange.com 1081 Daniel Voyer 1082 Bell Canada 1083 Canada 1085 Email: daniel.voyer@bell.ca