idnits 2.17.1 draft-doolan-ccamp-proprietary-ac-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 : ---------------------------------------------------------------------------- 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 (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-dharinigert-ccamp-g-698-2-lmp-08 == Outdated reference: A later version (-12) exists of draft-galikunze-ccamp-g-698-2-snmp-mib-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group P. Doolan 3 Internet-Draft Coriant 4 Intended status: Informational October 27, 2014 5 Expires: April 30, 2015 7 Concerns with the use of Proprietary Application Codes 8 draft-doolan-ccamp-proprietary-ac-00 10 Abstract 12 This document explains the terms Application Code and Application 13 Identifier and points out a danger that exists when proprietary 14 application codes are used. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 30, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 52 3. Description and definition of AC and AI . . . . . . . . . . . 2 53 3.1. AC . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3.2. AI . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.3. AC and AI axioms . . . . . . . . . . . . . . . . . . . . 4 56 4. Using AIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Using AI containing a STANDARD AC . . . . . . . . . . . . 5 58 4.2. Using AI containing a PROPRIETARY AC . . . . . . . . . . 5 59 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 8.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Application Code (AC) and Application Identifier (AI) are concepts 70 and terms defined in the ITU-T. They have been used in at least two 71 drafts in the IETF [SNMP][LMP] and it is quite possible they will be 72 used in others. While the definitions of these concepts are not 73 overly complicated it is important to understand them and to be aware 74 of some subtleties in using them. 76 2. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 3. Description and definition of AC and AI 84 This section provides and discusses some descriptive and definitional 85 material realted to AC and AI from ITU-T Recommendations. 87 3.1. AC 89 ACs have been used in ITU-T Recommendations that specify optical 90 interface parameters since at least the early 1990s. They are used 91 in many of the ITU-T Recommendations referenced in CCAMP work e.g. 92 G.957 [ITU-T_G.957], G.695 [ITU-T_G.695], G.698.1 [ITU-T_G.698.1] and 93 G.698.2 [ITU-T_G.698.2]. 95 ACs are explained in the ITU-T handbook 'Optical fibres, cables and 96 systems' [ITU-T_OFCS]. ACs take into account 'the many possible 97 combinations of channel counts, optical tributary signal types, span 98 distances, fibre types and system configurations. The structure of 99 these codes varies from one Recommendation to another, depending on 100 the characteristics required to distinguish one application from 101 another'. An indication of the bit rate and of the type of fibre 102 employed is common to all ACs specified in ITU-T Recommendations. 104 ACs are perhaps best illustrated by example, in the handbook we find 105 two examples: 107 From G.957 the AC 'L-16.2' wherein: 109 o L indicates a target distance of ~ 80kn (long reach) 111 o 16 indicates bit rate is STM-16 (2.48832 Gbits/s) 113 o 2 indicates G.652 fibre (in the 1550nm region) 115 And a more complicated example 'DN100C-2A(L)F' from G.698.2 wherein: 117 o D indicates DWDM 119 o N indicates narrow spectral excursion 121 o 100 indicates minimum channel spacing of 100GHz 123 o C indicates chromatic dispersion limits appropriate to a 124 compensated link 126 o 2 indicates highest class of bit rate supported is NRZ 10G 128 o A indicates that the link may contain optical amplifiers 130 o 3 indicates G.653 fibre 132 o L indicates operating wavelength in the L band 134 o F indicates that FEC must be transmitted 136 3.2. AI 138 In contrast to venerable history of AC, which first appears in 139 Recommendations under the responsiblity of Q6/15 in the 1990s, AI is 140 a more modern creation of Q12/15 and appears first in G.872 141 [ITU-T_G.872] the 'Architecture of optical transport networks' in 142 2012. 144 In G.872 we find that 'the characteristic information of the OCh 145 layer network (is) an optical signal defined by a set of parameters. 146 The central frequency, required bandwidth and other analogue 147 parameters such as signal-to-noise ratio associated with the network 148 media channel are of particular interest. The parameters are 149 captured in an application identifier, which covers both standardized 150 as well as proprietary applications'. These parameters defining the 151 characteristic information of an optical signal are the same 152 parameters as were heretofore encoded in ACs; the difference is that 153 AI covers 'standard and proprietary applications'. In a footnote we 154 find the important qualification that 'an application identifier 155 applies to the transmitter, the network media channel and receiver 156 combination. It does not apply to a single interface'. 158 In G.874 [ITU-T_G.874], which is a management specification under the 159 responsibility of Q14/15 entitled 'Management aspects of optical 160 transport network elements', there is a clause describing management 161 of AIs. It states that G.872 has 'generalised Application Code to 162 Application Identifier so that proprietary (i.e. non standard) 163 applications can be handled'. There is still no definition of AI 164 here; for that we have to consult G.874.1 [ITU-T_G.874.1] the 165 'Optical transport network (OTN): Protocol-neutral management 166 information model for the network element view' where, in the UML 167 model supplied with that Recommendation we find: 169 The syntax of ApplicationIdentifier is a 170 pair{ApplicationIdentifierType, PrintableString}. The value of 171 ApplicationIdentifierType is either STANDARD or PROPRIETARY. The 172 value of PrintableString represents the standard application code 173 as defined in the ITU-T Recommendations or a vendor-specific 174 proprietary code. 176 This is the Holy Grail; from it we can draw some axioms which we list 177 below. 179 3.3. AC and AI axioms 181 Note that we also discuss proprietary codes (PC) in this section. 183 o An AI may contain an AC OR a PC. 185 o An AC is NOT the same as an AI. 187 o An AI is NOT the same as an AC. 189 o A PC is NOT the same as an AI. 191 o An AI is not the same as a PC. 193 o ACs are defined in ITU-T standards and the corresponding AI would 194 be {STANDARD, AC value} 196 o By definition PCs are proprietary and not defined in standards 197 but, the vendor specific values would be given as printable 198 strings in an AI as {PROPRIETARY, PC value}. 200 4. Using AIs 202 The IETF specifies protocols; CCAMP in particular specifies protocols 203 that are used to configure and control equipment containing optical 204 interfaces that conform to ITU-T specifications. It is quite natural 205 to imagine that routing, signaling or link management protocols, or 206 extensions to such protocols, developed in CCAMP might need to encode 207 parameters describing those optical interfaces. In the past using an 208 AC would have been a natural choice to do that, now, with the 209 specificaton of AI, using AI would seem to be a best practice. 210 Indeed we see existence proof in some work in progress in CCAMP 211 [SNMP][LMP] that AI is already being used. 213 The IETF's work is used throughout the industry. Other bodies 214 'profile' protocol specifications developed in IETF and use those 215 profiles as building blocks for specification of implementation 216 agreements designed to enable the development of multivendor 217 interoperable systems. It is vital therefore that we consider the 218 use of AI as currently specified from that perspective. In the 219 following sections we consider the use of Standard and Proprietary 220 ACs in AIs. 222 4.1. Using AI containing a STANDARD AC 224 When a protocol component receives or sends an AI containing the 225 ApplicationIdentifierType set to STANDARD there is no ambiguity about 226 the meaning or provenance of the PrintAble string the AI contains: It 227 MUST be an AC defined in an ITU-T Recommendation. We note that, 228 unfortunately, there is no single registry of ITU-T ACs, but there 229 are a relatively small number of Recommendations that need to be 230 examined to determine whether an AC identified in this way, i.e as 231 standard, really is what it claims to be. 233 The situation is not so clear cut for proprietary ACs which we 234 consider next. 236 4.2. Using AI containing a PROPRIETARY AC 238 When a protocol component receives an AI containing the 239 ApplicationIdentifierType set to PROPRIETARY there are two 240 possibilities: it either recognizes the AC or it does not. We can 241 dismiss the second of these trivially; robust specifications of 242 protocols contain instructions for handling unrecognised or 243 incorectly formatted information elements. The first case, wherein 244 the AC is recognised, might also seem straightforward - after all the 245 AC has been 'recognised' - but it is not. 247 Because there is, beyond the fact that it is represented by a 248 printable string, no definition of a proprietary code it is 249 impossible for a protocol entity to distinguish between a PROPRIETARY 250 AC that it believes to be one of its own (i.e sent by a protocol peer 251 using the same proprietary list of PROPRIETARY ACs) and one sent from 252 an implementation using a different proprietary list of ACs one of 253 which is, unfortunately, identical. Proprietary ACs are not uniquely 254 self identifying and a risk of collision exists. This means that 255 they may not be used in a manner that requires them to be unique. 257 5. Discussion 259 AI is a relatively new concept that allows for representation of 260 standard (ITU-T specified) and proprietary ACs. This is valuable and 261 we believe that protocol specifications that need to communicate 262 optical interface parameters should use AI henceforth. 264 This memo identifies a potential problem with the use of proprietary 265 ACs wherein a 'collision' between ACs may occur. We believe such 266 collisions to be dangerous and that they should be eliminated. How 267 that is done is FFS but we note that the definition of AI is the 268 responsibility of ITU-T SG15 and it is important that a solution be 269 developed. 271 Until such time as a resolution to this problem has been achieved we 272 believe that proprietary application codes should be considered 273 dangerous and not used in a way that requires them to be unique i.e. 274 not used at all. Standard ACs are not afflicted by this problem and 275 may be used. 277 6. IANA Considerations 279 This memo includes no request to IANA. 281 7. Security Considerations 283 TBD 285 8. References 287 8.1. Normative References 289 [ITU-T_G.695] 290 ITU-T, "ITU-T G.695 Optical interfaces for coarse 291 wavelength division multiplexing applications; 10/2010", 292 2010, . 294 [ITU-T_G.698.1] 295 ITU-T, "ITU-T G.698.1 Multichannel DWDM applications with 296 single-channel optical interfaces; 11/2009", 2009, 297 . 299 [ITU-T_G.698.2] 300 ITU-T, "ITU-T G.698.2 Amplified multichannel dense 301 wavelength division multiplexing applications with single 302 channel optical interfaces ; 11/2009", 2009, 303 . 305 [ITU-T_G.872] 306 ITU-T, "ITU-T G.872 - Architecture of optical transport 307 networks; 10/2012", 2012, 308 . 310 [ITU-T_G.874] 311 ITU-T, "ITU-T G.874 - Management aspects of optical 312 transport network elements; 08/2013", 2013, 313 . 315 [ITU-T_G.874.1] 316 ITU-T, "ITU-T G.874.1 - Optical transport network: 317 Protocol-neutral management information model for the 318 network element view; 10/2012", 2012, 319 . 321 [ITU-T_G.957] 322 ITU-T, "ITU-T G.957 Optical interfaces for equipments and 323 systems relating to the synchronous digital hierarchy; 324 03/2006", 2006, . 326 [LMP] IETF, "(work in progress) Extension to the Link Management 327 Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division 328 Multiplexing (DWDM) Optical Line Systems to manage the 329 application code of optical interface parameters in DWDM 330 application draft-dharinigert-ccamp-g-698-2-lmp-08", 2014, 331 . 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [SNMP] IETF, "(work in progress) An SNMP MIB extension to RFC3591 338 to manage optical interface parameters of DWDM 339 applications", 2014, . 342 8.2. Informative References 344 [ITU-T_OFCS] 345 ITU-T, "ITU-T Handbook - Optical fibres, cables and 346 systems, ITU-T Manual 2009", 2009. 348 Author's Address 350 Paul Doolan 351 Coriant 352 USA 354 Phone: +1 972 357 5822 355 Email: paul.doolan@coriant.com