idnits 2.17.1 draft-agv-rtgwg-spring-segment-routing-mrt-03.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 abstract seems to contain references ([RFC7812], [RFC7811]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 29, 2016) is 2796 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 (-03) exists of draft-ietf-isis-mrt-02 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-07 == Outdated reference: A later version (-03) exists of draft-ietf-ospf-mrt-02 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group Anil Kumar S N 3 Internet-Draft Gaurav Agrawal 4 Intended status: Standards Track Vinod Kumar S 5 Expires: March 2, 2017 Huawei Technologies 6 C. Bowers 7 Juniper Networks 8 August 29, 2016 10 Maximally Redundant Trees in Segment Routing 11 draft-agv-rtgwg-spring-segment-routing-mrt-03 13 Abstract 15 [RFC7812] defines an architecture for IP/LDP Fast Reroute using 16 Maximally Redundant Trees (MRT-FRR). This document extends the use 17 of MRT to provide link and node protection for networks that use 18 segment routing. This document makes use of the inherent support in 19 segment routing for associating segments with different algorithms 20 for computing next hops to reach prefixes. It assigns new Segment 21 Routing Algorithms values corresponding to the MRT-Red and MRT-Blue 22 next-hop computations defined in [RFC7811]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 2, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 4. MRT for Segment Routing Network . . . . . . . . . . . . . . . 3 62 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4.2. IGP extensions for MRT . . . . . . . . . . . . . . . . . 4 64 4.3. SR Algorithm value for MRT-Blue and MRT-Red . . . . . . . 4 65 4.4. MRT capability advertisement for SR . . . . . . . . . . . 5 66 4.5. SR MRT SID/Label advertisement . . . . . . . . . . . . . 5 67 4.6. MRT computation for SR . . . . . . . . . . . . . . . . . 6 68 5. MRT-FRR for destination-based and traffic-engineered SR . . . 6 69 6. SR MRT Profile . . . . . . . . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 10.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 MRT is a fast re-route technology that provides 100% coverage for 81 link and nodes failures. This document describes how to use MRT as a 82 FRR technology in a segment routing network. 84 2. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119] 90 3. Terminology 92 Redundant Trees (RT): A pair of trees where the path from any node X 93 to the root R along the first tree is node-disjoint with the path 94 from the same node X to the root along the second tree. These can 95 be computed in 2-connected graphs. 97 Maximally Redundant Trees (MRT): A pair of trees where the path from 98 any node X to the root R along the first tree and the path from 99 the same node X to the root along the second tree share the 100 minimum number of nodes and the minimum number of links. Each 101 such shared node is a cut-vertex. Any shared links are cut-links. 102 Any RT is an MRT but many MRTs are not RTs. The two MRTs are 103 referred to as MRT-Blue and MRT-Red. 105 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used 106 to described the associated forwarding topology and MT-ID. 107 Specifically, MRT-Red is the decreasing MRT where links in the 108 GADAG are taken in the direction from a higher topologically 109 ordered node to a lower one. 111 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 112 used to described the associated forwarding topology and MT-ID. 113 Specifically, MRT-Blue is the increasing MRT where links in the 114 GADAG are taken in the direction from a lower topologically 115 ordered node to a higher one. 117 MRT Island: From the computing router, the set of routers that 118 support a particular MRT profile and are connected via MRT- 119 eligible links. 121 Island Border Router (IBR): A router in the MRT Island that is 122 connected to a router not in the MRT Island and both routers are 123 in a common area or level. 125 Island Neighbor (IN): A router that is not in the MRT Island but is 126 adjacent to an IBR and in the same area/level as the IBR. 128 4. MRT for Segment Routing Network 130 4.1. Overview 132 Segment Routing (SR) allows a flexible definition of end-to-end paths 133 within IGP topologies by encoding paths as sequences of topological 134 sub-paths, called "segments". These segments are advertised by the 135 link-state routing protocols (IS-IS and OSPF). Prefix segments 136 represent an ECMP-aware shortest-path to a prefix (or a node), as per 137 the state of the IGP topology. Adjacency segments represent a hop 138 over a specific adjacency between two nodes in the IGP. 140 MRT Fast Reroute requires that packets to be forwarded not only on 141 the shortest-path tree, but also on two Maximally Redundant Trees 142 (MRTs), referred to as the MRT-Blue and the MRT-Red. A router that 143 experiences a local failure must also have predetermined which 144 alternate to use. The MRT algorithm is defined in [RFC7811]. The 145 Default MRT Profile path calculation uses Lowpoint algorithm to 146 calculate Maximally Redundant Trees. 148 To use MRT in Segment Routing network below mentioned capabilities 149 needs to be incorporated in SR node. 151 1. SR nodes MUST support IGP extensions for MRT. 153 2. SR nodes MUST support MRT-RED and MRT-BLUE Algorithms. 155 3. SR nodes MUST advertise it's MRT capability. 157 4. SR nodes SHOULD send and receive SID/Label for MRT topologies 158 (MRT-RED and MRT-BLUE) for SR segment(s). 160 5. SR nodes MUST support computation of MRTs. 162 4.2. IGP extensions for MRT 164 These extensions are to support the distributed computation of 165 Maximally Redundant Trees (MRT). These extensions indicate the MRT 166 profile(s) each router supports. Different MRT profiles can be 167 defined to support different uses and to allow transition of 168 capabilities. 170 To support MRT for SR, a new SR MRT Profile is defined (as defined in 171 section 5 of this document). IGP extensions for 172 MRT[I-D.ietf-isis-mrt] / [I-D.ietf-ospf-mrt]MUST carry SR MRT 173 profile. 175 4.3. SR Algorithm value for MRT-Blue and MRT-Red 177 Segment routing supports the use of different algorithms for 178 computing paths to reach nodes and prefixes. To accomplish this, 179 every Prefix-SID has a mandatory algorithm field. This Prefix-SID 180 identifies an instruction to forward a packet along the path computed 181 using the algorithm identified in the algorithm field. 183 [I-D.ietf-spring-segment-routing] defines two algorithms, Shortest 184 Path and Strict Shortest Path. 185 [I-D.ietf-isis-segment-routing-extensions] and 186 [I-D.ietf-ospf-segment-routing-extensions] each assign the algorithm 187 values of 0 and 1 to identify these two algorithms. 189 This document defines two additional algorithm values to support MRT- 190 FRR using Segment Routing. The two algorithms correspond to the MRT- 191 Red and MRT-Blue for the Default MRT Profile. 193 4.4. MRT capability advertisement for SR 195 As packets routed on a hop-by-hop basis require that each router 196 compute a shortest-path tree that is consistent, it is necessary for 197 each router to compute the MRT-Blue next hops and MRT-Red next hops 198 in a consistent fashion. For this each SR node needs to know which 199 of the SR nodes in the SR domain supports MRT. This MUST be 200 communicated using SR MRT Capability Advertisement. 202 Both OSPF [I-D.ietf-ospf-segment-routing-extensions] and ISIS 203 [I-D.ietf-isis-segment-routing-extensions] supports segment routing 204 capabilities advertisement. MRT algorithm capabilities need to be 205 advertised in SR-Algorithm TLV for OSPF extension for segment routing 206 and SR-Algorithm Sub-TLV for ISIS extension for segment routing. 208 SR-Algorithm TLV [I-D.ietf-ospf-segment-routing-extensions] 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type | Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Algorithm 1 | Algorithm... | Algorithm n | | 216 +---------------------------------------------------------------+ 217 | | 218 + + 220 SR-Algorithm Sub-TLV[I-D.ietf-isis-segment-routing-extensions] 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 SR node is considered as MRT capable node if it advertises MRT 231 capability in IGP extension of MRT as well as IGP extension of SR. 233 4.5. SR MRT SID/Label advertisement 235 In a link-state IGP domain, an SR-capable IGP node advertises 236 segments for its attached prefixes and adjacencies. These segments 237 are called IGP segments or IGP SIDs. They play a key role in Segment 238 Routing as they enable the expression of any topological path 239 throughout the IGP domain. Such a topological path is either 240 expressed as a single IGP segment or a list of multiple IGP segments. 242 SR nodes supporting MRT MUST advertise two additional labels 243 corresponding to MRT-BLUE and MRT-RED for each prefix segment. 245 These labels are carried as a part of prefix SID sub-tlv (OSPF 246 Section 5 of [I-D.ietf-ospf-segment-routing-extensions], ISIS 247 Section 2.1 of [I-D.ietf-isis-segment-routing-extensions]) with 248 algorithm field set to algorithm value corresponding to the MRT 249 forwarding topology as described in section Section 4.3. 251 4.6. MRT computation for SR 253 An SR node that advertise support for the Segment Routing MRT Profile 254 MUST support MRT-RED and MRT-BLUE forwarding topology creation and 255 support the computation of FRR paths as per the MRT algorithm 256 described in [RFC7811]. 258 5. MRT-FRR for destination-based and traffic-engineered SR 260 In addition to the Prefix-SIDs for Shortest Path algorithm, the IGP 261 distributes Prefix-SIDs for MRT-Red and MRT-Blue. This allows each 262 node to install transit forwarding entries for the MRT-Red and MRT- 263 Blue paths for those prefixes. In normal operation, the traffic for 264 a given destination will be forwarded based on the Shortest Path 265 algorithm Prefix-SID for that destination. Upon detecting a link 266 failure, a node can act as a point-of-local repair (PLR) by 267 forwarding the traffic using either the MRT-Red or MRT-Blue Prefix- 268 SID for the same destination. Following the appropriate MRT path, 269 the traffic will the destination without crossing the failed link or 270 the remote node attached to the failed link, if such a path exists. 272 The description above is independent of the segment routing 273 forwarding plane. With the MRT-Red and MRT-Blue Segment Routing 274 Algorithm values defined in this document, MRT-FRR can provide 275 protection for traffic using either the MPLS or the IPv6 forwarding 276 plane for segment routing. For clarity, we also describe the MRT-FRR 277 mechanism when realized using the MPLS forwarding plane for segment 278 routing. 280 In the MPLS-specific description, each node uses the index 281 information contained in Prefix-SIDs and the SRGBs advertised by its 282 neighbors to install transit forwarding entries for the Shortest 283 Path, MRT-Red path, and MRT-Blue path for each destination prefix. 284 As an example, the transit forwarding entry for a destination prefix 285 on the MRT-Red path is a label swap operation where the both the 286 incoming and outgoing labels correspond to the MRT-Red labels on the 287 MRT-Red path. 289 In the absence of failures, traffic flows on transit forwarding 290 entries corresponding to the Shortest Path algorithm where an 291 incoming Shortest Path label is swapped to an outgoing Shortest Path 292 label for a given destination. Upon the failure of a link, the PLR 293 may change some forwarding entries to swap an incoming Shortest Path 294 label to an outgoing MRT-Red or MRT-Blue label. 296 MRT Prefix Segments are applicable to both destination-based SR as 297 well as traffic-engineered SR. In the case of destination-based SR, 298 the Segment List consists of a single Prefix Segment with an MRT-Red 299 or MRT-Blue algorithm value. In this case Prefix Segment identifies 300 the complete MRT-Red or MRT-Blue path to the destination node or 301 prefix. In the case of traffic-engineered SR, a Prefix Segment with 302 an MRT algorithm value may form part of a larger Segment List. In 303 this case, the MRT Prefix Segment identifies a portion of the entire 304 end-to-end path in the SR domain. That portion of the path 305 corresponds to the MRT-Red or MRT-Blue path for that prefix. 307 6. SR MRT Profile 309 The following set of options defines the SR MRT Profile. The SR MRT 310 Profile is indicated by the MRT Profile ID. 312 MRT Algorithm: MRT Lowpoint algorithm defined in [RFC7811]. 314 MRT-Red SR Algorithm ID: The MRT-Red SR Algorithm ID is indicated by 315 the MRT-Red SR Algorithm ID. 317 MRT-Blue SR Algorithm ID: The MRT-Blue SR Algorithm ID is indicated 318 by the MRT-BLue SR Algorithm ID. 320 GADAG Root Selection Policy: Among the routers in the MRT Island with 321 the lowest numerical value advertised for GADAG Root Selection 322 Priority, an implementation MUST pick the router with the highest 323 Router ID to be the GADAG root. Note that a lower numerical value 324 for GADAG Root Selection Priority indicates a higher preference for 325 selection. 327 Forwarding Mechanisms: MRT SR Label Option 1A 329 Recalculation: Recalculation of MRTs SHOULD occur as described in 330 Section 12.2 of [RFC7812] with SR label. 332 Area/Level Border Behavior: As described in Section 10 of [RFC7812], 333 ABRs/LBRs SHOULD ensure that traffic leaving the area also exits the 334 MRT-Red or MRT-Blue forwarding topology. 336 7. IANA Considerations 338 IANA is requested to allocate a value from the MRT Profile Identifier 339 Registry for the Segment Routing MRT Profile with a value of TDB-1. 341 Value Description Reference 342 ------- ---------------------------------------- ------------ 343 TBD-1 Segment Routing MRT Profile This document 345 Currently, there is no IANA registry defined for SR Algorithm values 346 carried in the Prefix-SID sub-TLV and the SR Algorithm sub-TLV for 347 IS-IS or the Prefix-SID sub-TLV and SR Algorithm TLV for OSPF 348 [I-D.ietf-isis-segment-routing-extensions] and 349 [I-D.ietf-ospf-segment-routing-extensions] define the Segment Routing 350 algorithms for values 0 and 1. 352 This document requests IANA to create a registry entitled "Segment 353 Routing Algorithm Values". This should appear in the IANA registry 354 under a new top-level entry entitled "IGP-Independent Segment Routing 355 Parameters". The initial registry is shown below. 357 Value SR Algorithm References 358 --------------------------------------- 359 0 Shortest Path I-D.ietf-isis-segment-routing-extensions 360 I-D.ietf-ospf-segment-routing-extensions 361 1 Strict Shortest Path I-D.ietf-isis-segment-routing-extensions 362 I-D.ietf-ospf-segment-routing-extensions 363 TBD-2 MRT-Red This document 364 TBD-3 MRT-Blue This document 366 Note to RFC Editor: this section may be removed on publication as an 367 RFC. 369 8. Security Considerations 371 Security consideration of MRT and SR are applicable here. None of 372 the additional security consideration are identified. 374 9. Acknowledgements 376 None 378 10. References 379 10.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 387 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 388 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 389 DOI 10.17487/RFC7811, June 2016, 390 . 392 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 393 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 394 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 395 . 397 10.2. Informative References 399 [I-D.ietf-isis-mrt] 400 Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J. 401 Tantsura, "Intermediate System to Intermediate System (IS- 402 IS) Extensions for Maximally Redundant Trees (MRT)", 403 draft-ietf-isis-mrt-02 (work in progress), May 2016. 405 [I-D.ietf-isis-segment-routing-extensions] 406 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 407 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 408 Extensions for Segment Routing", draft-ietf-isis-segment- 409 routing-extensions-07 (work in progress), June 2016. 411 [I-D.ietf-ospf-mrt] 412 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 413 "OSPF Extensions to Support Maximally Redundant Trees", 414 draft-ietf-ospf-mrt-02 (work in progress), May 2016. 416 [I-D.ietf-ospf-segment-routing-extensions] 417 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 418 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 419 Extensions for Segment Routing", draft-ietf-ospf-segment- 420 routing-extensions-09 (work in progress), July 2016. 422 [I-D.ietf-spring-segment-routing] 423 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 424 and R. Shakir, "Segment Routing Architecture", draft-ietf- 425 spring-segment-routing-09 (work in progress), July 2016. 427 Authors' Addresses 429 Anil Kumar S N 430 Huawei Technologies 431 Near EPIP Industrial Area, Kundalahalli Village 432 Whitefield, Bangalore, Karnataka 560066 433 India 435 Email: anil.ietf@gmail.com 437 Gaurav Agrawal 438 Huawei Technologies 439 Near EPIP Industrial Area, Kundalahalli Village 440 Whitefield, Bangalore, Karnataka 560066 441 India 443 Email: gaurav.agrawal@huawei.com 445 Vinod Kumar S 446 Huawei Technologies 447 Near EPIP Industrial Area, Kundalahalli Village 448 Whitefield, Bangalore, Karnataka 560066 449 India 451 Email: vinods.kumar@huawei.com 453 Chris Bowers 454 Juniper Networks 455 1194 N. Mathilda Ave. 456 Sunnyvale, CA 94089 457 USA 459 Email: cbowers@juniper.net