idnits 2.17.1 draft-liu-netmod-yang-schedule-05.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 (March 1, 2018) is 2247 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 593, but not defined == Missing Reference: 'RFC6242' is mentioned on line 617, but not defined == Missing Reference: 'RFC6536' is mentioned on line 617, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Unused Reference: 'RFC6021' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC6087' is defined on line 716, 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-06 ** 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-09 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-14 -- 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: September 2, 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 March 1, 2018 16 A YANG Data Model for Configuration Scheduling 17 draft-liu-netmod-yang-schedule-05 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 September 2, 2018. 40 Copyright Notice 42 Copyright (c) 2018 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 schedules 148 | +--rw schedule* [schedule-id] 149 | +--rw schedule-id uint32 150 | +--rw inclusive-exclusive? enumeration 151 | +--rw start? yang:date-and-time 152 | +--rw schedule-duration? string 153 | +--rw repeat-interval? string 154 | +--rw operation? operation 155 | +--rw data-value? 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? 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 190 191 11 192 2016-09-12T23:20:50.52Z 193 P1D 194 R5/P1W 195 configure 196 197 198 link-1 199 true 200 201 202 203 204 205 206 /ex:te-links 207 208 209 12 210 exclusive 211 2016-09-15T01:00:00.00Z 212 P2H 213 configure 214 215 216 link-2 217 true 218 219 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 238 239 11 240 2016-09-12T23:20:50.52Z 241 P1D 242 R5/P1W 243 set 244 true 245 246 247 248 249 /ex:te-links/ex:te-link[ex:link-id='link-2']/ex:enabled 250 251 252 253 12 254 exclusive 255 2016-09-15T01:00:00.00Z 256 P2H 257 set 258 true 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@2018-02-26.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 2018-02-26 { 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 leaf operation { 454 type operation; 455 default "configure"; 456 description 457 "Operation type."; 458 } 459 anydata data-value { 460 description 461 "The data value applied to the leaf data node 462 specified by data-objects. 463 The format of the data value depends on the value of the 464 leaf operation defined above: 465 configure: data-value is the sub-tree added to the 466 target object; 467 deconfigure: data-value is the child to be deleted from 468 the target object; 469 set: the target object MULST be a leaf, and 470 data-value is the new value to be set to 471 the target object; 472 reset: data-value is ignored."; 473 } 474 } // schedule-config-attributes 476 grouping schedule-config-notification { 477 description 478 "A group of attributes for a schedule notification."; 480 notification execution { 481 description 482 "Notification event for an execution performed on a target 483 object."; 484 leaf operation { 485 type operation; 486 mandatory true; 487 description "Operation type."; 488 } 489 leaf datetime { 490 type yang:date-and-time; 491 description 492 "The date and time when the execution was performed."; 493 } 494 anydata results { 495 description 496 "This chunk of data contains the results of the execution 497 performed on the target object. The results are the same 498 or equivalent to the contents of a message, 499 Because of the nature of such a target execution, a 500 message is not used to return the execution 501 results. Instead, this notification is used to serve 502 the same purpose."; 503 } 504 } 505 } // schedule-config-notification 507 grouping schedule-state-attributes { 508 description 509 "State attributes for a schedule."; 510 container future-executions { 511 description 512 "The state information of the nexte scheduled event."; 513 list execution { 514 key "start"; 515 description 516 "List of scheduled future executions."; 517 leaf start { 518 type yang:date-and-time; 519 description "Start time."; 520 } 521 leaf duration { 522 type string { 523 pattern 524 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?'; 525 } 526 description "Schedule duration in ISO 8601 format."; 527 } 528 leaf operation { 529 type operation; 530 description "Operation type."; 531 } 532 } // event 533 } // future-events 534 } // schedule-state-attributes 536 grouping schedules { 537 description 538 "A list of schedules defining when a particular 539 configuration takes effect."; 540 container schedules { 541 description 542 "Container of a schedule list defining when a particular 543 configuration takes effect."; 544 list schedule { 545 key "schedule-id"; 546 description "A list of schedule elements."; 547 leaf schedule-id { 548 type uint32; 549 description "Identifies the schedule element."; 550 } 551 uses schedule-config-attributes; 552 } 553 } 554 } // schedules 556 /* 557 * Configuration data and operational state nodes 558 */ 559 container configuration-schedules { 560 description 561 "Serves as top-level container for a list of configuration 562 schedules."; 563 list target { 564 key "object"; 565 description 566 "A list of targets that configuration schedules are 567 applied."; 568 leaf object { 569 type yang:xpath1.0; 570 description 571 "Xpath defining the data items of interest."; 572 } 573 uses schedules; 574 container state { 575 config false; 576 description 577 "Operational state data."; 578 uses schedule-state-attributes; 579 } // state 581 uses schedule-config-notification; 582 } // target 583 } // configuration-schedules 584 } 585 587 8. IANA Considerations 589 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 590 actual RFC number (and remove this note). 592 This document registers the following namespace URI in the IETF XML 593 registry [RFC3688]: 595 -------------------------------------------------------------------- 596 URI: urn:ietf:params:xml:ns:yang:ietf-schedule 597 Registrant Contact: The IESG. 598 XML: N/A, the requested URI is an XML namespace. 599 -------------------------------------------------------------------- 601 This document registers the following YANG module in the YANG Module 602 Names registry [RFC6020]: 604 -------------------------------------------------------------------- 605 name: ietf-schedule 606 namespace: urn:ietf:params:xml:ns:yang:ietf-schedule 607 prefix: l3te 608 reference: RFC XXXX 609 -------------------------------------------------------------------- 611 9. Security Considerations 613 The configuration, state, action and notification data defined in 614 this document are designed to be accessed via the NETCONF protocol 615 [RFC6241]. The lowest NETCONF layer is the secure transport layer, 616 and the mandatory-to-implement secure transport is Secure Shell (SSH) 617 [RFC6242]. The NETCONF access control model [RFC6536] provides the 618 means to restrict access for particular NETCONF users to a pre- 619 configured subset of all available NETCONF protocol operations and 620 contents. 622 The functionality defined in this memo can potentially allow network 623 reconnaissance; by gathering information about schedules an attacker 624 can learn about the network policy, its temporal behavior, and future 625 events. 627 The schedule YANG model defines schedules that are writable, 628 creatable, and deletable. Therefore, this model may be considered 629 sensitive or vulnerable in some network environments. An attacker 630 may maliciously configure a schedule in a way that disrupts the 631 normal behavior of the network. Furthermore, an attacker may attempt 632 to maliciously set a schedule or a set of schedules in a way that 633 amplifies an attack, or schedules an attack to a particularly 634 sensitive time instant. 636 The use of configuration scheduling implicitly assumes that there is 637 an underlying synchronization or time distribution mechanism. 638 Therefore, an attack on the synchronization mechanism may compromise 639 the configuration scheduling. The security considerations of time 640 protocols are discussed further in [RFC7384]. 642 10. Contributors 644 Tal Mizrahi 646 Email: talmi@marvell.com 648 11. References 650 11.1. Normative References 652 [IEEE1588] 653 IEEE, "IEEE Standard for a Precision Clock Synchronization 654 Protocol for Networked Measurement and Control Systems 655 Version 2", IEEE Standard 1588. 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, . 662 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 663 "Network Time Protocol Version 4: Protocol and Algorithms 664 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 665 . 667 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 668 the Network Configuration Protocol (NETCONF)", RFC 6020, 669 DOI 10.17487/RFC6020, October 2010, . 672 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 673 RFC 6021, DOI 10.17487/RFC6021, October 2010, 674 . 676 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 677 and A. Bierman, Ed., "Network Configuration Protocol 678 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 679 . 681 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 682 RFC 7950, DOI 10.17487/RFC7950, August 2016, 683 . 685 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 686 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 687 October 2014, . 689 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 690 Computation Element Architecture", RFC 7399, 691 DOI 10.17487/RFC7399, October 2014, . 694 [RFC7758] Mizrahi, T. and Y. Moses, "Time Capability in NETCONF", 695 RFC 7758, DOI 10.17487/RFC7758, February 2016, 696 . 698 [I-D.birrane-dtn-ama] 699 Birrane, E., "Asynchronous Management Architecture", 700 draft-birrane-dtn-ama-06 (work in progress), October 2017. 702 [I-D.ietf-netconf-subscribed-notifications] 703 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 704 A. Tripathy, "Custom Subscription to Event Streams", 705 draft-ietf-netconf-subscribed-notifications-09 (work in 706 progress), January 2018. 708 [I-D.ietf-netconf-yang-push] 709 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 710 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 711 Subscription", draft-ietf-netconf-yang-push-14 (work in 712 progress), February 2018. 714 11.2. Informative References 716 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 717 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 718 January 2011, . 720 Authors' Addresses 722 Xufeng Liu 723 Jabil 724 8281 Greensboro Drive, Suite 200 725 McLean VA 22102 726 USA 728 EMail: Xufeng_Liu@jabil.com 730 Igor Bryskin 731 Huawei Technologies 733 EMail: Igor.Bryskin@huawei.com 735 Vishnu Pavan Beeram 736 Juniper Networks 738 EMail: vbeeram@juniper.net 740 Tarek Saad 741 Cisco Systems Inc 743 EMail: tsaad@cisco.com 744 Himanshu Shah 745 Ciena 747 EMail: hshah@ciena.com 749 Oscar Gonzalez de Dios 750 Telefonica 752 EMail: oscar.gonzalezdedios@telefonica.com