idnits 2.17.1 draft-dharini-dwdm-if-yang-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 contain references ([ITU.G874.1], [ITU.G698.2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 314 has weird spacing: '...code-id uin...' == Line 315 has weird spacing: '...de-type uint8...' == Line 321 has weird spacing: '...code-id uint...' == Line 322 has weird spacing: '...de-type uint8...' == Line 338 has weird spacing: '...de-type uint8...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 17, 2016) is 2961 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) == Missing Reference: 'ITU-T G.7710' is mentioned on line 118, but not defined == Missing Reference: 'RFC6241' is mentioned on line 548, but not defined == Missing Reference: 'RFC6242' is mentioned on line 550, but not defined == Missing Reference: 'RFC6536' is mentioned on line 550, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 558, but not defined == Missing Reference: 'RFC6020' is mentioned on line 572, but not defined == Unused Reference: 'RFC2863' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'ITU.G959.1' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'ITU.G826' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'ITU.G8201' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'ITU.G7710' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'I-D.kdkgall-ccamp-dwdm-if-mng-ctrl-fwk' is defined on line 729, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G698.2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G872' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G798' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G959.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G826' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G8201' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G694.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G7710' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-01) exists of draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-00 Summary: 2 errors (**), 0 flaws (~~), 28 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G.Galimberti, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track R.Kunze, Ed. 5 Expires: September 18, 2016 Deutsche Telekom 6 K. Lam, Ed. 7 Alcatel-Lucent 8 D. Hiremagalur, Ed. 9 G. G.Grammel, Ed. 10 Juniper 11 L.Fang, Ed. 12 G.Ratterree, Ed. 13 Microsoft 14 March 17, 2016 16 A YANG model to manage the optical interface parameters for an external 17 transponder in a WDM network 18 draft-dharini-dwdm-if-yang-00 20 Abstract 22 This memo defines a Yang model that translates the SNMP mib module 23 defined in draft-galikunze-ccamp-dwdm-if-snmp-mib for managing single 24 channel optical interface parameters of DWDM applications. This 25 model is to support the optical parameters specified in ITU-T G.698.2 26 [ITU.G698.2] and application identifiers specified in ITU-T G.874.1 27 [ITU.G874.1] . Note that G.874.1 encompasses vendor-specific codes, 28 which if used would make the interface a single vendor IaDI and could 29 still be managed. 31 The Yang model defined in this memo can be used for Optical 32 Parameters monitoring and/or configuration of the endpoints of the 33 multi-vendor IaDI optical link. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 18, 2016. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. The Internet-Standard Management Framework . . . . . . . . . 4 76 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4.1. Optical Parameters Description . . . . . . . . . . . . . 5 79 4.1.1. Rs-Ss Configuration . . . . . . . . . . . . . . . . . 6 80 4.1.2. Table of Application Codes . . . . . . . . . . . . . 7 81 4.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.3. Optical Interface for external transponder in a WDM 83 network . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 5. Structure of the Yang Module . . . . . . . . . . . . . . . . 8 85 6. Yang Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 11.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 94 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 This memo defines a Yang model that translates the SNMP mib module 100 defined in draft-galikunze-ccamp-dwdm-if-snmp-mib for managing single 101 channel optical interface parameters of DWDM applications, using the 102 approach specified in G.698.2. This model is to support the optical 103 parameters specified in ITU-T G.698.2 [ITU.G698.2], application 104 identifiers specified in ITU-T G.874.1 [ITU.G874.1] and the Optical 105 Power at Transmitter and Receiver side. Note that G.874.1 106 encompasses vendor-specific codes, which if used would make the 107 interface a single vendor IaDI and could still be managed.` 109 [Editor's note: In G.698.2 this corresponds to the optical path from 110 point S to R; network media channel is also used and explained in 111 draft-ietf-ccamp-flexi-grid-fwk-02] 113 Management will be performed at the edges of the network media 114 channel (i.e., at the transmitters and receivers attached to the S 115 and R reference points respectively) for the relevant parameters 116 specified in G.698.2 [ITU.G698.2], G.798 [ITU.G798], G.874 117 [ITU.G874], and the performance parameters specified in G.7710/Y.1701 118 [ITU-T G.7710] and G.874.1 [ITU.G874.1]. 120 G.698.2 [ITU.G698.2] is primarily intended for metro applications 121 that include optical amplifiers. Applications are defined in G.698.2 122 [ITU.G698.2] using optical interface parameters at the single-channel 123 connection points between optical transmitters and the optical 124 multiplexer, as well as between optical receivers and the optical 125 demultiplexer in the DWDM system. This Recommendation uses a 126 methodology which does not explicitly specify the details of the 127 optical network between reference point Ss and Rs, e.g., the passive 128 and active elements or details of the design. The Recommendation 129 currently includes unidirectional DWDM applications at 2.5 and 10 130 Gbit/s (with 100 GHz and 50 GHz channel frequency spacing). Work is 131 still under way for 40 and 100 Gbit/s interfaces. There is 132 possibility for extensions to a lower channel frequency spacing. 133 This document specifically refers to the "application code" defined 134 in the G.698.2 [ITU.G698.2] and included in the Application 135 Identifier defined in G.874.1 [ITU.G874.1] and G.872 [ITU.G872], plus 136 a few optical parameters not included in the G.698.2 application code 137 specification. 139 This draft refers and supports the draft-kdkgall-ccamp-dwdm-if-mng- 140 ctrl-fwk 142 The building of a yang model describing the optical parameters 143 defined in G.698.2 [ITU.G698.2], and reflected in G.874.1 144 [ITU.G874.1], allows the different vendors and operator to retrieve, 145 provision and exchange information across the G.698.2 multi-vendor 146 IaDI in a standardized way. In addition to the parameters specified 147 in ITU recommendations the Yang models support also the "vendor 148 specifica application identifier", the Tx and Rx power at the Ss and 149 Rs points and the channel frequency. 151 The Yang Model, reporting the Optical parameters and their values, 152 characterizes the features and the performances of the optical 153 components and allow a reliable link design in case of multi vendor 154 optical networks. 156 Although RFC 3591 [RFC3591], which draft-galikunze-ccamp-DWDM-if- 157 snmp-mib is extending, describes and defines the SNMP MIB of a number 158 of key optical parameters, alarms and Performance Monitoring, as this 159 RFC is over a decade old, it is primarily pre-OTN, and a more 160 complete and up-to-date description of optical parameters and 161 processes can be found in the relevant ITU-T Recommendations. The 162 same considerations can be applied to the RFC 4054 [RFC4054]. 164 2. The Internet-Standard Management Framework 166 For a detailed overview of the documents that describe the current 167 Internet-Standard Management Framework, please refer to section 7 of 168 RFC 3410 [RFC3410]. 170 This memo specifies a Yang model for optical interfaces. 172 3. Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119] In 177 the description of OIDs the convention: Set (S) Get (G) and Trap (T) 178 conventions will describe the action allowed by the parameter. 180 4. Overview 181 Figure 1 shows a set of reference points, for single-channel 182 connection between transmitters (Tx) and receivers (Rx). Here the 183 DWDM network elements include an OM and an OD (which are used as a 184 pair with the opposing element), one or more optical amplifiers and 185 may also include one or more OADMs. 187 +-------------------------------------------------+ 188 Ss | DWDM Network Elements | Rs 189 +--+ | | | \ / | | | +--+ 190 Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1 191 +---+ | | | | | +------+ | | | | | +--+ 192 +---+ | | | | | | | | | | | | +--+ 193 Tx L2--|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2 194 +---+ | | | | | | | | | | | | +--+ 195 +---+ | | | | | +------+ | | | | | +--+ 196 Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 197 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 198 +-----------+ | | +----------+ 199 +--+ +--+ 200 | | 201 Rs v | Ss 202 +-----+ +-----+ 203 |RxLx | |TxLx | 204 +-----+ +-----+ 205 Ss = reference point at the DWDM network element tributary output 206 Rs = reference point at the DWDM network element tributary input 207 Lx = Lambda x 208 OM = Optical Mux 209 OD = Optical Demux 210 OADM = Optical Add Drop Mux 212 from Fig. 5.1/G.698.2 214 Figure 1: External transponder in WDM netwoks 216 4.1. Optical Parameters Description 218 The link between the external transponders through a WDM network 219 media channels are managed at the edges, i.e. at the transmitters 220 (Tx) and receivers (Rx) attached to the S and R reference points 221 respectively. The set of parameters that could be managed are 222 defined by the "application code" notation 224 The definitions of the optical parameters are provided below to 225 increase the readability of the document, where the definition is 226 ended by (R) the parameter can be retrieve with a read, when (W) it 227 can be provisioned by a write, (R,W) can be either read or written. 229 4.1.1. Rs-Ss Configuration 231 The Rs-Ss configuration table allows configuration of Central 232 Frequency, Power and Application codes as described in [ITU.G698.2] 233 and G.694.1 [ITU.G694.1] 234 This parameter report the current Transceiver Output power, it can be 235 either a setting and measured value (G, S). 237 Central frequency (see G.694.1 Table 1) (see G.694.1 Table 1): 238 This parameter indicates the Central frequency value that Ss and 239 Rs will be set to work (in THz). See the details in Section 6/ 240 G.694.1 (G, S). 242 Single-channel application codes(see G.698.2): 243 This parameter indicates the transceiver application code at Ss 244 and Rs as defined in [ITU.G698.2] Chapter 5.4 - this parameter can 245 be called Optical Interface Identifier OII as per [draft- 246 martinelli-wson-interface-class](G). 248 Number of Single-channel application codes Supported 249 This parameter indicates the number of Single-channel application 250 codes supported by this interface (G). 252 Current Laser Output power: 253 This parameter report the current Transceiver Output power, it can 254 be either a setting and measured value (G, S). 256 Current Laser Input power: 257 This parameter report the current Transceiver Input power (G). 259 +---------------------------------------------+---------+-----------+ 260 | PARAMETERS | Get/Set | Reference | 261 +---------------------------------------------+---------+-----------+ 262 | Central frequency Value | G,S | G.694.1 | 263 | | | S.6 | 264 | Single-channel application codes | G | G.698.2 | 265 | | | S.5.3 | 266 | Number of Single-channel application codes | G | N.A. | 267 | Supported | | | 268 | Current Output Power | G,S | N.A. | 269 | Current Input Power | G | N.A. | 270 +---------------------------------------------+---------+-----------+ 272 Table 1: Rs-Ss Configuration 274 4.1.2. Table of Application Codes 276 This table has a list of Application codes supported by this 277 interface at point R are defined in G.698.2. 279 Application code Identifier: 280 The Identifier for the Application code. 282 Application code Type: 283 This parameter indicates the transceiver type of application code 284 at Ss and Rs as defined in [ITU.G874.1], that is used by this 285 interface Standard = 0, PROPRIETARY = 1 286 The first 6 octets of the printable string will be the OUI 287 (organizationally unique identifier) assigned to the vendor 288 whose implementation generated the Application Identifier Code. 290 Application code Length: 291 The number of octets in the Application Code. 293 Application code: 294 This is the application code that is defined in G.698.2 or the 295 vendor generated code which has the OUI. 297 4.2. Use Cases 299 The use cases are described in draft-kdkgall-ccamp-dwdm-if-mng-ctrl- 300 fwk 302 4.3. Optical Interface for external transponder in a WDM network 304 The ietf-ext-xponder-wdm-if is an augment to the ietf-interface. It 305 allows the user to set the application code/vendor transceiver class/ 306 Central frequency and the output power. The module can also be used 307 to get the list of supported application codes/transceiver class and 308 also the Central frequency/output power/input power of the interface. 310 module: ietf-ext-xponder-wdm-if 311 augment /if:interfaces/if:interface: 312 +--rw optIfOChRsSs 313 +--rw if-current-application-code 314 | +--rw application-code-id uint8 315 | +--rw application-code-type uint8 316 | +--rw application-code-length uint8 317 | +--rw application-code? string 318 +--ro if-supported-application-codes 319 | +--ro number-application-codes-supported? uint32 320 | +--ro application-codes-list* [application-code-id] 321 | +--ro application-code-id uint8 322 | +--rw application-code-type uint8 323 | +--rw application-code-length uint8 324 | +--ro application-code? string 325 +--rw output-power? int32 326 +--ro input-power? int32 327 +--rw central-frequency? uint32 329 notifications: 330 +---n opt-if-och-central-frequency-change 331 | +--ro if-name? leafref 332 | +--ro new-central-frequency 333 | +--ro central-frequency? uint32 334 +---n opt-if-och-application-code-change 335 | +--ro if-name? leafref 336 | +--ro new-application-code 337 | +--ro application-code-id? uint8 338 | +--rw application-code-type uint8 339 | +--rw application-code-length uint8 340 | +--ro application-code? string 342 5. Structure of the Yang Module 344 ietf-ext-xponder-wdm-if is a top level model for the support of this 345 feature. 347 6. Yang Module 349 The ietf-ext-xponder-wdm-if is defined as an extension to ietf 350 interfaces. 352 file "ietf-ext-xponder-wdm-if.yang" 354 module ietf-ext-xponder-wdm-if { 355 namespace "urn:ietf:params:xml:ns:yang:ietf-ext-xponder-wdm-if"; 356 prefix ietf-ext-xponder-wdm-if; 358 import ietf-interfaces { 359 prefix if; 360 } 362 organization 363 "IETF CCAMP 364 Working Group"; 366 contact 367 "WG Web: 368 WG List: 370 Editor: Dharini Hiremagalur 371 "; 373 description 374 "This module contains a collection of YANG definitions for 375 configuring Optical interfaces. 377 Copyright (c) 2016 IETF Trust and the persons identified 378 as authors of the code. All rights reserved. 380 Redistribution and use in source and binary forms, with or 381 without modification, is permitted pursuant to, and 382 subject to the license terms contained in, the Simplified 383 BSD License set forth in Section 4.c of the IETF Trust's 384 Legal Provisions Relating to IETF Documents 385 (http://trustee.ietf.org/license-info)."; 387 revision "2016-03-17" { 388 description 389 "Initial revision."; 390 reference 391 "RFC XXXX: A YANG Data Model for Optical 392 Management of an Interface for an external 393 transponder in a WDM netwrok 394 reference 395 draft-dharini-netmod-dwdm-if-yang 3.0"; 397 } 398 grouping opt-if-och-application-code { 399 description "Application code entity."; 400 leaf application-code-id { 401 type uint8 { 402 range "1..255"; 403 } 404 description 405 "Id for the Application code"; 406 } 407 leaf application-code-type { 408 type uint8 { 409 range "0..1"; 410 } 411 description 412 "Type for the Application code 413 0 - Standard, 1 - Proprietory 414 When the Type is Proprietory, then the 415 first 6 octets of the application-code 416 will be the OUI (organizationally unique 417 identifier)"; 419 } 420 leaf application-code-length { 421 type uint8 { 422 range "1..255"; 423 } 424 description 425 "Number of octets in the Application code"; 427 } 428 leaf application-code { 429 type string { 430 length "1..255"; 431 } 432 description "This parameter indicates the 433 transceiver application code at Ss and Rs as 434 defined in [ITU.G698.2] Chapter 5.3, that 435 is/should be used by this interface. 436 The optIfOChApplicationsCodeList has all the 437 application codes supported by this 438 interface."; 440 } 441 } 443 grouping opt-if-och-application-code-list { 444 description "List of Application codes group."; 445 leaf number-application-codes-supported { 446 type uint32; 447 description "Number of Application codes 448 supported by this interface"; 449 } 450 list application-code-list { 451 key "application-code-id"; 452 description "List of the application codes"; 453 uses opt-if-och-application-code; 454 } 455 } 457 grouping opt-if-och-power { 458 description "Interface optical Power"; 459 leaf output-power { 460 type int32; 461 units ".01dbm"; 462 description "The output power for this interface in 463 .01 dBm. 464 The setting of the output power is 465 optional"; 466 } 468 leaf input-power { 469 type int32; 470 units ".01dbm"; 471 config false; 472 description "The current input power of this 473 interface"; 474 } 475 } 477 grouping opt-if-och-central-frequency { 478 description "Interface Central Frequency"; 479 leaf central-frequency { 480 type uint32; 481 description "This parameter indicate This parameter 482 indicates the frequency of this interface "; 484 } 485 } 487 notification opt-if-och-central-frequency-change { 488 description "A change of Central Frequency has been 489 detected."; 490 leaf "if-name" { 491 type leafref { 492 path "/if:interfaces/if:interface/if:name"; 493 } 494 description "Interface name"; 495 } 496 container opt-if-och-central-frequency { 497 description "The new Central Frequency of the 498 interface"; 499 uses opt-if-och-central-frequency; 500 } 501 } 503 notification opt-if-och-application-code-change { 504 description "A change of Application code has been 505 detected."; 506 leaf "if-name" { 507 type leafref { 508 path "/if:interfaces/if:interface/if:name"; 509 } 510 description "Interface name"; 511 } 512 container new-application-code { 513 description "The new application code for the 514 interface"; 515 uses opt-if-och-application-code; 516 } 517 } 519 augment "/if:interfaces/if:interface" { 520 description "Parameters for an optical interface"; 521 container optIfOChRsSs { 522 description "RsSs path configuration for an interface"; 523 container if-current-application-code { 524 description "Current Application code of the 525 interface"; 526 uses opt-if-och-application-code; 527 } 529 container if-supported-application-codes { 530 config false; 531 description "Supported Application codes of 532 the interface"; 533 uses opt-if-och-application-code-list; 534 } 536 uses opt-if-och-power; 537 uses opt-if-och-central-frequency; 539 } 540 } 541 } 543 545 7. Security Considerations 547 The YANG module defined in this memo is designed to be accessed via 548 the NETCONF protocol [RFC6241]. he lowest NETCONF layer is the secure 549 transport layer and the mandatory-to-implement secure transport is 550 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 551 the means to restrict access for particular NETCONF users to a pre- 552 configured subset of all available NETCONF protocol operation and 553 content. 555 8. IANA Considerations 557 This document registers a URI in the IETF XML registry [RFC3688]. 558 Following the format in [RFC3688], the following registration is 559 requested to be made: 561 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces:ietf-ext-xponder- 562 wdm-if 564 Registrant Contact: The IESG. 566 XML: N/A, the requested URI is an XML namespace. 568 This document registers a YANG module in the YANG Module Names 569 registry [RFC6020]. 571 This document registers a YANG module in the YANG Module Names 572 registry [RFC6020]. 574 prefix: ietf-ext-xponder-wdm-if reference: RFC XXXX 576 9. Acknowledgements 578 Gert Grammel is partly funded by European Union Seventh Framework 579 Programme under grant agreement 318514 CONTENT. 581 10. Contributors 583 Dean Bogdanovic 584 Juniper Networks 585 Westford 586 U.S.A. 587 email deanb@juniper.net 589 Bernd Zeuner 590 Deutsche Telekom 591 Darmstadt 592 Germany 593 email B.Zeuner@telekom.de 595 Arnold Mattheus 596 Deutsche Telekom 597 Darmstadt 598 Germany 599 email a.mattheus@telekom.de 601 Manuel Paul 602 Deutsche Telekom 603 Berlin 604 Germany 605 email Manuel.Paul@telekom.de 607 Walid Wakim 608 Cisco 609 9501 Technology Blvd 610 ROSEMONT, ILLINOIS 60018 611 UNITED STATES 612 email wwakim@cisco.com 614 11. References 616 11.1. Normative References 618 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 619 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 620 . 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 628 Schoenwaelder, Ed., "Structure of Management Information 629 Version 2 (SMIv2)", STD 58, RFC 2578, 630 DOI 10.17487/RFC2578, April 1999, 631 . 633 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 634 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 635 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 636 . 638 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 639 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 640 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 641 . 643 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 644 Managed Objects for the Optical Interface Type", RFC 3591, 645 DOI 10.17487/RFC3591, September 2003, 646 . 648 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 649 Lambda-Switch-Capable (LSC) Label Switching Routers", 650 RFC 6205, DOI 10.17487/RFC6205, March 2011, 651 . 653 [ITU.G698.2] 654 International Telecommunications Union, "Amplified 655 multichannel dense wavelength division multiplexing 656 applications with single channel optical interfaces", 657 ITU-T Recommendation G.698.2, November 2009. 659 [ITU.G709] 660 International Telecommunications Union, "Interface for the 661 Optical Transport Network (OTN)", ITU-T Recommendation 662 G.709, March 2003. 664 [ITU.G872] 665 International Telecommunications Union, "Architecture of 666 optical transport networks", ITU-T Recommendation G.872, 667 November 2001. 669 [ITU.G798] 670 International Telecommunications Union, "Characteristics 671 of optical transport network hierarchy equipment 672 functional blocks", ITU-T Recommendation G.798, October 673 2010. 675 [ITU.G874] 676 International Telecommunications Union, "Management 677 aspects of optical transport network elements", 678 ITU-T Recommendation G.874, July 2010. 680 [ITU.G874.1] 681 International Telecommunications Union, "Optical transport 682 network (OTN): Protocol-neutral management information 683 model for the network element view", ITU-T Recommendation 684 G.874.1, January 2002. 686 [ITU.G959.1] 687 International Telecommunications Union, "Optical transport 688 network physical layer interfaces", ITU-T Recommendation 689 G.959.1, November 2009. 691 [ITU.G826] 692 International Telecommunications Union, "End-to-end error 693 performance parameters and objectives for international, 694 constant bit-rate digital paths and connections", 695 ITU-T Recommendation G.826, November 2009. 697 [ITU.G8201] 698 International Telecommunications Union, "Error performance 699 parameters and objectives for multi-operator international 700 paths within the Optical Transport Network (OTN)", 701 ITU-T Recommendation G.8201, April 2011. 703 [ITU.G694.1] 704 International Telecommunications Union, "Spectral grids 705 for WDM applications: DWDM frequency grid", 706 ITU-T Recommendation G.694.1, June 2002. 708 [ITU.G7710] 709 International Telecommunications Union, "Common equipment 710 management function requirements", ITU-T Recommendation 711 G.7710, May 2008. 713 11.2. Informative References 715 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 716 "Introduction and Applicability Statements for Internet- 717 Standard Management Framework", RFC 3410, 718 DOI 10.17487/RFC3410, December 2002, 719 . 721 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 722 DOI 10.17487/RFC2629, June 1999, 723 . 725 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 726 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 727 September 2005, . 729 [I-D.kdkgall-ccamp-dwdm-if-mng-ctrl-fwk] 730 Kunze, R., Grammel, G., Beller, D., and G. Galimberti, "A 731 framework for Management and Control of G.698.2 optical 732 interface parameters", draft-kdkgall-ccamp-dwdm-if-mng- 733 ctrl-fwk-00 (work in progress), October 2015. 735 [RFC4054] Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other 736 Constraints on Optical Layer Routing", RFC 4054, 737 DOI 10.17487/RFC4054, May 2005, 738 . 740 Appendix A. Change Log 742 This optional section should be removed before the internet draft is 743 submitted to the IESG for publication as an RFC. 745 Note to RFC Editor: please remove this appendix before publication as 746 an RFC. 748 Appendix B. Open Issues 750 Note to RFC Editor: please remove this appendix before publication as 751 an RFC. 753 Authors' Addresses 755 Gabriele Galimberti (editor) 756 Cisco 757 Via Santa Maria Molgora, 48 c 758 20871 - Vimercate 759 Italy 761 Phone: +390392091462 762 Email: ggalimbe@cisco.com 763 Ruediger Kunze (editor) 764 Deutsche Telekom 765 Dddd, xx 766 Berlin 767 Germany 769 Phone: +49xxxxxxxxxx 770 Email: RKunze@telekom.de 772 Kam Lam (editor) 773 Alcatel-Lucent 774 USA 776 Phone: +1 732 331 3476 777 Email: kam.lam@alcatel-lucent.com 779 Dharini Hiremagalur (editor) 780 Juniper 781 1194 N Mathilda Avenue 782 Sunnyvale - 94089 California 783 USA 785 Email: dharinih@juniper.net 787 Gert Grammel (editor) 788 Juniper 789 Oskar-Schlemmer Str. 15 790 80807 Muenchen 791 Germany 793 Phone: +49 1725186386 794 Email: ggrammel@juniper.net 796 Luyuan Fang (editor) 797 Microsoft 798 5600 148th Ave NE 799 Redmond, WA 98502 800 USA 802 Email: lufang@microsoft.com 803 Gary Ratterree (editor) 804 Microsoft 805 5600 148th Ave NE 806 Redmond, WA 98502 807 USA 809 Email: gratt@microsoft.com