idnits 2.17.1 draft-ietf-mpls-retire-ach-tlv-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2013) is 3915 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel 3 Internet Draft Juniper Networks 4 Category: Standards Track S. Bryant 5 Updates: 5586 (if approved) Cisco Systems 6 Expires: January 31, 2014 July 31, 2013 8 Retiring TLVs from the Associated Channel Header of the MPLS Generic 9 Associated Channel 11 draft-ietf-mpls-retire-ach-tlv-03.txt 13 Abstract 15 The MPLS Generic Associated Channel (G-ACh) is a generalization of 16 the applicability of the Pseudowire (PW) Associated Channel Header 17 (ACH). RFC 5586 defines the concept of TLV constructs that can be 18 carried in messages on the G-ACh by placing them in the ACH between 19 the fixed header fields and the G-ACh message. These TLVs are called 20 ACH TLVs 22 No Associated Channel Type yet defined uses an ACH TLV. Furthermore, 23 it is believed that handling TLVs in hardware introduces significant 24 problems to the fast-path, and since G-ACh messages are intended to 25 be processed substantially in hardware, the use of ACH TLVs is 26 undesirable. 28 This document updates RFC 5586 by retiring ACH TLVs and removing the 29 associated registry. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that other 38 groups may also distribute working documents as Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 1. Introduction and Scope 68 RFC4385 [RFC4385] says that if the first nibble of a PW packet 69 carried over an MPLS network has a value of 1 then the packet starts 70 with a specific header format called the Pseudowire Associated 71 Channel Header, known as the PWACH or more generally as the ACH. This 72 mechanism creates an Associated Channel that is a message channel 73 associated with a specific pseudowire (PW). 75 The applicability of the ACH is generalized in RFC 5586 [RFC5586] to 76 define the MPLS Generic Associated Channel (G-ACh). This creates a 77 common encapsulation header for control channel messages associated 78 with MPLS Sections, Label Switching Paths (LSPs), and PWs. 80 As part of making the ACH fully generic, RFC 5586 defines ACH TLV 81 constructs. According to RFC 5586: 83 In some applications of the generalized associated control channel, 84 it is necessary to include one or more ACH TLVs to provide 85 additional context information to the G-ACh packet. 87 RFC 5586 goes on to say: 89 If the G-ACh message MAY be preceded by one or more ACH TLVs, then 90 this MUST be explicitly specified in the definition of an ACH 91 Channel Type. 93 However, at the time of writing, of the 18 ACH Channel Types defined, 94 none allows the use of ACH TLVs [IANA-ACH]. At the time of writing 95 there are no live Internet-Drafts that utilize ACH TLVs. 97 Furthermore, G-ACh packets are intended to be substantially processed 98 in hardware, however, processing TLVs in hardware can be hard because 99 of the unpredictable formats and lengths that they introduce to the 100 normal ACH format. 102 This document states that ACH TLVs as specified in RFC 5586 are not 103 useful and might be harmful. It updates RFC 5586 by deprecating the 104 ACH TLV and updating the associated IANA registries as described in 105 Section 4 of this document. This document makes no comment about the 106 use of TLVs in other places. In particular, proposals to use TLVs 107 within ACH messages or as an appendage to ACH messages, are not in 108 scope of this document. 110 1.1. Specification of Requirements 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Update to RFC 5586 118 Section 3 of RFC 5586 is deleted. 120 References to ACH TLVs in Section 4 of RFC 5586 should also be 121 disregarded. Note that the text in Section 4 currently uses phrases 122 like "ACH TLV(s), if present" so, with the removal of Section 3 that 123 used to define ACH TLVs, they will not be present. 125 3. Implication for the ACH 127 A G-ACh message MUST NOT be preceded by an ACH TLV. 129 4. IANA Considerations 131 This document requests IANA to make two changes to the IANA 132 registries. 134 4.1. Associated Channel Header TLV Registry 136 The "Pseudowire Name Spaces (PWE3)" registry has a sub-registry 137 called the "Associated Channel Header TLV Registry". IANA is 138 requested to entirely delete this sub-registry, but to leave a 139 tombstone record in the top-level list of registries that says: 141 Associated Channel Header TLV Registry RFC 5586 RFC xxxx 143 Where "xxxx" is the number of this RFC. 145 draft-ietf-mpls-retire-ach-tlv-03.txt July 20 13 147 4.2. Pseudowire Associated Channel Types Registry 149 The "Pseudowire Name Spaces (PWE3)" registry has a sub-registry 150 called the "Pseudowire Associated Channel Types Registry". This 151 sub-registry includes a column marked "TLV Follows". IANA is 152 requested to entirely delete this column leaving no record. 154 IANA is requested to add a pointer to this RFC in the definition of 155 this sub-registry. 157 5. Manageability Considerations 159 This document will have no impact on network or device manageability 160 because there are no ACH Types that allow the use of TLVs. 161 The document removes a feature that might have been used to enhance 162 management messages, and especially Operations, Management, and 163 Administration (OAM) messages. However, given the considerable 164 experience in defining MPLS OAM messages in the last few years, it 165 would appear that this feature is not useful. 167 It is possible that packet sniffers that have already been 168 implemented will look for ACH TLVs. The deletion of the construct 169 will not have a negative impact. 171 6. Security Considerations 173 Deleting the ACH TLV has a marginal positive effect on security 174 because it removes a feature that might have been used as an attack 175 vector to carry false information or to bloat G-ACh messages. 177 On the other hand, it had been sugested that the ACH TLV could have 178 been used to carry security parameters to secure the messages on the 179 G-ACh in a generic way. However, no mechanisms have been proposed at 180 the time of writing, and it has generally been considered that it is 181 the responsiblity of the specification that defines G-ACh messages to 182 consider the security requirements of those messages which may be 183 different for the different applications. 185 Otherwise, this document has no implications for security. 187 7. Acknowledgements 189 Thanks to Eric Osborne, Thomas Morin, Lizhong Jin, Greg Mirsky, Jia 190 He, and Pearl Liang for suggestions to improve the text. 192 8. References 194 8.1. Normative References 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 199 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 200 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word 201 for Use over an MPLS PSN", RFC 4385, February 2006. 203 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 204 Associated Channel", RFC 5586, June 2009. 206 8.2. Informative References 208 [IANA-ACH] "Pseudowire Associated Channel Types", IANA, 209 http://www.iana.org/assignments/pwe3-parameters/pwe3- 210 parameters.xml#pwe3-parameters-10 212 Authors' Addresses 214 Adrian Farrel 215 Juniper Networks 216 EMail: adrian@olddog.co.uk 218 Stewart Bryant 219 Cisco Systems 220 EMail: stbryant@cisco.com