idnits 2.17.1 draft-agv-rtgwg-spring-segment-routing-mrt-00.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 ([I-D.atlas-rtgwg-mrt-mc-arch]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 9, 2015) is 3084 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) == Unused Reference: 'I-D.ietf-rtgwg-mrt-frr-algorithm' is defined on line 208, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-mrt-frr-architecture' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 222, but no explicit reference was found in the text == Unused Reference: 'RFC5561' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'RFC6420' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'RFC7307' is defined on line 237, but no explicit reference was found in the text == Unused Reference: 'I-D.atlas-rtgwg-mrt-mc-arch' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-mrt' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-mrt' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'I-D.wijnands-mpls-mldp-node-protection' is defined on line 262, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-05 == Outdated reference: A later version (-03) exists of draft-ietf-isis-mrt-00 == Outdated reference: A later version (-03) exists of draft-ietf-ospf-mrt-00 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Anil Kumar S N 3 INTERNET-DRAFT Gaurav Agrawal 4 Intended Status: Standard Track Vinod Kumar S 5 Expires: April 11, 2016 Huawei Technologies India 6 October 9, 2015 8 Maximally Redundant Trees in Segment Routing 9 draft-agv-rtgwg-spring-segment-routing-mrt-00 11 Abstract 13 This document presents a Fast Reroute (FRR) approach aimed at 14 providing link and node protection of node and adjacency segments 15 within the Segment Routing (SR) framework. This FRR behavior builds 16 on Maximally Redundant Trees (MRT) FRR algorithm [I-D.atlas-rtgwg- 17 mrt-mc-arch]. 19 Fast-Reroute with Maximally Redundant Trees (MRT-FRR) using 20 Segment routing is a technology that gives link-protection and node- 21 protection with 100% coverage in any network topology that is still 22 connected after the failure. MRT is computational efficient. For any 23 router in the network, the MRT computation is less than the LFA 24 computation for a node with three or more neighbors in SR domain (Ex: 25 Topology Independent Fast Reroute). 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Standard Terminology . . . . . . . . . . . . . . . . . . . . 3 67 2. Draft Specific Terminology . . . . . . . . . . . . . . . . . . 3 68 3. Overview of SR Signaling for MRT . . . . . . . . . . . . . . . 5 69 4. Protecting segments . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. The top segment is a node segment . . . . . . . . . . . . . 5 71 4.1. The top segment is an adjacency segment . . . . . . . . . . 5 72 5. Requirements for SR MRT implementation . . . . . . . . . . . . 6 73 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 74 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 75 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.1 Normative References . . . . . . . . . . . . . . . . . . . 7 77 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1 Introduction 82 SR MRT FRR is one among the local repair mechanisms for Segment 83 routing network. Another well known local repair mechanism for SR is 84 Topology Independent Fast Reroute which is also capable of restoring 85 end-to-end connectivity in case of a failure of a link or a node, 86 with guaranteed coverage properties. MRT also provides 100% network 87 failure coverage. The advantage of MRT over TI-LFA would be the 88 computation complexities involved in MRT is much lesser then TI-LFA. 89 MRT is best suited for access/aggregate ring network or low end 90 devices which has low computing capacity. 92 1.1 Standard Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Draft Specific Terminology 100 For ease of reading, some of the terminology defined in [I-D.ietf- 101 rtgwg-mrt-frr-architecture] is repeated here. 103 Redundant Trees (RT): A pair of trees where the path from any node 104 X to the root R along the first tree is node-disjoint with the path 105 from the same node X to the root along the second tree. These can be 106 computed in 2-connected graphs. 108 Maximally Redundant Trees (MRT): A pair of trees where the path 109 from any node X to the root R along the first tree and the path from 110 the same node X to the root along the second tree share the minimum 111 number of nodes and the minimum number of links. Each such shared 112 node is a cut-vertex. Any shared links are cut-links. Any RT is an 113 MRT but many MRTs are not RTs. The two MRTs are referred to as MRT- 114 Blue and MRT-Red. 116 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 117 used to described the associated forwarding topology and MT-ID. 118 Specifically, MRT-Red is the decreasing MRT where links in the GADAG 119 are taken in the direction from a higher topologically ordered node 120 to a lower one. 122 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 123 used to described the associated forwarding topology and MT-ID. 124 Specifically, MRT-Blue is the increasing MRT where links in the GADAG 125 are taken in the direction from a lower topologically ordered node to 126 a higher one. 128 Rainbow MRT MT-ID: It is useful to have an MT-ID that refers to the 129 multiple MRT topologies and to the default topology. This is 130 referred to as the Rainbow MRT MT-ID and is used by LDP to reduce 131 signaling and permit the same label to always be advertised to all 132 peers for the same (MT-ID, Prefix). 134 MRT Island: From the computing router, the set of routers that 135 support a particular MRT profile and are connected via MRT- eligible 136 links. 138 Island Border Router (IBR): A router in the MRT Island that is 139 connected to a router not in the MRT Island and both routers are in a 140 common area or level. 142 Island Neighbor (IN): A router that is not in the MRT Island but is 143 adjacent to an IBR and in the same area/level as the IBR.. 145 3. Overview of SR Signaling for MRT 147 To extend MRT support to Segment routing following requirement 148 need to be achieved : 150 1. SR MRT Capabilities must be advertised using IGP extension for SR 151 MRT. Also SR MRT capabilities must be in sync with IGP specific MRT 152 capabilities advertisement. If the peer has not advertised the SR MRT 153 capability, then it indicates that LSR does not support MRT 154 procedures. 156 2. As specified in MRT Architecture draft-ietf-rtgwg-mrt-frr- 157 architecture, both Option 1A and Option 1B can be used for the 158 implementation of SR MRT. 160 For Option 1A, two additional Prefix SID's/Label for RED and BLUE MT 161 must be advertised in addition to default prefix SID/Label. The IGP 162 extension carrying prefix SID for RED and BLUE MT must have 163 corresponding MT-ID allocated by IANA for default MRT profile. 165 For Option 1B, Global Unique Context SID/Label for Red & Blue as 166 topology identifier must be used. 168 4. Protecting segments 170 In this section, we explain how a protecting router processes the 171 label stack of a packet upon the failure of its interface. 173 The behavior depends on the type of top segment in SR label stack to 174 be protected. Its assumed the MRT algorithm is run prior to interface 175 failure and alternate is selected as per the algorithm. The alternate 176 segment could be MRT-RED label or MRT Blue label of Next/Next-to-Next 177 Hop depending on the scenario. 179 4.1. The top segment is a node segment The current SR Label Stack is 180 kept intact. The alternate segment is pushed at the top of SR label 181 stack and continue forwarding the packet as per updated label stack. 183 4.1. The top segment is an adjacency segment The top adjacency label in 184 the SR label stack representing the failed interface is popped & the 185 alternate segment is pushed at the top of SR Label stack and contineu 186 forwarding the packet as per updated label stack. 188 5. Requirements for SR MRT implementation 190 REQ1 : IGP Extension to carry the Segment Routing Node MRT Capability 191 in addition to exiting IGP extension carrying IGP MRT Capability 193 REQ2 : IGP Extension to carry Red & Blue MRT SR Segments in addition 194 to existing Default SR Segment 196 3 Security Considerations 198 None of the security consideration are identified 200 4 IANA Considerations 202 None of the IANA consideration are identified 204 5 References 206 5.1 Normative References 208 [I-D.ietf-rtgwg-mrt-frr-algorithm] 210 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 211 Gopalan, "Algorithms for computing Maximally Redundant 212 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 213 algorithm-05 (work in progress), July 2015. 215 [I-D.ietf-rtgwg-mrt-frr-architecture] 216 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 217 A., Tantsura, J., and R. White, "An Architecture for IP/ 218 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 219 ietf-rtgwg-mrt-frr-architecture-05 (work in progress), 220 January 2015. 222 [RFC5036] 223 Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 224 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 225 October 2007, . 227 [RFC5561] 228 Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 229 Le Roux, "LDP Capabilities", RFC 5561, DOI 230 10.17487/RFC5561, July 2009, . 232 [RFC6420] 233 Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 234 Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, 235 . 237 [RFC7307] 238 Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 239 King, "LDP Extensions for Multi-Topology", RFC 7307, DOI 240 10.17487/RFC7307, July 2014, . 243 5.2. Informative References 245 [I-D.atlas-rtgwg-mrt-mc-arch] 246 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 247 Envedi, "An Architecture for Multicast Protection Using 248 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 249 arch-02 (work in progress), July 2013. 251 [I-D.ietf-isis-mrt] 252 Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. 253 Tantsura, "Intermediate System to Intermediate System (IS- 254 IS) Extensions for Maximally Redundant Trees (MRT)", 255 draft-ietf-isis-mrt-00 (work in progress), February 2015. 257 [I-D.ietf-ospf-mrt] 258 Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, 259 "OSPF Extensions to Support Maximally Redundant Trees", 260 draft-ietf-ospf-mrt-00 (work in progress), January 2015. 262 [I-D.wijnands-mpls-mldp-node-protection] 263 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 264 A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- 265 mpls-mldp-node-protection-04 (work in progress), June 266 2013. 268 [RFC2119] 269 Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, DOI 271 10.17487/RFC2119, March 1997, . 274 Authors' Addresses 276 Anil Kumar S N 277 Huawei Technologies India Pvt. Ltd, 278 Near EPIP Industrial Area, 279 Kundalahalli Village, 280 Whitefield, 281 Bangalore - 560037 283 EMail: anil.sn@huawei.com 285 Gaurav Agrawal 286 Huawei Technologies India Pvt. Ltd, 287 Near EPIP Industrial Area, 288 Kundalahalli Village, 289 Whitefield, 290 Bangalore - 560037 292 EMail: gaurav.agrawal@huawei.com 294 Vinod Kumar S 295 Huawei Technologies India Pvt. Ltd, 296 Near EPIP Industrial Area, 297 Kundalahalli Village, 298 Whitefield, 299 Bangalore - 560037 301 EMail: vinods.kumar@huawei.com