IETF A. Rhodes Internet-Draft N. NeateExpires: February 7, 2009Intended status: Informational D. McWalter, Ed. Expires: September 5, 2009 Data Connection LtdAugust 6, 2008March 4, 2009 Problems observed with RSVP recovery signalingdraft-rhodes-rsvp-recovery-signaling-00.txtdraft-rhodes-rsvp-recovery-signaling-01.txt Status of this MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft isaware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF inaccordancefull conformance withSection 6the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onFebruary 7,September 5, 2009. Copyright Notice Copyright(C)(c) 2009 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. 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(2008).the right to allow modifications of 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 Implementation experience with RSVP-TE recovery signaling has uncovered some problems. Associations between LSPs in different sessions are forbidden. Protecting LSPs cannot themselves be protected. Overlapping repairs cause loss of traffic. This draft provides details of these problems for the community to consider. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .34 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .34 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .3 3.14 3.1. Association between LSPs in different sessions . . . . . .3 3.24 3.2. LSP association in multi-domain protection cases . . . . .3 3.34 3.3. Protecting LSPs cannot themselves be protected . . . . . .3 3.44 3.4. Overlapping repairs cause loss of traffic . . . . . . . .45 3.5. segment-recording-desired flag is unassigned . . . . . . . 5 4. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 4.15 4.1. Association between LSPs in different sessions . . . . . .4 4.25 4.2. LSP association in multi-domain protection cases . . . . .4 4.37 4.3. Protecting LSPs cannot themselves be protected . . . . . .4 4.48 4.4. Overlapping repairs cause loss of traffic . . . . . . . .58 4.5. segment-recording-desired flag is unassigned . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . .610 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .610 7.AcknowledgementsRevision History . . . . . . . . . . . . . . . . . . . . . . .6 8. References10 7.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . .6 8.1 Normative References. . . . . . . . . . . . . . . . . . .6 8.211 9. Informative References . . . . . . . . . . . . . . . . . .6 Authors' Addresses .. . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . .7 Intellectual Property and Copyright Statements. . . . .. . . 811 1. Introduction This draft describes problems. It does not propose solutions. Our purpose in writing this draft is to determine how to resolve some RSVP-TE recovery problems we have encountered. We believe these problems are due to limitations in existing RSVP signaling procedures. We would like the community to consider whether the following scenarios are within the requirements for RSVP-TE protection. If so, we would like comments on whether we have correctly interpreted the existing RSVP-TE signaling proceduress in each case. If so, we solicit further collaboration in preparing proposals for interoperable solutions. 2. Terminology GMPLS recovery terminology is introduced by [RFC4427]. 'End-to-end protection' (e2e) procedures are defined by [RFC4872]. 'Segment recovery' procedures are defined by [RFC4873]. 3. Summary3.13.1. Association between LSPs in different sessions Segment recovery protecting LSPs may have a different endpoint address from the corresponding protected LSP. The protected and protecting LSPs are therefore in different Sessions. The Association object of type 1 (recovery) is not effective in this case, as the Association ID can only associate to an LSP ID within the same Session.3.23.2. LSP association in multi-domain protection cases End-to-end protected LSPs may pass through several addressing domains, resulting in mappings of addresses in the Session and Sender-Template. This causes difficulties for LSP endpoints attempting to associate protecting and protected LSPs.3.33.3. Protecting LSPs cannot themselves be protected End-to-end or segment protection can be applied to a protecting LSP. That LSP is both protecting and protected. This cannot be signaled because only a single Protection object is allowed and it contains a single bit to indicate whether the LSP is protecting or protected.3.43.4. Overlapping repairs cause loss of traffic Segment protection can be provided by two overlapping recovery paths. A single failure may trigger restoration using both repairs. Traffic is lost in this case. 3.5. segment-recording-desired flag is unassigned [RFC4873] s5.2 defines this flag, but no value is given. We need to ask IANA to assign a value. 4. Detail4.14.1. Association between LSPs in different sessions End-to-end recovery uses Association objects of type 1 (recovery)alwaysto associate LSPs belonging to the samesession ([RFC4872] s6.1,session. Association ID is (in most cases) set to the LSP ID of the associated LSP. See [RFC4872] s4.3, s6.1 and s16. [RFC4873]s3). Segment recovery repair paths musts3.2 and s3.2.1 state that procedures for use of theendpoint specified by explicit or dynamic controlAssociation ID in segment recovery are not modified from those defined in [RFC4872] for end-to-end recovery. The following example shows that different procedures([RFC4873] s4.2are necessary. A G D \ / \ / \ / \ / B-----C / \ / \ E F Protected LSP1: A-B-C-D, LSP ID 5 Protected LSP2: E-B-C-F, LSP ID 5 Segment recovery LSP1: B-G-C (1+1 protection) Segment recovery LSP2: B-G-C (1+1 protection) It is not possible for B ands6.2). In cases whereC to use LSP ID 5 to associate the two segment recoverypath endpoint differs fromLSPs with the protectedLSP endpoint,LSPs. Discussion with authors suggests that it is intended that B assigns an arbitrary value as the Association ID, although this is not clearly spelled out. Here is how this applies to the example: Protected LSP1: A-B-C-D, LSP ID 5, Assoc ID 23 Protected LSP2: E-B-C-F, LSP ID 5, Assoc ID 24 Segment recovery LSP1: B-G-C (1+1 protection) Assoc ID 23 Segment recovery LSP2: B-G-C (1+1 protection) Assoc ID 24 This works in many cases, but introduces ambiguity when both segment recovery and end-to-end recovery are used in a network. ?? protected LSP3: B-C, LSP ID 1, Assoc ID 25 Segment recovery LSP: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25 End-to-end recovery LSP: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1 It is not possible tosatisfydecide which of theserestrictions. As a result,recovery LSPs protects LSP3, at least not using existing procedures. The difficulty becomes more marked as additional LSPs are added: ?? protected LSP3: B-C, LSP ID 1, Assoc ID 25 Segment protected LSP4: A-B-C-D, LSP ID 5, Assoc ID 1 ?? recovery LSP5: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25 ?? recovery LSP6: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1 (All Association objects are Type 1, Association Source B). Significant analysis is required to determine which LSPs might be associated, and which recovery LSPs are segment or end-to-end recovery. In this case, we might choose to regard LSP3 as segment protected by LSP5 rather than e2e protected by LSP6, as this allows us to associate LSP4 with LSP6. Such deductions may fail or prove incorrect where protected and recoveryrepair pathsLSPs are noteffective in these cases (unless non-interoperable assumptions1:1 paired. Therefore we can expect to see transient mapping errors as LSPs aremade). 4.2established and released. We can also expect to see permanent errors for recovery schemes such as (Full) LSP rerouting that do not always pair protected and recovery LSPs. Two approaches to remove this difficulty have been suggested. Both modify [RFC4873] procedures. 1. For a given Association Source, match Association objects by first looking for a matching segment recovery Association ID. If none exists, then match by treating Association ID as an LSP ID within the given Session. This resolves the ambiguity but restricts identifier use at the Association Source: values chosen as segment recovery Association IDs are unusable as LSP IDs from that source, and vice versa. A branch node implementing this approach would not allow management to use the full range of LSP IDs. 2. Introduce a new Association type for segment recovery. Use Association type 1 only for end-to-end recovery. This removes the ambiguity. This keeps separate the LSP ID and Association ID number spaces. The meaning of the Association ID is given by the Association type. This is back-compatible with deployments of [RFC4872] but disrupts deployments of [RFC4873]. 4.2. LSP association in multi-domain protection casesLSPsA GMPLS domain may contain multiple IP addressing domains. Therefore an LSP may traverse multiple IP addressing domains.Address mappings[RFC4927] and [RFC5376] show inter-area and inter-AS (G)MPLS-TE tunnel establishment. A given IP address may occur in more than one area or AS. (Otherwise the areas or ASes are not separate addressing domains). In order to support this, address mappings must modify the Session andSender-TemplateSender- Template at address domain boundaries. Protected and protecting LSPs may achieve diversity by traversing different domains. The cumulative modifications to Session and Sender-Template may result in the LSPs being in different sessions at theend of the repair path.merge point. ........ ........... ........ . . . . . . . A------B-----C------D . . / . . . . \ . . / . .....2..... . \ . . I 1 3 E . . \ . .....4..... . / . . \ . . . . / . . F------G-----H------J . . . . . . . ........ ........... ........ In thiscase,illustration, four addressing domains (1-4) are shown. Together they make up a GMPLS domain across which LSPs can be set up. If two LSPs take theAssociation IDpaths IABCDE and IFGHJE, then it is unclear whether these LSPs can be considered to be in theAssociation object cannot be usedsame session at node E. A/B translates Tunnel Sender / ext tunnel ID from I toassociate'K'. C/D translates Tunnel Sender / ext tunnel ID from K to 'L'. F/G translates Tunnel Sender / ext tunnel ID from I to 'M'. H/J translates Tunnel Sender / ext tunnel ID from M to 'N'. So E may regard theprotectingLSPs as being in different sessions, as their extended tunnel ID will differ, as will their tunnel sender address andprotected LSPs: The restrictionsany Association Source. These values were all set to 'I' in addressing domain 1. In such cases, the statement of [RFC4872] s6.1and those of [RFC4873] s3 prevent the association ofthat "both LSPsin different sessions. As a result, end-to-end recovery repair paths areMUST belong to the same session" is difficult to apply. End-to-end protection might therefore noteffective in these cases (unless non-interoperable assumptions are made). 4.3be applicable to a GMPLS domain containing multiple IP addressing domains. Applicability might be achieved if the GMPLS address mapping peformed at IP addressing domain boundaries (AB, CD, FG, HJ) within a GMPLS domain were to be specified or constrained. This is for discussion. 4.3. Protecting LSPs cannot themselves be protectedOnly one protection object may be signaled. See [RFC4872] s17 and [RFC4873] s7.A segment recovery repair path can itself be protected by end-to-end or segment recovery repairs, according to [RFC4873] s2. The result is an LSP segment that is both protected and protecting. However, only one protection object may be signaled. See [RFC4872] s17 and [RFC4873] s7. The (P)rotecting bit in the protection object should be set for the LSP's protecting role, but clear for its protected role. See [RFC4872] s4.2.1, s14.1 and [RFC4873] s6.1. Therefore protecting LSPs cannot themselves be protected by repair paths (unless we include non-interoperable procedures).4.44.4. Overlapping repairs cause loss of traffic Consider the following topology: K-----------L / \ A===B===C===D===E===F===G===H \ / I-----------J Primary bidirectional LSP A-B-C-D-E-F-G-H is protected by two overlapping segment recovery paths B-K-L-F and C-I-J-G. Suppose 1:1 protection with extra traffic. This 'overlapping protection' is a valid case, see [RFC4873] section 1. Consider a failure of link D-E. K-----------L / \ A===B===C===D=X=E===F===G===H \ / I-----------J D detects this locally, and sends Notify to C (first Notify object in the received Path). C and G communicate to remove extra traffic from the C-I-J-G repair, and then send and receive normal traffic on C-I and G-J. Meanwhile, E also detects the failure locally, and sends Notify to F (first Notify object in the received Resv). F likewise communicates with B and normal traffic is sent and received on B-K and F-L. K----->-----L / \ A->-Bx<-C---D-X-E---F->xG<--H \ / I-----<-----J Forward traffic reaches G on the link F-G. However, G has switched to send and receive on G-J. Reverse traffic reaches B on C-B. However, B has switched to send and receive on B-K.TheThus the standard procedure causes the loss of traffic in both directions. It may possible to solve this problem by configuring or otherwise assigning master/slave roles to the branch and merge points. See [RFC4426] s2.3. Currently there is no protocol description for how the master/slave roles might be dynamically assigned, nor how configured master/slave roles would affect [RFC4872] or [RFC4873] switchover. The mandatory procedures from [RFC4872] s6.2 and s7.2 (applied to segment recovery by [RFC4873] s2.1) prescribe the behaviour of the endpoints. It may be that procedures need to be modified so that endpoints have some latitude to decide not to perform switchover in some cases. It is possible to detect the 'overlapping repairs' condition at nodes B and G by using SRRO objects. These are optionally present between F and H on the path, and between C and A on the Resv, see [RFC4873] s2 and s5.2. In order to detect the problem reliably, procedures would need to change to make them mandatory. 4.5. segment-recording-desired flag is unassigned [RFC4873] s5.2 assigns this flag as part of the SESSION_ATTRIBUTE object. However, no request was made to IANA to assign a value for it. We could correct this omission by asking IANA to assign a value. At the time of writing 0x40 is the next available value, see http:// www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.txt Note that it is also open to specify that an LSP_ATTRIBUTE flag for this purpose. For discussion. 5. Security Considerations This document does not propose any protocol changes. 6. IANA Considerations None. 7. Revision History 7.1. Changes in -01 Sections 3.1 and 4.1 better describe interactions between end-to-end and segment recovery use of Association type 1 Association ID. Sections 3.5 and 4.5 added, describing a missing codepoint. Section 4.1 includes examples. Section 4.1 includes Added Adrian Farrel's suggestion for egress to match segment recovery associations in precedence to end-to-end recovery associations. Section 4.2 includes an example. Section 4.2 questions the applicability of [RFC4872] to GMPLS domains containing multiple IP addressing domains. Section 4.4 notes that the SRRO object could provide a tool for detecting overlapping repairs, though its presence is not mandatory. Section 4.4 is updated with discussion of [RFC4426] roles, which do not appear to provide a solution. 8. AcknowledgementsThanksThe authors would like to thank allreviewers, includingwho have contributed to our understanding of these issues, particularly SnigdhoBardalai andBardalai, Adrian Farrel, RemiTheillaud. Differing interpretations of RSVP signaling procedures confirmed that we should circulate this draft. 8. References 8.1 Normative References 8.2Theillaud and Dimitri Papadimitriou. 9. Informative References [RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007. [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008. Authors' Addresses Andrew Rhodes Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom Email: adr@dataconnection.com Nic Neate Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom Email: nhn@dataconnection.com David McWalter (editor) Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom Email: dmcw@dataconnection.comIntellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.