idnits 2.17.1 draft-helvoort-ccamp-fs-priority-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC4427, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2013) is 3935 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) ** Downref: Normative reference to an Informational RFC: RFC 4427 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP WG Huub van Helvoort 2 Internet Draft Huawei Technologies 3 Updates: 4427 4 Intended status: Standards track July 11, 2013 5 Expires: January 2014 7 Update Forced Switch Priority 8 draft-helvoort-ccamp-fs-priority-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on January 11, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. 57 Abstract 59 This document clarifies the definitions related to Manual Switch and 60 Forced Switch. This document updates RFC 4427. 62 Table of Contents 64 1. Introduction ................................................ 2 65 2. Manual Switch and Forced Switch.............................. 3 66 3. Security Considerations ..................................... 3 67 4. IANA Considerations ......................................... 3 68 5. References .................................................. 4 69 5.1. Normative References.................................... 4 70 5.2. Informative References.................................. 4 71 6. Acknowledgments ............................................. 4 73 1. Introduction 75 The external commands, Manual Switch and Forced Switch, provide an 76 operator the ability to control the recovery schemes. The 77 definitions in [RFC4427] provide an informative description but do 78 not provide enough description to distinguish the processing of 79 these commands for usage with priority treatment. The current 80 description has led to the open question of how the commands are to 81 be processed for relative priority treatment. 83 This document provides clarification of the terms relative to 84 [G.808.1]. 86 2. Manual Switch and Forced Switch 88 This section updates [RFC4427]. Section 4.13 of [RFC4427] contains 89 the following text regarding the definitions: 91 D. Forced switch-over for normal traffic: 93 A switch-over action, initiated externally, that switches normal 94 traffic to the recovery LSP/span, unless an equal or higher 95 priority switch-over command is in effect. 97 E. Manual switch-over for normal traffic: 99 A switch-over action, initiated externally, that switches normal 100 traffic to the recovery LSP/span, unless a fault condition exists 101 on other LSPs/spans (including the recovery LSP/span) or an equal 102 or higher priority switch-over command is in effect. 104 This definition does not provide enough detail with respect to their 105 usage relative to priorities. In order to avoid mis-interpretation, 106 this document adds the following Note as clarification: 108 Note: 110 For 1+1 protection schemes (which do not use a communication 111 channel), a Forced Switch over for normal traffic will have the 112 highest priority, it will not be overridden by a signal fail on 113 the protection channel. For other protection schemes (which do use 114 a communication channel), a Forced Switch over for normal traffic 115 will be overridden if a signal fail is present on the protection 116 channel. Definitions of ITU-T terminology in this section are 117 intended to aid understanding of the concepts. For the full 118 definition of these terms and their use, the reader is referred to 119 the appropriate ITU-T Recommendations and RFCs. 121 3. Security Considerations 123 This document clarifies usage of terms defined in [RFC4427]. No new 124 information is conveyed; therefore no additional considerations are 125 included here. 127 4. IANA Considerations 129 There are no items for IANA to consider. 131 5. References 133 5.1. Normative References 135 [RFC4427] Mannie E. and Papadimitriou D., "Recovery (Protection and 136 Restoration) Terminology for Generalized Multi-Protocol 137 Label Switching (GMPLS) ", RFC 4427, March 2006. 139 5.2. Informative References 141 [G.808.1] ITU-T Recommendation G.808.1, "Generic protection 142 switching - Linear trail and subnetwork protection", 143 February 2010. 145 6. Acknowledgments 147 149 This document was prepared using 2-Word-v2.0.template.dot. 151 Authors' Addresses 153 Huub van Helvoort 155 Huawei Technologies 157 Karspeldreef 4 159 Amsterdam 1011 CJ 161 The Netherlands 163 Phone: +31 20 4300832 165 Email: Huub.van.Helvoort@huawei.com