idnits 2.17.00 (12 Aug 2021) /tmp/idnits41033/draft-ali-ccamp-extended-srlg-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 169 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC4202]), 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 (February 18, 2013) is 3372 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DRAFT-SRLG-INFERENCE' is mentioned on line 119, but not defined Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: August 17, 2013 Ori Gerstel 6 Stewart Bryant 7 Matt Hartley 8 Cisco Systems 9 February 18, 2013 11 Extended Encoding Scheme for Shared List Link Group (SRLG) 12 draft-ali-ccamp-extended-srlg-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the provisions 17 of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF). Note that other groups may also distribute working 21 documents as Internet-Drafts. The list of current Internet-Drafts is at 22 http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months and 25 may be updated, replaced, or obsoleted by other documents at any time. It 26 is inappropriate to use Internet-Drafts as reference material or to cite 27 them other than as "work in progress." 29 This Internet-Draft will expire on August 17, 2013. 31 Copyright Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the document 34 authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 37 Relating to IETF Documents (http://trustee.ietf.org/license-info) in 38 effect on the date of publication of this document. Please review these 39 documents carefully, as they describe your rights and restrictions with 40 respect to this document. Code Components extracted from this document 41 must include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as described 43 in the Simplified BSD License. 45 This document may contain material from IETF Documents or IETF 46 Contributions published or made publicly available before November 10, 47 2008. The person(s) controlling the copyright in some of this material 48 may not have granted the IETF Trust the right to allow modifications of 49 ID draft-ali-ccamp-extended-srlg-00.txt 51 such material outside the IETF Standards Process. Without obtaining an 52 adequate license from the person(s) controlling the copyright in such 53 materials, this document may not be modified outside the IETF Standards 54 Process, and derivative works of it may not be created outside the IETF 55 Standards Process, except to format it for publication as an RFC or to 56 translate it into languages other than English. 58 Abstract 60 SRLGs play a key role in routing resiliency and capacity planning of 61 multi-domain and multi-layer networks. Notion of SRLG are used to select a 62 backup path that is disjoint from the primary path, to ensure disjointness 63 of circuits and to avoid catastrophic partitioning outages. 65 In the current specifications, SRLG is identified as a 32 bit number that 66 is unique within an IGP domain [RFC4202]. There are many limitations to 67 this approach of encoding SRLGs, especially in a multi-layer network. This 68 draft outlines these limitations and suggests components of extended SRLG 69 encoding scheme to address them. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 Table of Contents 79 Copyright Notice.....................................................1 80 1. Introduction......................................................3 81 2. Requirements......................................................3 82 2.1. SRLG Scaling..............................................3 83 2.2. Global SRLG Identification................................4 84 2.3. Risk Management...........................................4 85 3. Components of Extended SRLG.......................................5 86 3.1. SRLG Filtration...........................................5 87 3.2. Globally Unique SRLGs.....................................6 88 3.3. SRLG Risk Management......................................6 89 4. Extended SRLG Encoding............................................6 90 5. Protocols extensions for extended SRLG Encoding...................7 91 6. Security Considerations...........................................7 92 7. IANA Considerations...............................................7 93 8. Acknowledgments...................................................7 94 9. References........................................................7 95 9.1. Normative References......................................7 96 9.2. Informative References....................................8 98 ID draft-ali-ccamp-extended-srlg-00.txt 100 1. Introduction 102 [RFC4202] defines notion of Shared Risk Link Group (SRLG). OSPF and IS-IS 103 extension for flooding SRLGs are defined in [RFC4203] and [RFC5307], 104 respectively. RSVP-TE signaling extensions for SRLG exclusion and recording 105 are defined in [RFC4874] and [DRAFT-SRLG-RECORDING], respectively. 107 In current specifications, SRLG is identified as a 32 bit number that is 108 unique within an IGP domain. There are many limitations to this approach for 109 encoding SRLGs, especially in multi-domain and multi-layer networks. Section2 110 outlines these restrictions and states the associated requirements. Section 3 111 outlines components of the extended SRLG encoding format to address these 112 requirements. The extended SRLG encoding format and the associated protocols 113 extension(s) are intentionally left for a future version/ companion 114 document(s). 116 2. Requirements 118 The section outlines the requirements for extending SRLG beyond an IGP domain 119 scoped 32 bit number. Some of these requirements are also noted in [DRAFT- 120 SRLG-INFERENCE]. 122 2.1. SRLG Scaling 124 A zealous operator could assign an SRLG for each risk, including (but not 125 limited to) a building, a floor of a building, a bridge, a side of a rail- 126 track, a side of a highway, and an amplifier. This operator could easily have 127 hundreds of SRLGs for Label Switch Paths (LSPs) transiting domain it operates. 128 Similarly, there are technologies (e.g., DWDM) where it is possible to have 129 hundreds of SRLGs associated with LSPs using such underlying technology. 131 This presents a scaling issue with operations of the network, e.g., during 132 constrained-based path computation of intra-domain LSPs. This also presents a 133 scaling issue when such networks are used in multi-domain and multi-layer 134 environment, e.g., in IP over DWDM network, there may be hundreds of SRLGs 135 along a given IP/ MPLS link (inherited from underlying DWDM LSP). It may not 136 scale for the IP/ MPLS layer to learn hundreds of SRLGs per link and flood 137 them into its IGP database. This may impact flooding speed, topology database 138 size and especially constrained-based path computation complexity and 139 performance. 141 In the light of the above, finding mechanism(s) to scale SRLG is a requirement 142 for GMPLS networks, especially in inter-domain/ inter-layer environment. 144 ID draft-ali-ccamp-extended-srlg-00.txt 146 2.2. Global SRLG Identification 148 Currently SRLGs are defined and supported within domains. This limits the 149 usefulness of SRLGs in an inter-domain environment, as elaborated in the 150 following cases. 152 - There are cases where two different Service Providers (SPs) may be sharing 153 the same fate (facility) for TE links within domains administrated by them. 154 For example, if a client Service Provider SP-C leases two LSPs LSP1 and 155 LSP2 respectively from two server SPs SP-S1 and SP-S2 who themselves lease 156 fibers from the same submarine duct, the SP-C would like to know when the 157 two LSPs LSP1 and LSP2 share the same submarine risk. With current 158 definition of SRLGs this is not possible. This is because SP-S1 uses an 159 SRLG numbering completely independent from SP-S2. For example, SP-S1 might 160 identify the submarine risk as SRLG23 while SP-S2 identifies it as SRLG47. 161 Even if client SP (SP-C) is able to discover SRLGs along LSP1 and LSP2 162 (e.g., using SRLG recording [DRAFT-SRLG-RECORDING] SP-C learns that the 163 LSP1 is exposed to SRLG23 and LSP2 exposed to SRLG47), the SP-C problem is 164 not resolved: it has no way to know that LSP1 and LSP2 are actually sharing 165 the same risk. 167 - If SP-C in the above example would like to request LSP2 to be SRLG diverse 168 from LSP1 using SRLG recording [DRAFT-SRLG-RECORDING] and SRLG XRO/ EXRS 169 [RFC4874], there is no guarantee that LSP2 route is SRLG diverse. This is 170 because knowing that LSP1 is exposed to SRLG23, SP-C cannot realize a path 171 from SP-S2 which is disjoint from SRLG23 of SP-S1 (as SRLG23 means 172 something else for SP-S2). Similarly, SRLG inclusion also does not work 173 using the current SRLG encoding scheme. 175 - At present, SRLG administration is completely up to the SPs. Therefore, 176 SRLG values in an inter-domain environment may collide. Considering the 177 above example, SP-S1 may have assigned SRLG12 to a resource used by LSP1, 178 whereas client SP-C may already be using SRLG12 to identify a different 179 resource in its network. Even though these two resources may not share any 180 risk, they are not SRLG diverse (assumed to share risk in GMPLS control 181 plane). 183 In the light of the above, finding mechanism(s) to maintain consistency of 184 SRLG in an inter-domain environment is a requirement. 186 2.3. Risk Management 188 Not all resources in a network have same level of availability. Some resources 189 are more prone to failures, e.g., a fiber trunk running close to utility wires 190 is more likely to suffer from accidental cuts than a fiber trunk running in 191 isolation. Metro links are more susceptible to cuts than rural links, and 192 aerial fiber is susceptible to storm induced outages. 194 ID draft-ali-ccamp-extended-srlg-00.txt 196 Consider the example where a client Service Provider (SP) SP-C leases LSP1 197 from server SP (SP-S1). Availability of LSP1 is typically part of service 198 level agreement (SLA) between SP-C and SP-S1, e.g., SP-C may request 99.999% 199 (five-nines) of availability. Given high availability requirement for LSP1, 200 SP-S1 needs to route LSP1 such that it uses resources with better than 99.999% 201 availability. Furthermore, given a set of underlying resources, SP1 should 202 also be able to estimate availability of LSP1 connection. How availability of 203 a connection given availability of its underlying resources is estimated is 204 beyond the scope of this document but, if availability is represented as a 205 number between 0 and 1, a multiply function can be used for this calculation. 207 In the light of the above, finding mechanism(s) to quantify risk associated 208 with a resource is a requirement. 210 3. Components of Extended SRLG 212 This section outline components that form basis for extended SRLG encoding 213 scheme. 215 3.1. SRLG Filtration 217 A way to address SRLG scaling requirement mentioned in Section 2 is to 218 associate a priority field to the SRLG and use it as a mechanism to observe 219 SRLG filtering. For example, in a multi-layer network, only higher priority 220 SRLGs may be requested or exposed to the client layer. Alternatively, the 221 client may request all the SRLG's from the server and store them locally in 222 its SRLG database but only flood in its client control-plane (ISIS, OSPF) the 223 more important (higher priority) SRLG's. 225 Examining a resource type associated with an SRLG may also be used to filter 226 SRLG information in multi-domain/ multi-layer networks. E.g., SP-S1 may not 227 export SRLGs of amplifiers used along path of LSP1 to the client SP (SP-C) 228 running IP services. This document suggests characterization of the following 229 resource types: 231 - Optical section: A fiber that connects two optical NEs(e.g., amplifiers). 232 Also termed OTS in ITU parlance. 234 - Optical line: A fiber that connects two optical switching elements (e.g., 235 ROADMs). Also termed OMS in ITU parlance. 237 - Optical path: an optical connection that connects two client ports, e.g., a 238 port P1 on node N1 to a port P2 on node N2. Also termed Och Connection in 239 ITU parlance. 241 - Fiber Duct: Conduit carrying fibers (which represent optical sections). 243 ID draft-ali-ccamp-extended-srlg-00.txt 245 - Building: Building hosting multiple network elements, and represents a 246 common risk, e.g., during a terror attack. Such a building may host both 247 transport and client gear. 249 - Optical NE: Amplifier, ROADM or other optical NE used along an optical TE 250 link. 252 - Power feed: a common power source feeding multiple NEs 254 - Geographic region: an area susceptible to a disaster such as earthquake or 255 flood. 257 - More may be added in future revision(s). 259 3.2. Globally Unique SRLGs 261 A way to address global uniqueness of the SRLG is to associate Autonomous 262 System (AS) number of the AS that originated the SRLG value. 264 3.3. SRLG Risk Management 266 Risk management requirements are discussed in section 2. As SRLGs are used to 267 characterize resources, associating a resource availability field to the SRLG 268 can satisfy risk management requirements. Specifically, availability of a 269 resource as defined in the following can be used for this purpose. 271 Availability = MTBF/(MTBF+MTTR), where 273 MTBF is mean time between failures of the resource, 275 MTTR is mean time to repair a failure of the resource. 277 4. Extended SRLG Encoding 279 Motivation for this version is to discuss components of SRLG and hence the 280 extended SRLG encoding is intentionally left for a future revision. 281 Nonetheless the idea is to augment the currently defined 32-bit Shared Risk 282 Link Group Value with the following parameters: 284 o SRLG priority. 285 o Type of the SRLG resource. 286 o Availability of the SRLG SRLG resource. 287 o SRLG Originator's AS Number. 289 ID draft-ali-ccamp-extended-srlg-00.txt 291 5. Protocols extensions for extended SRLG Encoding 293 Extension(s) for protocols that use SRLG values for their operations (e.g., 294 OSPF, ISIS, RSVP-TE, PCE, etc.) are to be added in future version of this 295 document or companion document(s). 297 6. Security Considerations 299 Security considerations related to the extended-SRLG encoding are left 300 for future revision of the document. 302 7. IANA Considerations 304 This version of the document does not require any IANA considerations. 306 8. Acknowledgments 308 Authors would like to acknowledge valuable feedback from many service 309 providers. Individual acknowledgements will be added in future version 310 of the document. 312 9. References 314 9.1. Normative References 316 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 317 in Support of Generalized Multi-Protocol Label Switching 318 (GMPLS)", RFC 4202, October 2005. 320 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 321 Support of Generalized Multi-Protocol Label Switching 322 (GMPLS)", RFC 4203, October 2005. 324 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in 325 Support of Generalized Multi-Protocol Label Switching 326 (GMPLS)", RFC 5307, October 2008. 328 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 329 Extension to Resource ReserVation Protocol-Traffic 330 Engineering (RSVP-TE)", RFC 4874, April 2007. 332 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 333 Margaria, M. Hartley, Z. Ali, "RSVP-TE Extensions for 334 Collecting SRLG Information", draft-ietf-ccamp-rsvp-te-srlg- 335 collect.txt, work in progress. 337 ID draft-ali-ccamp-extended-srlg-00.txt 339 9.2. Informative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 Authors' Addresses 346 Zafar Ali 347 Cisco Systems 348 Email: zali@cisco.com 350 George Swallow 351 Cisco Systems 352 swallow@cisco.com 354 Clarence Filsfils 355 Cisco Systems 356 cfilsfil@cisco.com 358 Ori Gerstel 359 Cisco Systems 360 Email: ogerstel@cisco.com 362 Stewart Bryant 363 Cisco Systems 364 stbryant@cisco.com 366 Matt Hartley 367 Cisco Systems 368 Email: mhartley@cisco.com