CCAMP Working Group Zafar Ali Internet Draft George Swallow Intended status: Standard Track Clarence Filsfils Expires: August 17, 2013 Ori Gerstel Stewart Bryant Matt Hartley Cisco Systems February 18, 2013 Extended Encoding Scheme for Shared List Link Group (SRLG) draft-ali-ccamp-extended-srlg-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 17, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of Ali, Swallow, Filsfils Expires August 2013 [Page 1] ID draft-ali-ccamp-extended-srlg-00.txt such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract SRLGs play a key role in routing resiliency and capacity planning of multi-domain and multi-layer networks. Notion of SRLG are used to select a backup path that is disjoint from the primary path, to ensure disjointness of circuits and to avoid catastrophic partitioning outages. In the current specifications, SRLG is identified as a 32 bit number that is unique within an IGP domain [RFC4202]. There are many limitations to this approach of encoding SRLGs, especially in a multi-layer network. This draft outlines these limitations and suggests components of extended SRLG encoding scheme to address them. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents Copyright Notice.....................................................1 1. Introduction......................................................3 2. Requirements......................................................3 2.1. SRLG Scaling..............................................3 2.2. Global SRLG Identification................................4 2.3. Risk Management...........................................4 3. Components of Extended SRLG.......................................5 3.1. SRLG Filtration...........................................5 3.2. Globally Unique SRLGs.....................................6 3.3. SRLG Risk Management......................................6 4. Extended SRLG Encoding............................................6 5. Protocols extensions for extended SRLG Encoding...................7 6. Security Considerations...........................................7 7. IANA Considerations...............................................7 8. Acknowledgments...................................................7 9. References........................................................7 9.1. Normative References......................................7 9.2. Informative References....................................8 Ali, Swallow, Filsfils Expires May 2013 [Page 2] ID draft-ali-ccamp-extended-srlg-00.txt 1. Introduction [RFC4202] defines notion of Shared Risk Link Group (SRLG). OSPF and IS-IS extension for flooding SRLGs are defined in [RFC4203] and [RFC5307], respectively. RSVP-TE signaling extensions for SRLG exclusion and recording are defined in [RFC4874] and [DRAFT-SRLG-RECORDING], respectively. In current specifications, SRLG is identified as a 32 bit number that is unique within an IGP domain. There are many limitations to this approach for encoding SRLGs, especially in multi-domain and multi-layer networks. Section2 outlines these restrictions and states the associated requirements. Section 3 outlines components of the extended SRLG encoding format to address these requirements. The extended SRLG encoding format and the associated protocols extension(s) are intentionally left for a future version/ companion document(s). 2. Requirements The section outlines the requirements for extending SRLG beyond an IGP domain scoped 32 bit number. Some of these requirements are also noted in [DRAFT- SRLG-INFERENCE]. 2.1. SRLG Scaling A zealous operator could assign an SRLG for each risk, including (but not limited to) a building, a floor of a building, a bridge, a side of a rail- track, a side of a highway, and an amplifier. This operator could easily have hundreds of SRLGs for Label Switch Paths (LSPs) transiting domain it operates. Similarly, there are technologies (e.g., DWDM) where it is possible to have hundreds of SRLGs associated with LSPs using such underlying technology. This presents a scaling issue with operations of the network, e.g., during constrained-based path computation of intra-domain LSPs. This also presents a scaling issue when such networks are used in multi-domain and multi-layer environment, e.g., in IP over DWDM network, there may be hundreds of SRLGs along a given IP/ MPLS link (inherited from underlying DWDM LSP). It may not scale for the IP/ MPLS layer to learn hundreds of SRLGs per link and flood them into its IGP database. This may impact flooding speed, topology database size and especially constrained-based path computation complexity and performance. In the light of the above, finding mechanism(s) to scale SRLG is a requirement for GMPLS networks, especially in inter-domain/ inter-layer environment. Ali, Swallow, Filsfils Expires May 2013 [Page 3] ID draft-ali-ccamp-extended-srlg-00.txt 2.2. Global SRLG Identification Currently SRLGs are defined and supported within domains. This limits the usefulness of SRLGs in an inter-domain environment, as elaborated in the following cases. - There are cases where two different Service Providers (SPs) may be sharing the same fate (facility) for TE links within domains administrated by them. For example, if a client Service Provider SP-C leases two LSPs LSP1 and LSP2 respectively from two server SPs SP-S1 and SP-S2 who themselves lease fibers from the same submarine duct, the SP-C would like to know when the two LSPs LSP1 and LSP2 share the same submarine risk. With current definition of SRLGs this is not possible. This is because SP-S1 uses an SRLG numbering completely independent from SP-S2. For example, SP-S1 might identify the submarine risk as SRLG23 while SP-S2 identifies it as SRLG47. Even if client SP (SP-C) is able to discover SRLGs along LSP1 and LSP2 (e.g., using SRLG recording [DRAFT-SRLG-RECORDING] SP-C learns that the LSP1 is exposed to SRLG23 and LSP2 exposed to SRLG47), the SP-C problem is not resolved: it has no way to know that LSP1 and LSP2 are actually sharing the same risk. - If SP-C in the above example would like to request LSP2 to be SRLG diverse from LSP1 using SRLG recording [DRAFT-SRLG-RECORDING] and SRLG XRO/ EXRS [RFC4874], there is no guarantee that LSP2 route is SRLG diverse. This is because knowing that LSP1 is exposed to SRLG23, SP-C cannot realize a path from SP-S2 which is disjoint from SRLG23 of SP-S1 (as SRLG23 means something else for SP-S2). Similarly, SRLG inclusion also does not work using the current SRLG encoding scheme. - At present, SRLG administration is completely up to the SPs. Therefore, SRLG values in an inter-domain environment may collide. Considering the above example, SP-S1 may have assigned SRLG12 to a resource used by LSP1, whereas client SP-C may already be using SRLG12 to identify a different resource in its network. Even though these two resources may not share any risk, they are not SRLG diverse (assumed to share risk in GMPLS control plane). In the light of the above, finding mechanism(s) to maintain consistency of SRLG in an inter-domain environment is a requirement. 2.3. Risk Management Not all resources in a network have same level of availability. Some resources are more prone to failures, e.g., a fiber trunk running close to utility wires is more likely to suffer from accidental cuts than a fiber trunk running in isolation. Metro links are more susceptible to cuts than rural links, and aerial fiber is susceptible to storm induced outages. Ali, Swallow, Filsfils Expires May 2013 [Page 4] ID draft-ali-ccamp-extended-srlg-00.txt Consider the example where a client Service Provider (SP) SP-C leases LSP1 from server SP (SP-S1). Availability of LSP1 is typically part of service level agreement (SLA) between SP-C and SP-S1, e.g., SP-C may request 99.999% (five-nines) of availability. Given high availability requirement for LSP1, SP-S1 needs to route LSP1 such that it uses resources with better than 99.999% availability. Furthermore, given a set of underlying resources, SP1 should also be able to estimate availability of LSP1 connection. How availability of a connection given availability of its underlying resources is estimated is beyond the scope of this document but, if availability is represented as a number between 0 and 1, a multiply function can be used for this calculation. In the light of the above, finding mechanism(s) to quantify risk associated with a resource is a requirement. 3. Components of Extended SRLG This section outline components that form basis for extended SRLG encoding scheme. 3.1. SRLG Filtration A way to address SRLG scaling requirement mentioned in Section 2 is to associate a priority field to the SRLG and use it as a mechanism to observe SRLG filtering. For example, in a multi-layer network, only higher priority SRLGs may be requested or exposed to the client layer. Alternatively, the client may request all the SRLG's from the server and store them locally in its SRLG database but only flood in its client control-plane (ISIS, OSPF) the more important (higher priority) SRLG's. Examining a resource type associated with an SRLG may also be used to filter SRLG information in multi-domain/ multi-layer networks. E.g., SP-S1 may not export SRLGs of amplifiers used along path of LSP1 to the client SP (SP-C) running IP services. This document suggests characterization of the following resource types: - Optical section: A fiber that connects two optical NEs(e.g., amplifiers). Also termed OTS in ITU parlance. - Optical line: A fiber that connects two optical switching elements (e.g., ROADMs). Also termed OMS in ITU parlance. - Optical path: an optical connection that connects two client ports, e.g., a port P1 on node N1 to a port P2 on node N2. Also termed Och Connection in ITU parlance. - Fiber Duct: Conduit carrying fibers (which represent optical sections). Ali, Swallow, Filsfils Expires May 2013 [Page 5] ID draft-ali-ccamp-extended-srlg-00.txt - Building: Building hosting multiple network elements, and represents a common risk, e.g., during a terror attack. Such a building may host both transport and client gear. - Optical NE: Amplifier, ROADM or other optical NE used along an optical TE link. - Power feed: a common power source feeding multiple NEs - Geographic region: an area susceptible to a disaster such as earthquake or flood. - More may be added in future revision(s). 3.2. Globally Unique SRLGs A way to address global uniqueness of the SRLG is to associate Autonomous System (AS) number of the AS that originated the SRLG value. 3.3. SRLG Risk Management Risk management requirements are discussed in section 2. As SRLGs are used to characterize resources, associating a resource availability field to the SRLG can satisfy risk management requirements. Specifically, availability of a resource as defined in the following can be used for this purpose. Availability = MTBF/(MTBF+MTTR), where MTBF is mean time between failures of the resource, MTTR is mean time to repair a failure of the resource. 4. Extended SRLG Encoding Motivation for this version is to discuss components of SRLG and hence the extended SRLG encoding is intentionally left for a future revision. Nonetheless the idea is to augment the currently defined 32-bit Shared Risk Link Group Value with the following parameters: o SRLG priority. o Type of the SRLG resource. o Availability of the SRLG SRLG resource. o SRLG Originator's AS Number. Ali, Swallow, Filsfils Expires May 2013 [Page 6] ID draft-ali-ccamp-extended-srlg-00.txt 5. Protocols extensions for extended SRLG Encoding Extension(s) for protocols that use SRLG values for their operations (e.g., OSPF, ISIS, RSVP-TE, PCE, etc.) are to be added in future version of this document or companion document(s). 6. Security Considerations Security considerations related to the extended-SRLG encoding are left for future revision of the document. 7. IANA Considerations This version of the document does not require any IANA considerations. 8. Acknowledgments Authors would like to acknowledge valuable feedback from many service providers. Individual acknowledgements will be added in future version of the document. 9. References 9.1. Normative References [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria, M. Hartley, Z. Ali, "RSVP-TE Extensions for Collecting SRLG Information", draft-ietf-ccamp-rsvp-te-srlg- collect.txt, work in progress. Ali, Swallow, Filsfils Expires May 2013 [Page 7] ID draft-ali-ccamp-extended-srlg-00.txt 9.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Zafar Ali Cisco Systems Email: zali@cisco.com George Swallow Cisco Systems swallow@cisco.com Clarence Filsfils Cisco Systems cfilsfil@cisco.com Ori Gerstel Cisco Systems Email: ogerstel@cisco.com Stewart Bryant Cisco Systems stbryant@cisco.com Matt Hartley Cisco Systems Email: mhartley@cisco.com Ali, Swallow, Filsfils Expires May 2013 [Page 8]