idnits 2.17.1 draft-bowers-spring-adv-per-algorithm-label-blocks-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 489: '... values, routers MUST determine the la...' RFC 2119 keyword, line 497: '...el-Block sub-TLV MUST NOT be advertise...' RFC 2119 keyword, line 504: '... nodes SHOULD only advertise a node ...' RFC 2119 keyword, line 507: '... SHOULD NOT be advertised in TLV-235...' RFC 2119 keyword, line 509: '...tion 2), then it MUST ignore the recei...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2015) is 3126 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) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-09) exists of draft-ietf-rtgwg-mrt-frr-algorithm-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Bowers 3 Internet-Draft P. Sarkar 4 Intended status: Standards Track H. Gredler 5 Expires: April 7, 2016 Juniper Networks 6 U. Chunduri 7 Ericsson Inc 8 October 5, 2015 10 Advertising Per-Topology and Per-Algorithm Label Blocks 11 draft-bowers-spring-adv-per-algorithm-label-blocks-02 13 Abstract 15 When segment routing is used in a network that is controlled by a 16 link state IGP (such as ISIS or OSPF), each node in the network can 17 be assigned one or more index numbers, known as "node-SIDs". The 18 node-SIDs are unique within the network, and are known to all the 19 nodes in the network. If an ingress node has a data packet to be 20 sent to an egress node, the ingress node may select a node-SID 21 corresponding to the egress node, and "translate" that node-SID to an 22 MPLS label. The MPLS label represents a particular path to the 23 egress node; the path is determined by applying a routing algorithm 24 to a particular view of the network topology and a particular set of 25 metric assignments to the links of that topology. The packet can 26 then be forwarded by pushing the label on the packet's label stack 27 and transmitting the packet to the next hop on the corresponding path 28 to the egress node. This document compares two different procedures 29 for translating a node-SID to the MPLS label that represents a path 30 chosen by a particular algorithm operating on a particular topology. 31 It also specifies the ISIS extensions needed to support one of the 32 procedures (known as the "per-topology/per-algorithm label block" 33 procedure). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 7, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Destination-based forwarding using other algorithms . . . . . 3 70 3. Multi-topology routing . . . . . . . . . . . . . . . . . . . 5 71 4. Example: Adding Nodes when Multiple Algorithms are In Use . . 6 72 5. Proposed configured offset mapping method for assigning per- 73 topology/per-algorithm node-SIDs when using Option 1 . . . . 7 74 6. Flexibility to create easy-to-interpret label values . . . . 9 75 7. Robustness against misconfiguration . . . . . . . . . . . . . 10 76 8. ISIS extensions to encode per-topology/per-algorithm label 77 blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9. OSPF extensions to encode per-topology/per-algorithm label 79 blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10. A note on algorithms and topologies . . . . . . . . . . . . . 12 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 12. Management Considerations . . . . . . . . . . . . . . . . . . 12 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 15.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 [I-D.ietf-spring-segment-routing] describes the segment routing 93 architecture. When segment routing is used in a network that is 94 controlled by a link state IGP (such as ISIS or OSPF), each node in 95 the network can be assigned one or more index numbers, known as 96 "node-SIDs". The node-SIDs are unique within the network, and are 97 known to all the nodes in the network. If an ingress node has a data 98 packet to be sent to an egress node, the ingress node may select a 99 node-SID corresponding to the egress node, and "translate" that node- 100 SID to an MPLS label. The MPLS label represents a particular path to 101 the egress node; the path is determined by applying a routing 102 algorithm to a particular view of the network topology and a 103 particular set of metric assignments to the links of that topology. 104 The packet can then be forwarded by pushing the label on the packet's 105 label stack and transmitting the packet to the next hop on the 106 corresponding path to the egress node. 108 When a particular network is using a single routing algorithm and a 109 single topology, the procedure for translating a node-SID to an MPLS 110 label is straightforward. Figure 1 shows the formula used to 111 translate a node-SID into an MPLS label when the paths are selected 112 by using the default routing algorithm (Dijkstra's shortest path 113 first algorithm) and the default topology. 115 SPF_Label(X,D) = Label_Block(X) + Node_Index(D) 117 D is the destination node 118 X is the next-hop along the path to D 120 Figure 1: Translating Node-SID to Label: The Default Case 122 As a simple example, when the computing node (Y) needs to forward a 123 packet ultimately destined for node D, Y first determines the 124 shortest path next-hop node to reach D, which in this example is X. 125 Y then adds the Node_Index value advertised by D to the Label_Block 126 value advertised by X to determine the label value to apply to the 127 packet before sending it to X. 129 2. Destination-based forwarding using other algorithms 131 Figure 2 shows two options for generalizing the above formula, to 132 determine locally significant labels corresponding to forwarding 133 next-hops computed using other algorithms. 135 Option 1a: per-algorithm node index 136 Label(X,D,A) = Label_Block(X) + Node_Index(D,A) 138 Option 2a: per-algorithm label block 139 Label(X,D,A) = Label_Block(X,A) + Node_Index(D) 141 A is the algorithm for computing destination-based 142 forwarding next-hops 143 D is the destination node 144 X is the next hop along the path to D that is 145 determined by algorithm A 147 Figure 2: Translating Node-SID to Label: Algorithm-Specific Options 149 Suppose router Y needs to forward a packet to node D along a path 150 computed by algorithm A. Using either option, Y determines the next- 151 hop computed by algorithm A to reach D, which in this example is X. 152 Y then needs to figure out the correct label to apply to the packet 153 so that so that X will also understand that the packet is to be sent 154 to node D along a path computed by algorithm A. The two options 155 shown in Figure 2 differ in how Y determines that label value. 157 In Option 1a each node advertises a single label block, but 158 advertises a different node index for each algorithm. Y determines 159 the label value of local significance to X to reach D using algorithm 160 A by adding the Node_Index advertised by node D for algorithm A to 161 the Label_Block advertised by node X. We refer to this as the per- 162 algorithm node index option. 164 In Option 2a each node advertises only a single node index, but 165 advertises a different label block for each algorithm. Y determines 166 the label value of local significance to X to reach D using algorithm 167 A by adding the Node_Index advertised by node D to the Label_Block 168 for algorithm A advertised by node X. We refer to this as the per- 169 algorithm label block option. 171 The extensions currently defined in 172 [I-D.ietf-isis-segment-routing-extensions] and 173 [I-D.ietf-ospf-segment-routing-extensions] specify encodings for 174 Option 1a, the per-algorithm node index option. This draft proposes 175 extensions that can be used to support option 2a, the per-algorithm 176 label block option. However, before discussing those extensions, we 177 generalize the formula in Figure 2 further to take into account 178 multiple topologies. This will allow us to define extensions that 179 address the use of both multiple topologies and multiple algorithms. 181 3. Multi-topology routing 183 The IGP extensions to support multi-topology routing are defined in 184 [RFC4915] for OSPF and [RFC5120] for IS-IS. Figure 3 further 185 generalizes the formulas above to take into account multiple 186 topologies. It shows two options for determining locally significant 187 labels for different topologies and algorithms. 189 Option 1: per-topology / per-algorithm node index 190 Label(X,D,T,A) = Label_Block(X) + Node_Index(D,T,A) 192 Option 2: per-topology / per-algorithm label block 193 Label(X,D,T,A) = Label_Block(X,T,A) + Node_Index(D) 195 T is the topology 196 A is the algorithm for computing destination-based 197 forwarding next-hops 198 D is the destination node 199 X is the next hop along the path to D that is 200 determined by algorithm A for topology T 202 Figure 3: Translating Node-SID to Label: Topology and Algorithm- 203 Specific Options 205 In Option 1 each node advertises a single label block, but advertises 206 a different node index for each combination of topology and algorithm 207 used. In order for Y to determine the label value that tells X to 208 reach D via the path chosen by algorithm A for topology T, Y adds the 209 Node_Index advertised by node D for topology T and algorithm A to the 210 Label_Block advertised by node X. We refer to this as the per- 211 topology/per-algorithm node index option. 213 In Option 2 each node advertises a single node index and a unique 214 label block along for each combination of topology and algorithm 215 used. In order for Y to determine the label value that tells X to 216 reach D via the path chosen by algorithm A for topology T, Y adds the 217 Node_Index advertised by node D to the Label_Block advertised by node 218 X for topology T and algorithm A. We refer to this as the per- 219 topology/per-algorithm label block option. 221 Note that the formulas in Figure 3 can of course be applied even if 222 there is only one algorithm and/or only one topology. For example, 223 if the use case uses multiple topologies but only uses the default 224 shortest path algorithm (algorithm=0), then option 2 can be written 225 as: Label(X,D,T,0) = Label_Block(X,T,0) + Node_Index(D), which is 226 independent of algorithm. Similarly, if the use case only uses the 227 default topology (topology=0) but uses different algorithms, then 228 option 2 can be written as Label(X,D,0,A) = Label_Block(X,0,A) + 229 Node_Index(D). 231 4. Example: Adding Nodes when Multiple Algorithms are In Use 233 The following example illustrates the practical difficulties 234 associated with using the per-topology/per-algorithm node index 235 option alone (option 1 in Figure 3 ). This example is intentionally 236 simplified to illustrate the need for some kind of convention to 237 manage the assignment of the unique node index values required by 238 option 1, even in a simple scenario. The sections below discuss a 239 more complex example, as well as a specific proposal to manage the 240 assignment of unique node index values. This simplified example 241 assumes that the operator does not use multi-topology routing, i.e. 242 that the default topology is used. 244 Suppose an operator has a network with 100 nodes, which we will refer 245 to as R0-R99. The operator assigns the unique node index values 0-99 246 to those nodes for algorithm=0, in order to accomplish shortest path 247 routing based on IGP metrics with SR labels. Each node will need to 248 advertise a label block of size=100. 250 Assume that at some future point in time, the IETF defines 251 algorithm=2 to mean shortest path routing based on latency, and 252 vendors implement this. (See section Section 10 for more discussion 253 of this example.) Suppose that the operator wants to use latency- 254 based SPF routes for some traffic and metric-based SPF routes for 255 other traffic. The operator will need to define a new set of unique 256 node index values for algorithm=2. A reasonable choice would be to 257 assign node index values of 100-199 to R0-R99 for algorithm=2. Each 258 node will now need to advertise a label block of size=200. So far 259 the need for per-algorithm node index values is an annoyance, but not 260 too difficult to deal with. 262 Now assume that the operator needs to add 10 new nodes to the SR 263 domain, specifically nodes R100-R109. Each node will now need to 264 advertise a label block of size=220. The main issue is deciding how 265 to assign per-algorithm node index for the 10 new nodes. One option 266 is to redo the node index numbering scheme so that R0-R109 have node 267 index values 0-109 for algorithm=0 and node index values 110-229 for 268 algorithm=2. However, this requires renumbering existing nodes. The 269 other option is to avoid renumbering of nodes by assigning nodes 270 R100-R109 node index values 200-209 for algorithm=0 and node index 271 values 210-219 for algorithm=1. Each of these approaches has 272 drawbacks. The first requires renumbering existing nodes, while the 273 second is difficult to maintain since there is no obvious 274 relationship between the node index values for different algorithms. 276 In order to reduce the complexity associated with option 1 in this 277 simple example, a certain amount of pre-planning together with some 278 convention for assigning node index values to algorithms or 279 topologies would be useful. Specific proposals for managing unique 280 node index values when using option 1 are discussed below. First 281 however, we illustrate the advantages of option 2 for this simple 282 example. 284 The use of per-algorithm label blocks avoids the problems associated 285 with assigning and maintaining unique node index values for each 286 forwarding algorithm. 288 When the SR domain is initially deployed, R0-R99 can be assigned node 289 index values 0-99, as one would expect. When support for algorithm=1 290 gets added, the operator does not need to assign and configure any 291 new node index values. Instead, the routers automate the process by 292 advertising different label blocks for each forwarding algorithm. 294 When another 10 nodes are added to the SR domain, R100-R109 get 295 assigned node index values 100-109 as one would expect. And the 296 router advertises a label block of size=110 for each algorithm, as 297 one would expect. Adding new nodes in the presence of multiple 298 forwarding algorithms is simplified significantly with the use of 299 per-algorithm label blocks. 301 5. Proposed configured offset mapping method for assigning per- 302 topology/per-algorithm node-SIDs when using Option 1 304 If a network operator uses option 1, which requires the assignment of 305 unique per-topology/per-algorithm node-SIDs, then it is clear that a 306 common convention or methodology would be useful to help assign and 307 maintain those unique node-SIDs. The methodology described in this 308 section represents the authors' understanding of a proposal to manage 309 assignment of node-SIDs when using option 1, as discussed on the 310 SPRING mailing list. 312 The proposed method for managing the assignment of unique node index 313 values for each topology/algorithm pair involves configuring a 314 mapping from each topology/algorithm pair to an offset value. This 315 offset mapping would need to be configured identically on every 316 router in the network. Figure 4 shows the formula for a router Y to 317 compute its own unique node index value for each topology/algorithm 318 pair. Y would then treat those computed node index values as if they 319 were directly configured via CLI or via Netconf/Yang, advertising 320 them into the IGP and installing the appropriate label operations in 321 the FIB. 323 Node_Index(Y,T,A) = Configured_Offset(T,A) + Base_Node_Index(Y) 325 Y is the computing router 326 T is the topology 327 A is the algorithm 329 Figure 4: Proposed configured offset mapping method to manage 330 assignment of unique per-topology/per-algorithm node index values 331 when using Option 1 333 We illustrate the operation of the configured offset mapping method 334 with a specific example. In this example, the operator has a network 335 with 500 nodes, and wants to support four different topologies using 336 different algorithms. The default topology (topology=0) needs to 337 support algorithms 0, 4, and 5. Topology 2 and topology 6 need to 338 support algorithm 0, while topology 7 needs to support algorithm 2. 339 There are a total of six topology/algorithm pairs. In order to avoid 340 renumbering the network in the event of unanticipated increases in 341 the number of nodes or the number of topology/algorithm pairs, the 342 operator sizes the label offsets and overall label block size to 343 accomodate 1000 nodes and 12 topology/algorithm pairs. 345 Figure 5 shows the configuration data required on each of the 500 346 routers using option 1 together with the configured offset mapping 347 method to manage node index assignment. 349 base_node_index=123 350 label_block_size=12000 351 topology=0 algorithm=0 offset=0 352 topology=0 algorithm=4 offset=1000 353 topology=0 algorithm=5 offset=2000 354 topology=2 algorithm=0 offset=3000 355 topology=6 algorithm=0 offset=4000 356 topology=7 algorithm=2 offset=5000 358 Figure 5: Required configuration data using option 1 360 The base_node_index value is the unique node index for a given node, 361 and will thus be different for each node. The other values define 362 the overall size of the label block and associate topology algorithm 363 pairs with an offset value. This set of values must be configured 364 identically across all routers in the network in order avoid 365 advertising duplicate node index values. Advertisement of duplicate 366 node index values would disrupt forwarding. The configuration above 367 would result in R123 computing node index values of 123, 1123, 2123, 368 3123, 4123, and 5123 for the corresponding topology/algorithm pairs. 370 For comparison, Figure 6 shows the configuration data required on 371 each of the 500 routers using option 2. Since the per-topology/per- 372 algorithm label blocks are advertised independently by each node, 373 option 2 requires no additional configuration beyond what is required 374 for default topology shortest path forwarding (topology=0, 375 algorithm=0). 377 node_index=123 378 label_block_size=1000 380 Figure 6: Required configuration data using option 2 382 6. Flexibility to create easy-to-interpret label values 384 For some applications, it may be desirable to arrange things so that 385 the meaning of label values used for forwarding can be readily 386 understood by people trouble-shooting the network. When using the 387 configured offset mapping method with option 1, if one configures a 388 meaningful base value for the single label block, then the configured 389 offset values can also be chosen to provide understandable label 390 values. In the example above with 500 nodes and 6 topology/algorithm 391 pairs, if the single logically advertised label block consists of a 392 single numerically contiguous label block from 20000 through 31999 393 across all routers in the network, then the label values 394 corresponding to forwarding to R123 using different topology/ 395 algorithm pairs will be meaningful to a people. They will be 20123, 396 21123, 22123, 23123, 24123, and 25123 for the corresponding topology/ 397 algorithm pairs, so an operator who remembers the mapping between 398 topology/algorithm pair and offset can tell that 25123 is the label 399 corresponding to topology=7, algorithm=2, node=123. 401 When using option 2 (per-topology/per-algorithm label blocks) and 402 requiring that the topology, algorithm, and node associated with a 403 label value be easy to interpret, each topology/algorithm pair needs 404 to have an associated label_block_base configured on every router. 405 Figure 7 show an example configuration of a mapping from topology/ 406 algorithm pairs to label_block_base values. 408 node_index=123 409 label_block_size=1000 410 topology=0 algorithm=0 label_block_base=100000 411 topology=0 algorithm=4 label_block_base=104000 412 topology=0 algorithm=5 label_block_base=105000 413 topology=2 algorithm=0 label_block_base=120000 414 topology=6 algorithm=0 label_block_base=160000 415 topology=7 algorithm=2 label_block_base=172000 417 Figure 7: Configuration data for 500 node example with option 2, 419 Note in this example that we have taken advantage of the additional 420 flexibility of option 2 to create label values that are more readable 421 than from option 1. In this example, a first digit of "1" indicates 422 that this is a SPRING node label. The second and third digits are 423 readable as the topology and algorithm, while the last three digits 424 encode the node number. So 172123 would indicate the node label for 425 topology=7, algorithm=2, node=123. 427 In the above example, we have illustrated the flexibility of option 2 428 to create more readable labels in a hypothetical network with no 429 constraints on label space. However, it is likely that in a multi- 430 vendor network with multiple generations of hardware supporting 431 different MPLS applications there will exist constraints regarding 432 the location and size of contiguous label blocks for use by SPRING. 433 This would impose constraints on one's ability to construct readable 434 label values using option 1 with the configured offset mapping. 435 Option 2 provides more flexibility to construct easy-to-interpret 436 label values in such a network. 438 7. Robustness against misconfiguration 440 Option 2 is much more robust against misconfiguration than is option 441 1. This is true both in scenarios that require easy-to-interpret 442 label values and in scenarios that do not. 444 In the simple case where the application does not require easy-to- 445 interpret label values, option 2 has clear advantages over option 1 446 in terms of robustness again misconfiguration. Option 1 requires 447 identical offset mapping configurations on all routers for proper 448 forwarding. Option 2 requires no configuration, so there is nothing 449 to misconfigure. 451 In scenarios requiring easy-to-interpret label values, where option 2 452 requires a label_block_base mapping configuration, option 2 is still 453 more robust against misconfiguration than option 1. Misconfiguration 454 of the label_block_base mapping in option 2 does not affect 455 forwarding. The explicit advertisement of the per-topology/per- 456 algorithm label blocks ensures that forwarding will continue to work 457 properly. 459 8. ISIS extensions to encode per-topology/per-algorithm label blocks 461 Below is a concrete proposal for encoding per-topology/per-algorithm 462 label blocks in ISIS compatible with the encodings in 463 [I-D.ietf-isis-segment-routing-extensions]. 465 The newly-defined Topology-Algorithm-Label-Block sub-TLV is shown in 466 Figure 8. It is carried in the IS-IS Router Capability TLV-242. It 467 contains a 12-bit MT-ID field as well as an 8-bit Algorithm field 468 which associates the SRGB Descriptor entries carried in the sub-TLV 469 with a particular topology and algorithm. Otherwise, the structure 470 and interpretation of the Topology-Algorithm-Label-Block sub-TLV is 471 identical to that of the SR-Capabilities sub-TLV defined in section 472 3.1 of [I-D.ietf-isis-segment-routing-extensions]. 474 0 1 2 3 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type | Length |R|R|R|R| MT-ID | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Algorithm | Flags | One or more | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | SRGB Descriptor entries (variable) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 8: Topology-Algorithm-Label-Block sub-TLV 486 A single network must use either option 1 or option 2 for all 487 routers. Mixed mode operation is not supported. When the Topology- 488 Algorithm-Label-Block sub-TLV is present with a given pair of 489 topology and algorithm values, routers MUST determine the label 490 values associated with that topology/algorithm pair using the per- 491 topology/per-algorithm label block method and the concatenated label 492 block carried by the Topology-Algorithm-Label-Block sub-TLV. The 493 node indices used in this calculation are those carried in Node-SID 494 advertisements with algorithm value=0 in TLV-135(IPv4) or TLV- 495 236(IPv6). 497 The Topology-Algorithm-Label-Block sub-TLV MUST NOT be advertised 498 with both MT-ID=0 and Algorithm value=0. In this way, the 499 concatenated label block used to compute the label values for the 500 default topology and algorithm=0 can only be carried by the SR 501 Capabilities sub-TLV. 503 When using the Topology-Algorithm-Label-Block sub-TLV in a network, 504 nodes SHOULD only advertise a node index value corresponding to 505 algorithm=0 in Node-SID advertisements in TLV-135(IPv4) and/or TLV- 506 236(IPv6). Node index values (with algorithm=0 or any other value) 507 SHOULD NOT be advertised in TLV-235(MT-IPv4) and TLV-237(MT-IPv6). 508 If a node originates the Topology-Algorithm-Label-Block sub-TLV 509 (meaning that it supports option 2), then it MUST ignore the receipt 510 of node indices for non-zero algorithms in TLV-135 and TLV-236 and 511 any node index values in TLV-235 and TLV-237. 513 9. OSPF extensions to encode per-topology/per-algorithm label blocks 515 OSPF extensions to encode per-topology/per-algorithm label blocks 516 will be provided in a future version of this draft. 518 10. A note on algorithms and topologies 520 The example given in Section 4 supposes that at some point in the 521 future the IETF defines algorithm=2 to mean shortest path routing 522 based on latency. This simple example was chosen since it is easy to 523 understand. However, the same result could also have been achieved 524 by defining a second topology which uses latency as the metric for 525 that topology, and running the default SPF algorithm on that second 526 topology. 528 In general, when using other algorithms for computing next-hops for 529 destination-based forwarding, it is not possible to achieve the same 530 results by simply defining a new topology with modified metrics and 531 running the default SPF algorithm. An example of such an algorithm 532 is that used to compute Maximally Redundant Trees (MRTs), as defined 533 in [I-D.ietf-rtgwg-mrt-frr-algorithm]. 535 11. IANA Considerations 537 This document requests the following registration in the "sub-TLVs 538 for TLV 242" registry. 540 Value: TBA (suggested value 20) 542 Description: Topology-Algorithm-Label-Block 544 Reference: This document (Section 8) 546 12. Management Considerations 548 This document proposes the use of per-topology/per-algorithm label 549 blocks (option 2) to support destination-based forwarding along next- 550 hops computed using different algorithms for different topologies. 552 The automated advertisement of per-topology/per-algorithm label 553 blocks significantly simplifies network management compared to 554 configuration and maintenance of unique per-topology/per-algorithm 555 node indices. 557 13. Security Considerations 559 TBD 561 14. Acknowledgements 563 The authors thank John Scudder and Eric Rosen for their helpful 564 review of this document and suggestions. 566 15. References 568 15.1. Normative References 570 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 571 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 572 RFC 4915, DOI 10.17487/RFC4915, June 2007, 573 . 575 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 576 Topology (MT) Routing in Intermediate System to 577 Intermediate Systems (IS-ISs)", RFC 5120, 578 DOI 10.17487/RFC5120, February 2008, 579 . 581 15.2. Informative References 583 [I-D.ietf-isis-segment-routing-extensions] 584 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 585 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 586 Extensions for Segment Routing", draft-ietf-isis-segment- 587 routing-extensions-05 (work in progress), June 2015. 589 [I-D.ietf-ospf-segment-routing-extensions] 590 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 591 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 592 Extensions for Segment Routing", draft-ietf-ospf-segment- 593 routing-extensions-05 (work in progress), June 2015. 595 [I-D.ietf-rtgwg-mrt-frr-algorithm] 596 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 597 Gopalan, "Algorithms for computing Maximally Redundant 598 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 599 algorithm-05 (work in progress), July 2015. 601 [I-D.ietf-spring-segment-routing] 602 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 603 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 604 ietf-spring-segment-routing-04 (work in progress), July 605 2015. 607 Authors' Addresses 609 Chris Bowers 610 Juniper Networks 611 1194 N. Mathilda Ave. 612 Sunnyvale, CA 94089 613 US 615 Email: cbowers@juniper.net 617 Pushpasis Sarkar 618 Juniper Networks 619 Embassy Business Park 620 Bangalore, KA 560093 621 India 623 Email: psarkar@juniper.net 625 Hannes Gredler 626 Juniper Networks 627 1194 N. Mathilda Ave. 628 Sunnyvale, CA 94089 629 US 631 Email: hannes@juniper.net 633 Uma Chunduri 634 Ericsson Inc 635 300 Holger Way 636 San Jose, CA 95134 637 US 639 Email: uma.chunduri@ericsson.com@