IETF A. Rhodes Internet-Draft N. Neate Expires: February 7, 2009 D. McWalter, Ed. Data Connection Ltd August 6, 2008 Problems observed with RSVP recovery signaling draft-rhodes-rsvp-recovery-signaling-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 on February 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). 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. Rhodes, et al. Expires February 7, 2009 [Page 1] Internet-Draft RSVP recovery signaling August 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Association between LSPs in different sessions . . . . . . 3 3.2 LSP association in multi-domain protection cases . . . . . 3 3.3 Protecting LSPs cannot themselves be protected . . . . . . 3 3.4 Overlapping repairs cause loss of traffic . . . . . . . . 4 4. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Association between LSPs in different sessions . . . . . . 4 4.2 LSP association in multi-domain protection cases . . . . . 4 4.3 Protecting LSPs cannot themselves be protected . . . . . . 4 4.4 Overlapping repairs cause loss of traffic . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1 Normative References . . . . . . . . . . . . . . . . . . . 6 8.2 Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Rhodes, et al. Expires February 7, 2009 [Page 2] Internet-Draft RSVP recovery signaling August 2008 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 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. Summary 3.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.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.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. Rhodes, et al. Expires February 7, 2009 [Page 3] Internet-Draft RSVP recovery signaling August 2008 3.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. 4. Detail 4.1 Association between LSPs in different sessions Association objects of type 1 (recovery) always associate LSPs belonging to the same session ([RFC4872] s6.1, [RFC4873] s3). Segment recovery repair paths must use the endpoint specified by explicit or dynamic control procedures ([RFC4873] s4.2 and s6.2). In cases where the recovery path endpoint differs from the protected LSP endpoint, it is not possible to satisfy these restrictions. As a result, segment recovery repair paths are not effective in these cases (unless non-interoperable assumptions are made). 4.2 LSP association in multi-domain protection cases LSPs may traverse multiple IP addressing domains. Address mappings may modify the Session and Sender-Template at domain boundaries. Protected and protecting LSPs may achieve diversity by traversing different domains. The modifications to Session and Sender-Template may result in the LSPs being in different sessions at the end of the repair path. In this case, the Association ID in the Association object cannot be used to associate the protecting and protected LSPs: The restrictions of [RFC4872] s6.1 and those of [RFC4873] s3 prevent the association of LSPs in different sessions. As a result, end-to-end recovery repair paths are not effective in these cases (unless non-interoperable assumptions are made). 4.3 Protecting LSPs cannot themselves be protected Only 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. Rhodes, et al. Expires February 7, 2009 [Page 4] Internet-Draft RSVP recovery signaling August 2008 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.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 Rhodes, et al. Expires February 7, 2009 [Page 5] Internet-Draft RSVP recovery signaling August 2008 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. The standard procedure causes the loss of traffic in both directions. 5. Security Considerations This document does not propose any protocol changes. 6. IANA Considerations None. 7. Acknowledgements Thanks to all reviewers, including Snigdho Bardalai and Remi Theillaud. Differing interpretations of RSVP signaling procedures confirmed that we should circulate this draft. 8. References 8.1 Normative References 8.2 Informative References [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. Rhodes, et al. Expires February 7, 2009 [Page 6] Internet-Draft RSVP recovery signaling August 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.com Rhodes, et al. Expires February 7, 2009 [Page 7] Internet-Draft RSVP recovery signaling August 2008 Intellectual 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. Rhodes, et al. Expires February 7, 2009 [Page 8]