Internet DRAFT - draft-ali-ccamp-extended-srlg

draft-ali-ccamp-extended-srlg










     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]