idnits 2.16.02
/tmp/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 1293 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 (-24) 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: draft-ietf-rtgwg-mrt-frr-algorithm has been
published as RFC 7811
== Outdated reference: draft-ietf-spring-segment-routing has been published
as RFC 8402
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@