idnits 2.17.1 draft-liu-netmod-yang-schedule-04.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 == Line 163 has weird spacing: '...eration ope...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 6, 2017) is 2423 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: 'RFC3688' is mentioned on line 594, but not defined == Missing Reference: 'RFC6242' is mentioned on line 618, but not defined == Missing Reference: 'RFC6536' is mentioned on line 618, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Unused Reference: 'RFC6021' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC6087' is defined on line 717, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) ** Downref: Normative reference to an Informational RFC: RFC 7384 ** Downref: Normative reference to an Informational RFC: RFC 7399 ** Downref: Normative reference to an Experimental RFC: RFC 7758 == Outdated reference: A later version (-07) exists of draft-birrane-dtn-ama-05 ** Downref: Normative reference to an Informational draft: draft-birrane-dtn-ama (ref. 'I-D.birrane-dtn-ama') == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-03 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-08 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Liu 3 Internet-Draft Jabil 4 Intended status: Standards Track I. Bryskin 5 Expires: March 10, 2018 Huawei Technologies 6 V. Beeram 7 Juniper Networks 8 T. Saad 9 Cisco Systems Inc 10 H. Shah 11 Ciena 12 O. Gonzalez de Dios 13 Telefonica 14 September 6, 2017 16 A YANG Data Model for Configuration Scheduling 17 draft-liu-netmod-yang-schedule-04 19 Abstract 21 This document describes a data model for configuration scheduling. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 10, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Configuration Scheduling YANG Data Model Overview . . . . . . 3 61 4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Relations to Datastores . . . . . . . . . . . . . . . . . . . 6 63 5.1. Validation . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Schedules Expansion and Operational States . . . . . . . 7 65 5.3. Server Executions at Scheduled Moments . . . . . . . . . 7 66 5.4. Interactions with Locks . . . . . . . . . . . . . . . . . 7 67 5.5. Interactions with Authorization Mechanism . . . . . . . . 7 68 6. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 7 69 7. Configuration Scheduling YANG Module . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 11.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 This document introduces a YANG [RFC6020] [RFC7950] data model for 81 configuration scheduling. This model can be used together with other 82 YANG data models to specify a schedule applied on a configuration 83 data node, so that the configuration data can take effect according 84 to the schedule. Such a configuration schedule can be one-time or 85 recurring, with its properties persistently saved in the datastores 86 of the management system server. 88 The mechanism described in this document is designed to complement 89 the one described in [RFC7758], which defines a capability extension 90 to NETCONF to allow time-triggered RPCs. Such RPCs can be executed 91 at a future time moment, but cannot be repeated and is not saved in 92 the persistent datastores. 94 1.1. Terminology 96 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14, [RFC2119]. 101 The following terms are defined in [RFC7950] and are not redefined 102 here: 104 o augment 106 o data model 108 o data node 110 2. Motivation 112 Some applications benefit from resource scheduling to allow operators 113 to plan ahead of time. Traffic engineering is one of such examples 114 [RFC7399]. When configuration and state models are designed for such 115 applications, it has been considered that certain data objects need 116 to be configured according to predefined schedules. In other 117 situations, operators need to deconfigure certain data objects at 118 predefined schedules for the purposes such as maintenance. These 119 data objects are interpreted and implemented by the applicable 120 applications. 122 Delay/Disruption Tolerant Networking (DTN) is another example for 123 which the scheduled configuration can be used, where a long-lived, 124 reliable, low-latency sequenced data delivery session is 125 unsustainable. Section 4.3 of [I-D.birrane-dtn-ama] describes the 126 Autonomous Parameterized Control. Time-based event is one of the two 127 types of triggers in such a system. 129 3. Configuration Scheduling YANG Data Model Overview 131 This document defines a YANG data model that specifies configuration 132 schedules for other YANG data models. For each targeted 133 configuration data object or a group of configuration data objects, 134 an entry is specified along with requested schedules using this 135 configuration schedule model. The application implementing the 136 targeted schema nodes implements the configuration schedules, 137 configuring or deconfiguring the specified objects according to the 138 specified schedules. The model schema of the targeted application 139 does not need changes, so the data model described in this document 140 can be used for any data model. The configuration scheduling YANG 141 data model has the following structure: 143 module: ietf-schedule 144 +--rw configuration-schedules 145 +--rw target* [object] 146 +--rw object yang:xpath1.0 147 +--rw operation? operation 148 +--rw data-value? anydata 149 +--rw schedules 150 | +--rw schedule* [schedule-id] 151 | +--rw schedule-id uint32 152 | +--rw inclusive-exclusive? enumeration 153 | +--rw start? yang:date-and-time 154 | +--rw schedule-duration? string 155 | +--rw repeat-interval? string 156 +--ro state 157 | +--ro future-executions 158 | +--ro execution* [start] 159 | +--ro start yang:date-and-time 160 | +--ro duration? string 161 | +--ro operation? operation 162 +---n execution 163 +---- operation operation 164 +---- datetime? yang:date-and-time 165 +---- results? anydata 167 4. Usage Example 169 The following model defines a list of TE (Traffic Engineering) links 170 which can be configured with specified schedules: 172 module: example 173 +--rw te-links 174 +--rw te-link* [id] 175 +--rw id string 176 +--rw enabled? boolean 178 The following configuration requests that 180 o link-1 is configured weekly for five one-day periods, starting 181 from 2016-09-12T23:20:50.52Z. 183 o link-2 is deconfigured for two hours, starting from 2016-09- 184 15T01:00:00.00Z. 186 187 188 /ex:te-links 189 configure 190 191 192 link-1 193 true 194 195 196 197 198 11 199 2016-09-12T23:20:50.52Z 200 P1D 201 R5/P1W 202 203 204 205 206 /ex:te-links 207 configure 208 209 210 link-2 211 true 212 213 214 215 216 12 217 exclusive 218 2016-09-15T01:00:00.00Z 219 P2H 220 221 222 223 225 The following configuration requests that 227 o link-1 is enabled weekly for five one-day periods, starting from 228 2016-09-12T23:20:50.52Z. 230 o link-2 is not enabled for two hours, starting from 2016-09- 231 15T01:00:00.00Z. 233 234 235 /ex:te-links/ex:te-link[ex:link-id='link-1']/ex:enabled 236 237 set 238 true 239 240 241 11 242 2016-09-12T23:20:50.52Z 243 P1D 244 R5/P1W 245 246 247 248 249 /ex:te-links/ex:te-link[ex:link-id='link-2']/ex:enabled 250 251 set 252 true 253 254 255 12 256 exclusive 257 2016-09-15T01:00:00.00Z 258 P2H 259 260 261 262 264 5. Relations to Datastores 266 NETCONF defines configuration datastores and operations that can be 267 used to access these datastores. The configuration data encoded 268 according to this data model is persistently saved in the proper 269 datastores in the same way as other data model, such as ietf- 270 interfaces. 272 5.1. Validation 274 When configuration data based on this model is received, the server 275 MUST perform syntax validations on the received data nodes, and 276 examine the requested schedules. The server does not validate 277 whether requested target configuration data can be applied to the 278 target configuration objects, until the actual scheduled time 279 arrives. 281 At each scheduled time moment, the server applies the requested 282 target configuration data to the target configuration objects. The 283 server MUST perform the validations on the target configuration data 284 along with the current target configuration objects in the proper 285 datastore. 287 5.2. Schedules Expansion and Operational States 289 The server SHOULD expand these schedules and expose them to the 290 client as operational states. 292 5.3. Server Executions at Scheduled Moments 294 At each scheduled time moment, the server applies the requested 295 target configuration data to the target configuration objects, as if 296 an RPC request is newly received. Whether such a time-triggered 297 configuration is successfully applied depends on the configuration 298 data of the target object and requested configuration data. The 299 results of such executions are sent to the client through 300 notifications. The notification management mechanism described in 301 [I-D.ietf-netconf-yang-push] and 302 [I-D.ietf-netconf-subscribed-notifications] can be used to enable, 303 disable, subscribe, filter, and replay the notifications. 305 5.4. Interactions with Locks 307 The rules of datastore lock specified by NETCONF [RFC6241] are 308 checked when the schedule configuration data is received and when the 309 target configuration data is applied. 311 5.5. Interactions with Authorization Mechanism 313 If the server implements any authorization mechanism, the 314 authorization rules MUST be checked against this data model schema 315 when the schedule configuration data is received. At each scheduled 316 time moment, the authorization rules MUST be checked against the 317 target objects by using the target configuration data. To check the 318 authorization rules, the server uses the same client credential 319 learned when the initial configuration data was received. 321 6. Synchronization Aspects 323 The scheduling mechanisms described in this document assume that 324 servers have access to the wall-clock time. Thus, servers are 325 required to acquire the time-of-day from an external time source, for 326 example using the Network Time Protocol [RFC5905], or the Precision 327 Time Protocol [IEEE1588]. 329 It is assumed that the client and servers rely on a common time 330 source, so as to guarantee that schedules are defined with respect to 331 a common reference. In order to avoid the potential ambiguity of 332 different time zones and daylight saving time, it is recommended to 333 define all schedules in the UTC time zone, using the suffix 'Z'. For 334 example, the time 2016-09-12T23:20:50.52Z, is specified with respect 335 to the UTC time zone. 337 7. Configuration Scheduling YANG Module 339 file "ietf-schedule@2017-09-06.yang" 340 module ietf-schedule { 341 yang-version 1.1; 342 namespace "urn:ietf:params:xml:ns:yang:ietf-schedule"; 344 prefix "sch"; 346 import ietf-yang-types { 347 prefix "yang"; 348 } 350 organization 351 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 352 contact 353 "WG Web: 354 WG List: 356 Editor: Xufeng Liu 357 359 Editor: Igor Bryskin 360 362 Editor: Vishnu Pavan Beeram 363 365 Editor: Tarek Saad 366 368 Editor: Himanshu Shah 369 371 Editor: Oscar Gonzalez De Dios 372 "; 374 description 375 "The model allows time scheduling parameters to be specified."; 377 revision 2017-09-06 { 378 description "Initial revision"; 379 reference "TBD"; 380 } 382 /* 383 * Typedefs 384 */ 385 typedef operation { 386 type enumeration { 387 enum configure { 388 description 389 "Create the configuration data."; 390 } 391 enum deconfigure { 392 description 393 "Remove the configuration data."; 394 } 395 enum set { 396 description 397 "Set the specified configuration data."; 398 } 399 enum reset { 400 description 401 "Revert the specified configuration data back to the 402 original value."; 403 } 404 } 405 description "Operation type."; 406 } 408 /* 409 * Groupings 410 */ 412 grouping schedule-config-attributes { 413 description 414 "A group of attributes for a schedule."; 416 leaf inclusive-exclusive { 417 type enumeration { 418 enum inclusive { 419 description 420 "The schedule element is inclusive, i.e., the schedule 421 specifies the time at which the element is enabled."; 423 } 424 enum exclusive { 425 description 426 "The schedule element is exclusive. i.e., the schedule 427 specifies the time at which the element is disabled."; 428 } 429 } 430 default "inclusive"; 431 description 432 "Whether the list item is inclusive or exclusive."; 433 } 434 leaf start { 435 type yang:date-and-time; 436 description "Start time."; 437 } 438 leaf schedule-duration { 439 type string { 440 pattern 441 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?'; 442 } 443 description "Schedule duration in ISO 8601 format."; 444 } 445 leaf repeat-interval { 446 type string { 447 pattern 448 'R\d*/P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?' 449 + '(\d+S)?'; 450 } 451 description "Repeat interval in ISO 8601 format."; 452 } 453 } // schedule-config-attributes 455 grouping schedule-config-notification { 456 description 457 "A group of attributes for a schedule notification."; 459 notification execution { 460 description 461 "Notification event for an execution performed on a target 462 object."; 463 leaf operation { 464 type operation; 465 mandatory true; 466 description "Operation type."; 467 } 468 leaf datetime { 469 type yang:date-and-time; 470 description 471 "The date and time when the execution was performed."; 472 } 473 anydata results { 474 description 475 "This chunk of data contains the results of the execution 476 performed on the target object. The results are the same 477 or equivalent to the contents of a message, 478 Because of the nature of such a target execution, a 479 message is not used to return the execution 480 results. Instead, this notification is used to serve 481 the same purpose."; 482 } 483 } 484 } // schedule-config-notification 486 grouping schedule-state-attributes { 487 description 488 "State attributes for a schedule."; 489 container future-executions { 490 description 491 "The state information of the nexte scheduled event."; 492 list execution { 493 key "start"; 494 description 495 "List of scheduled future executions."; 496 leaf start { 497 type yang:date-and-time; 498 description "Start time."; 499 } 500 leaf duration { 501 type string { 502 pattern 503 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?'; 504 } 505 description "Schedule duration in ISO 8601 format."; 506 } 507 leaf operation { 508 type operation; 509 description "Operation type."; 510 } 511 } // event 512 } // future-events 513 } // schedule-state-attributes 515 grouping schedules { 516 description 517 "A list of schedules defining when a particular 518 configuration takes effect."; 520 container schedules { 521 description 522 "Container of a schedule list defining when a particular 523 configuration takes effect."; 524 list schedule { 525 key "schedule-id"; 526 description "A list of schedule elements."; 527 leaf schedule-id { 528 type uint32; 529 description "Identifies the schedule element."; 530 } 531 uses schedule-config-attributes; 532 } 533 } 534 } // schedules 536 /* 537 * Configuration data and operational state nodes 538 */ 539 container configuration-schedules { 540 description 541 "Serves as top-level container for a list of configuration 542 schedules."; 543 list target { 544 key "object"; 545 description 546 "A list of targets that configuration schedules are 547 applied."; 548 leaf object { 549 type yang:xpath1.0; 550 description 551 "Xpath defining the data items of interest."; 552 } 553 leaf operation { 554 type operation; 555 default "configure"; 556 description 557 "Operation type."; 558 } 559 anydata data-value { 560 description 561 "The data value applied to the leaf data node 562 specified by data-objects. 563 The format of the data value depends on the value of the 564 leaf operation defined above: 565 configure: data-value is the sub-tree added to the 566 target object; 567 deconfigure: data-value is the child to be deleted from 568 the target object; 569 set: the target object MULST be a leaf, and 570 data-value is the new value to be set to 571 the target object; 572 reset: data-value is ignored."; 573 } 574 uses schedules; 575 container state { 576 config false; 577 description 578 "Operational state data."; 579 uses schedule-state-attributes; 580 } // state 582 uses schedule-config-notification; 583 } // target 584 } // configuration-schedules 585 } 586 588 8. IANA Considerations 590 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 591 actual RFC number (and remove this note). 593 This document registers the following namespace URI in the IETF XML 594 registry [RFC3688]: 596 -------------------------------------------------------------------- 597 URI: urn:ietf:params:xml:ns:yang:ietf-schedule 598 Registrant Contact: The IESG. 599 XML: N/A, the requested URI is an XML namespace. 600 -------------------------------------------------------------------- 602 This document registers the following YANG module in the YANG Module 603 Names registry [RFC6020]: 605 -------------------------------------------------------------------- 606 name: ietf-schedule 607 namespace: urn:ietf:params:xml:ns:yang:ietf-schedule 608 prefix: l3te 609 reference: RFC XXXX 610 -------------------------------------------------------------------- 612 9. Security Considerations 614 The configuration, state, action and notification data defined in 615 this document are designed to be accessed via the NETCONF protocol 616 [RFC6241]. The lowest NETCONF layer is the secure transport layer, 617 and the mandatory-to-implement secure transport is Secure Shell (SSH) 618 [RFC6242]. The NETCONF access control model [RFC6536] provides the 619 means to restrict access for particular NETCONF users to a pre- 620 configured subset of all available NETCONF protocol operations and 621 contents. 623 The functionality defined in this memo can potentially allow network 624 reconnaissance; by gathering information about schedules an attacker 625 can learn about the network policy, its temporal behavior, and future 626 events. 628 The schedule YANG model defines schedules that are writable, 629 creatable, and deletable. Therefore, this model may be considered 630 sensitive or vulnerable in some network environments. An attacker 631 may maliciously configure a schedule in a way that disrupts the 632 normal behavior of the network. Furthermore, an attacker may attempt 633 to maliciously set a schedule or a set of schedules in a way that 634 amplifies an attack, or schedules an attack to a particularly 635 sensitive time instant. 637 The use of configuration scheduling implicitly assumes that there is 638 an underlying synchronization or time distribution mechanism. 639 Therefore, an attack on the synchronization mechanism may compromise 640 the configuration scheduling. The security considerations of time 641 protocols are discussed further in [RFC7384]. 643 10. Contributors 645 Tal Mizrahi 647 Email: talmi@marvell.com 649 11. References 651 11.1. Normative References 653 [IEEE1588] 654 IEEE, "IEEE Standard for a Precision Clock Synchronization 655 Protocol for Networked Measurement and Control Systems 656 Version 2", IEEE Standard 1588. 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, 660 DOI 10.17487/RFC2119, March 1997, . 663 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 664 "Network Time Protocol Version 4: Protocol and Algorithms 665 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 666 . 668 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 669 the Network Configuration Protocol (NETCONF)", RFC 6020, 670 DOI 10.17487/RFC6020, October 2010, . 673 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 674 RFC 6021, DOI 10.17487/RFC6021, October 2010, 675 . 677 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 678 and A. Bierman, Ed., "Network Configuration Protocol 679 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 680 . 682 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 683 RFC 7950, DOI 10.17487/RFC7950, August 2016, 684 . 686 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 687 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 688 October 2014, . 690 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 691 Computation Element Architecture", RFC 7399, 692 DOI 10.17487/RFC7399, October 2014, . 695 [RFC7758] Mizrahi, T. and Y. Moses, "Time Capability in NETCONF", 696 RFC 7758, DOI 10.17487/RFC7758, February 2016, 697 . 699 [I-D.birrane-dtn-ama] 700 Birrane, E., "Asynchronous Management Architecture", 701 draft-birrane-dtn-ama-05 (work in progress), March 2017. 703 [I-D.ietf-netconf-subscribed-notifications] 704 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 705 A. Tripathy, "Custom Subscription to Event Notifications", 706 draft-ietf-netconf-subscribed-notifications-03 (work in 707 progress), July 2017. 709 [I-D.ietf-netconf-yang-push] 710 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 711 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 712 YANG datastore push updates", draft-ietf-netconf-yang- 713 push-08 (work in progress), August 2017. 715 11.2. Informative References 717 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 718 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 719 January 2011, . 721 Authors' Addresses 723 Xufeng Liu 724 Jabil 725 8281 Greensboro Drive, Suite 200 726 McLean VA 22102 727 USA 729 EMail: Xufeng_Liu@jabil.com 731 Igor Bryskin 732 Huawei Technologies 734 EMail: Igor.Bryskin@huawei.com 736 Vishnu Pavan Beeram 737 Juniper Networks 739 EMail: vbeeram@juniper.net 741 Tarek Saad 742 Cisco Systems Inc 744 EMail: tsaad@cisco.com 745 Himanshu Shah 746 Ciena 748 EMail: hshah@ciena.com 750 Oscar Gonzalez de Dios 751 Telefonica 753 EMail: oscar.gonzalezdedios@telefonica.com