idnits 2.17.1 draft-wu-netmod-base-notification-nmda-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([RFC8342]), 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 248 has weird spacing: '...sist-id strin...' == Line 253 has weird spacing: '...sist-id strin...' -- The document date (September 14, 2018) is 2052 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: 'RFC8040' is mentioned on line 74, but not defined == Missing Reference: 'NMDA-DIFF' is mentioned on line 180, but not defined == Missing Reference: 'RFC8174' is mentioned on line 107, but not defined == Missing Reference: 'RFC8340' is mentioned on line 240, but not defined == Missing Reference: 'RFC7950' is mentioned on line 620, but not defined == Unused Reference: 'I-D.clemm-netmod-nmda-diff' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'RFC8072' is defined on line 677, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group Q. Wu 3 Internet-Draft R. Ranade 4 Intended status: Standards Track Huawei 5 Expires: March 18, 2019 September 14, 2018 7 NMDA Base Notification for Applied Intended Configuration 8 draft-wu-netmod-base-notification-nmda-00 10 Abstract 12 The Network Configuration Protocol (NETCONF)and RESTCONF provides 13 mechanisms to manipulate configuration datastores. NMDA introduces 14 additional datastores for systems that support more advanced 15 processing chains converting configuration to operational state. 16 However, client applications are not able to be aware of common 17 events in these additional datstores of the management system, such 18 as a applied configuration state change in NETCONF server or RESTCONF 19 server, that may impact management applications. This document 20 define a YANG module that allows a client to receive additional 21 notifications for some common system events pertaining to the Network 22 Management Datastore Architecture (NMDA) defined in [RFC8342]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 18, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. NMDA Base Notifications for applied intended configuration . 3 61 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Data Model Design . . . . . . . . . . . . . . . . . . . . 5 63 2.3. Relation with NMDA Datastore Compare . . . . . . . . . . 7 64 2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 68 6. Normative References . . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 The Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 74 [RFC8040] provides mechanisms to manipulate configuration datastores. 75 NMDA introduces additional datastores (e.g., , 76 ) for systems that support more advanced processing 77 chains converting configuration to operational state. However, 78 client applications are not able to be aware of common events in 79 these additional datastores of the management system, e.g., there are 80 many background activities (e.g.,NMDA datastore consistency checking 81 [NMDA-DIFF]) that happen during the time that configuration is 82 committed to to the time that the configuration is actually 83 applied to . It is possible that some configuration 84 could not be applied to due to either validation 85 issues, or missing resource etc. There is a need for user to know 86 the applying result of data-store and the reason why the 87 configuration were not applied. 89 This document define a YANG module that allows a NMS client to 90 receive additional notifications for some common system events 91 pertaining to the Network Management Datastore Architecture (NMDA) 92 defined in [RFC8342]. These notifications are designed to support 93 the monitoring of the base system events within the server and not 94 specific to any network management protocols such as NETCONF and 95 RESTCONF. 97 The solution presented in this document is backwards compatible with 98 [RFC6470]. 100 1.1. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 The following terms are defined in [RFC8342] and are not redefined 109 here: 111 o operational state datastore 113 o running configuration datastore 115 o intended configuration datastore 117 2. NMDA Base Notifications for applied intended configuration 119 2.1. Overview 121 The YANG module in NETCONF Base Notifications [RFC6470] specifies the 122 following 5 event notifications for the 'NETCONF' stream to notify a 123 client application that the NETCONF server state has changed: 125 o netconf-config-change 127 o netconf-capability-change 129 o netconf-session-start 131 o netconf-session-end 133 o netconf-confirmed-commit 135 These event notifications used within the 'NETCONF' stream are 136 accessible to clients via the subscription mechanism described in 137 [RFC5277]. 139 This document introduces NMDA specific extension which allows a 140 client to receive 3 notifications for additional common system events 141 as follows: 143 intended-apply-start: Generated when a server with network 144 management protocol support detects that configuration applied 145 from intended has started. The applied-intended-start starts at 146 the time when configuration is succesfully committed to , 147 i.e., the confirmed-commit procedure has been completed.A server 148 MAY optionally generate this event for both NETCONF session and 149 non-NETCONF management sessions. In case two commits are 150 detected, if the second commit is confirmed commit, the commit and 151 confirmed commit should be treated as the same commit, i.e., 152 intended-apply-start commit should not be sent for persistent 153 confirmed commit. if the the second commit is not confirmed 154 commit, intended-apply-start for the second commit should not be 155 sent until intended-apply-end or nmda-intended-applied for the 156 first commit has been sent. 158 intended-apply-end: Generated when a server with network management 159 protocol support detects that all or a set of configurations are 160 successfully applied or none of them are applied. Note that 161 configuration applying process of the learned configuration, 162 system-provided configuration, and default values defined by data 163 models is not relevant to the events defined in this document. 164 Unlike the learned configuration, system-provided configuration, 165 the intended configuration is not applied frequently and may be 166 fixed after the configuration applying process. A server MAY 167 optionally generate this event for both NETCONF session and non- 168 NETCONF management sessions. 170 nmda-intended-applied: Generated when a server with network 171 management protocol support detects that all or a set of 172 configurations are successfully applied or none of them are 173 applied. Occurs at the same as intended-apply-end and Indicates 174 the event and the current state of the intended configuration 175 applying. If the applied-event of the mmda-intended-applied is 176 set to start or compete, the nmda-intended-applied can also used 177 to indicate the start time and end time of the intended 178 configuration applying procedure, i.e., intended-apply-start and 179 intended-apply-end are not needed being sent to the client. In 180 addition, NMDA datastore compare [NMDA-DIFF] should be used to 181 check which part of intended configuration data is applied or 182 which part of intended configuration data is not applied. A 183 server MAY report events for non- NETCONF management sessions 184 (such as RESTCONF,gPRC), using the 'session-id' value of zero. 186 Editor-Note: If nmda-intended-applied can be used to indicate 187 start time and end time of the intended configuration applying 188 procedure, do we need intended-apply-start and intended-apply-end 189 events? 191 The following figure shows event notification sequence defined in 192 this document. 194 +-------------+ +-----------+ 195 | | | | 196 | (ct, rw) |<---+ +--->| (ct, rw) | 197 +-------------+ | | +-----------+ 198 | | | | 199 | +-----------+ | 200 +-------->| |<--------+ 201 | (ct, rw) | 202 +-----------+ 203 | 204 (a)intended-apply-start | // configuration transformations, 205 | // e.g., removal of nodes marked as 206 | // "inactive", expansion of 207 | // templates 208 v 209 +------------+ 210 | | // subject to validation 211 | (ct, ro) | 212 +------------+ 213 | // changes applied, subject to 214 (b)intended-apply-end | // local factors, e.g., missing 215 nmda-intended-applied | // resources, delays 216 | 217 dynamic | +-------- learned configuration 218 configuration | +-------- system configuration 219 datastores -----+ | +-------- default configuration 220 | | | 221 v v v 222 +---------------+ 223 | | <-- system state 224 | (ct + cf, ro) | 225 +---------------+ 227 ct = config true; cf = config false 228 rw = read-write; ro = read-only 229 boxes denote named datastores 231 These notification messages are accessible to clients via either the 232 subscription mechanism described in [RFC5277] or dynamic subscription 233 mechanism and configured subscription mechanism described in [I- 234 D.ietf-netconf-netconf-event-notifications]. 236 2.2. Data Model Design 238 The data model is defined in the ietf-nmda-notifications YANG module. 239 Its structure is shown in the following figure. The notation syntax 240 follows [RFC8340]. 242 module: ietf-nmda-notifications 243 notifications: 244 +---n intended-apply-start 245 | +--ro username string 246 | +--ro session-id session-id-or-zero-type 247 | +--ro source-host? inet:ip-address 248 | +--ro commit-persist-id string 249 +---n intended-apply-end 250 | +--ro username string 251 | +--ro session-id session-id-or-zero-type 252 | +--ro source-host? inet:ip-address 253 | +--ro commit-persist-id string 254 | +--ro (complete-status)? 255 | +--:(global-errors) 256 | | +--ro errors 257 | | +--ro error* 258 | | +--ro error-type enumeration 259 | | +--ro error-tag string 260 | | +--ro error-app-tag? string 261 | | +--ro error-path? instance-identifier 262 | | +--ro error-message? string 263 | | +--ro error-info? 264 | +--:(ok) 265 | +--ro ok? empty 266 +---n nmda-intended-applied 267 +--ro username string 268 +--ro session-id session-id-or-zero-type 269 +--ro source-host? inet:ip-address 270 | +--ro commit-persist-id string 271 +--ro applied-event enumeration 272 +--ro (applied-status)? 273 | +--:(global-errors) 274 | | +--ro errors 275 | | +--ro error* 276 | | +--ro error-type enumeration 277 | | +--ro error-tag string 278 | | +--ro error-app-tag? string 279 | | +--ro error-path? instance-identifier 280 | | +--ro error-message? string 281 | | +--ro error-info? 282 | +--:(ok) 283 | +--ro ok? empty 284 +--ro fail-applied-target* 285 +--ro datastore? identityref 286 +--ro edit-id? string 287 +--ro target? ypatch:target-resource-offset 288 +--ro (applied-status-choice)? 289 +--:(errors) 290 +--ro errors 291 +--ro error* 292 +--ro error-type enumeration 293 +--ro error-tag string 294 +--ro error-app-tag? string 295 +--ro error-path? instance-identifier 296 +--ro error-message? string 297 +--ro error-info? 299 The following are examples of a nmda-intended-applied notification 300 message: 302 303 2017-06-16T16:30:59.137045+09:00 304 305 admin 306 0 307 10.251.93.83 308 IQ,d4668 309 complete 310 311 protocol 312 mis-resource 313 \ 314 \/if:interfaces-state\ 315 \ 316 refer to resources that are not \ 317 \available or otherwise not physically present.\ 318 \ 319 320 321 intended 322 1 323 /ietf-interfaces:interfaces-state 324 325 326 intended 327 1 328 /ietf-system:system 329 330 331 333 2.3. Relation with NMDA Datastore Compare 335 NMDA datastore compare [NMDA-DIFF]could be used to check which part 336 of intended configuration data is applied or which part of intended 337 configuration data is not applied. On the other hand, the event 338 notification for applied-intended-start can be used to trigger NMDA 339 datastore compare procedure to be started. 341 2.4. Definitions 343 This section presents the YANG module defined in this document. This 344 module imports data types from the 'ietf-datastores' module defined 345 in [RFC8342] and 'ietf-inet-types' module defined in [RFC6021]. 347 file "ietf-nmda-notifications@2018-04-01.yang" 348 module ietf-nmda-notifications { 349 namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-notifications"; 350 prefix ndn; 351 import ietf-datastores { 352 prefix ds; 353 } 354 import ietf-inet-types { prefix inet; } 355 import ietf-yang-patch { 356 prefix ypatch; 357 } 358 import ietf-restconf { prefix rc;} 359 organization 360 "IETF NETMOD (Network Modeling) Working Group"; 361 contact 362 "WG Web: 363 WG List: 364 WG Chair: Kent Watsen 365 366 Editor: Qin Wu 367 368 Editor: Rohit R Ranade 369 "; 370 description 371 "This module defines a YANG data model for use with the 372 NETCONF and RESTCONF protocol that allows the client to 373 receive additional common event notifications related to NMDA. 374 Copyright (c) 2012 IETF Trust and the persons identified as 375 the document authors. All rights reserved. 376 Redistribution and use in source and binary forms, with or 377 without modification, is permitted pursuant to, and subject 378 to the license terms contained in, the Simplified BSD License 379 set forth in Section 4.c of the IETF Trust's Legal Provisions 380 Relating to IETF Documents 381 (http://trustee.ietf.org/license-info). 382 This version of this YANG module is part of RFC xxxx; see 383 the RFC itself for full legal notices."; 385 revision 2018-04-01 { 386 description 387 "Initial version."; 388 reference "RFC xxx: NETCONF Base Notifications for NMDA"; 389 } 390 typedef session-id-or-zero-type { 391 type uint32; 392 description 393 "NETCONF Session Id or Zero to indicate none"; 394 } 396 grouping common-session-parms { 397 description 398 "Common session parameters to identify a 399 management session."; 401 leaf username { 402 type string; 403 mandatory true; 404 description 405 "Name of the user for the session."; 406 } 408 leaf session-id { 409 type session-id-or-zero-type; 410 mandatory true; 411 description 412 "Identifier of the session. 413 A NETCONF session MUST be identified by a non-zero value. 414 A non-NETCONF session MAY be identified by the value zero."; 415 } 417 leaf source-host { 418 type inet:ip-address; 419 description 420 "Address of the remote host for the session."; 421 } 423 leaf commit-persist-id { 424 type string; 425 description 426 "This parameter is used to identify each commit. 427 The value of this parameter is a token that must be given 428 in the 'persist-id' parameter of or 429 operations in order to confirm or cancel 430 the persistent confirmed commit. 432 The token should be a random string."; 433 reference "RFC 6241, Section 8.3.4.1"; 435 } 436 } 438 notification intended-apply-start { 439 description 440 " Generated when a server detects that applied configuration from 441 intended has started. This event will be sent immediately upon 442 any data is written to . A server MAY generate this 443 event for both NETCONF session and non-NETCONF management 444 sessions."; 445 uses common-session-parms; 446 } // notification applied-intended-start 448 notification intended-apply-end { 449 description 450 " Generated when a server detects that a applied configuration 451 from intended has complete. A server MAY optionally generate 452 this event for both NETCONF session and non-NETCONF management 453 sessions."; 454 uses common-session-parms; 455 choice complete-status { 456 description 457 "Report global errors or complete success. 458 If there is no case selected, then errors 459 are reported in the 'edit-status' container."; 460 case global-errors { 461 uses rc:errors; 462 description 463 "This container will be present if global errors that 464 are unrelated to a specific edit occurred."; 465 } 466 leaf ok { 467 type empty; 468 description 469 "This leaf will be present if the request succeeded 470 and there are no errors reported in the 'edit-status' 471 container."; 472 } 473 } 474 } // notification applied-intended-complete 476 notification nmda-intended-applied { 477 description 478 "Generated when a server detects that a 479 intended configuration applied event has occurred. Indicates 480 the event and the current state of the intended data applying 481 procedure in progress."; 482 reference "RFC 8342, Section 5"; 483 uses common-session-parms; 484 leaf applied-event { 485 type enumeration { 486 enum "start" { 487 description 488 "The intended data applying procedure has started."; 489 } 490 enum "transform" { 491 description 492 " MAY be updated independently of 493 due to configuration transformation."; 494 } 495 enum "synchronizing" { 496 description 497 "The data validation results within is in 498 progress of synchronizing to ."; 499 } 500 enum "complete" { 501 description 502 "The intended data applying procedure has been 503 completed."; 504 } 505 } 506 mandatory true; 507 description 508 "Indicates the event that caused the notification."; 509 } 510 choice applied-status { 511 when "./applied-event = 'complete'"; 512 description 513 "Report global errors or complete success. 514 If there is no case selected, then errors 515 are reported in the 'edit-status' container."; 516 case global-errors { 517 uses rc:errors; 518 description 519 "This container will be present if global errors that 520 are unrelated to a specific edit occurred."; 521 } 522 leaf ok { 523 type empty; 524 description 525 "This leaf will be present if the request succeeded 526 and there are no errors reported in the 'edit-status' 527 container."; 528 } 529 } 531 list fail-applied-target { 532 leaf datastore { 533 type identityref { 534 base ds:datastore; 535 } 536 default "ds:operational"; 537 description 538 "Indicates which datastore has changed or which datastore is 539 target of edit-data operation."; 540 } 541 leaf edit-id { 542 type string; 543 description 544 "Response status is for the 'edit' list entry 545 with this 'edit-id' value."; 546 } 547 leaf target { 548 type ypatch:target-resource-offset; 549 description 550 "Topmost node associated with the configuration change. 551 A server SHOULD set this object to the node within 552 the datastore that is being altered. A server MAY 553 set this object to one of the ancestors of the actual 554 node that was changed, or omit this object, if the 555 exact node is not known."; 556 } 557 choice applied-status-choice { 558 description 559 "A choice between different types of status 560 responses for each 'edit' entry."; 561 case errors { 562 uses rc:errors; 563 description 564 "The server detected errors associated with the 565 edit identified by the same 'edit-id' value."; 566 } 567 } 568 description 569 "List for fail applied targets"; 570 } 571 } 572 } 574 575 3. Security Considerations 577 The YANG module defined in this memo is designed to be accessed via 578 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 579 secure transport layer and the mandatory-to-implement secure 580 transport is SSH, defined in [RFC6242]. 582 Some of the readable data nodes in this YANG module may be considered 583 sensitive or vulnerable in some network environments. It is thus 584 important to control read access (e.g., via get, get-config, or 585 notification) to these data nodes. These are the subtrees and data 586 nodes and their sensitivity/vulnerability: 588 /applied-intended-start: 590 Event type itself indicates that a server may start applying 591 configuration from intended. It may be possible for an attacker 592 to slow down intended validation or update intended independently 593 of running by somehow taking advantage of configuration template 594 transformation. 596 /applied-intended-complete: 598 Event type itself indicates that a server may be finished applying 599 configuration from intended. This event could alert an attacker 600 that a datastore may have been altered. 602 /nmda-data-applied/applied-event: 604 Indicates the specific applied intended applied event state change 605 that occurred. A value of 'complete' probably indicates that 606 intended data applying procedure has completed. 608 4. IANA Considerations 610 This document registers one XML namespace URN in the 'IETF XML 611 registry', following the format defined in [RFC3688]: 613 URI: urn:ietf:params:xml:ns:yang:ietf-nmda-notifications 615 Registrant Contact: The IESG. 617 XML: N/A, the requested URI is an XML namespace. 619 This document registers one module name in the 'YANG Module Names' 620 registry, defined in [RFC7950]: 622 name: ietf-nmda-notifications 623 prefix: ndn 625 namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-notifications 627 RFC: xxxx 629 5. Acknowledgements 631 Thanks to Juergen Schoenwaelder, Alex Clemm,Carey Timothy and Andy 632 Berman to review this draft and Thank Xiaojian Ding provide important 633 input to the initial version of this document. 635 6. Normative References 637 [I-D.clemm-netmod-nmda-diff] 638 Clemm, A., Qu, Y., Tantsura, J., and A. Bierman, 639 "Comparison of NMDA datastores", draft-clemm-netmod-nmda- 640 diff-00 (work in progress), June 2018. 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 648 DOI 10.17487/RFC3688, January 2004, 649 . 651 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 652 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 653 . 655 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 656 the Network Configuration Protocol (NETCONF)", RFC 6020, 657 DOI 10.17487/RFC6020, October 2010, 658 . 660 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 661 RFC 6021, DOI 10.17487/RFC6021, October 2010, 662 . 664 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 665 and A. Bierman, Ed., "Network Configuration Protocol 666 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 667 . 669 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 670 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 671 . 673 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 674 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 675 February 2012, . 677 [RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 678 Media Type", RFC 8072, DOI 10.17487/RFC8072, February 679 2017, . 681 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 682 and R. Wilton, "Network Management Datastore Architecture 683 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 684 . 686 Authors' Addresses 688 Qin Wu 689 Huawei 690 101 Software Avenue, Yuhua District 691 Nanjing, Jiangsu 210012 692 China 694 Email: bill.wu@huawei.com 696 Rohit R Ranade 697 Huawei 698 Divyashree Techno Park, Whitefield 699 Bangalore, Karnataka 560066 700 India 702 Email: rohitrranade@huawei.com