idnits 2.17.1 draft-zheng-mpls-lsp-ping-yang-cfg-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([6241], [RFC6020]), 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2734 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) -- Looks like a reference, but probably isn't: '6241' on line 24 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) -- Obsolete informational reference (is this intentional?): RFC 6829 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Zheng 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track S. Aldrin 5 Expires: May 4, 2017 Google 6 G. Zheng 7 Huawei Technologies 8 G. Mirsky 9 Ericsson 10 R. Rahman 11 Cisco Systems 12 October 31, 2016 14 Yang Data Model for LSP-PING 15 draft-zheng-mpls-lsp-ping-yang-cfg-04 17 Abstract 19 When an LSP fails to deliver user traffic, the failure cannot always 20 be detected by the MPLS control plane. RFC4379 defines a mechanism 21 that would enable users to detect such failure and to isolate faults. 22 YANG [RFC6020] is a data definition language that was introduced to 23 define the contents of a conceptual data store that allows networked 24 devices to be managed using NETCONF RFC[6241]. This document defines 25 a YANG data model that can be used to configure and manage LSP-Ping. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 4, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Support of Long Running Command with NETCONF . . . . . . 3 69 1.2. Contributors . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 72 3.1. Configuration of Control Information . . . . . . . . . . 4 73 3.2. Configuration of Schedule Parameters . . . . . . . . . . 5 74 3.3. Display of Result Information . . . . . . . . . . . . . . 6 75 4. Data Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 7 76 5. Interaction with other MPLS OAM Tools Models . . . . . . . . 10 77 6. LSP-Ping Yang Module . . . . . . . . . . . . . . . . . . . . 10 78 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 7.1. Configuration of Control Information . . . . . . . . . . 20 80 7.2. Configuration of Schedule Parameters . . . . . . . . . . 21 81 7.3. Display of Result Information . . . . . . . . . . . . . . 22 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 87 11.2. Informative References . . . . . . . . . . . . . . . . . 25 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 90 1. Introduction 92 When an LSP fails to deliver user traffic, the failure cannot always 93 be detected by the MPLS control plane. [RFC4379] defines a mechanism 94 that would enable users to detect such failure and to isolate faults. 95 YANG [RFC6020] is a data definition language that was introduced to 96 define the contents of a conceptual data store that allows networked 97 devices to be managed using NETCONF [RFC6241]. This document defines 98 a YANG data model that can be used to configure and manage LSP-Ping 99 [RFC4379]. 101 The rest of this document is organized as follows. Section 2 102 presents the scope of this document. Section 3 provides the design 103 of the LSP-Ping configuration data model in details by containers. 104 Section 4 presents the complete data hierarchy of LSP-Ping YANG 105 model. Section 5 discusses the interaction between LSP-Ping data 106 model and other MPLS tools data models. Section 6 specifies the YANG 107 module and section 7 lists examples which conform to the YANG module 108 specified in this document. Finally, security considerations are 109 discussed in Section 8. 111 1.1. Support of Long Running Command with NETCONF 113 LSP Ping is one of examples of what can described as "long-running 114 operation". Unlike most of configuration operations that result in 115 single response execution of an LSP Ping triggers multiple responses 116 from a node under control. The question of implementing long-running 117 operation in NETCONF is still open and possible solutions being 118 discussed: 120 1. Consecutive Remote Processing Calls (RPC) to poll for results; 122 2. Model presented in[RFC4560] ; 124 3. The one outlined in [I-D.mahesh-netconf-persistent]. 126 The problem of long-running operation as well can be considered as a 127 case of controlling and obtaining results from a Measurement Agent 128 (MA) as defined in [I-D.ietf-lmap-framework]. 130 1.2. Contributors 132 Yanfeng Zhang (Huawei Technologies) contributed to the definition of 133 the YANG module in Section 6. 135 2. Scope 137 The fundamental mechanism of LSP-Ping is defined in [RFC4379]. The 138 on-going work of [I-D.ietf-mpls-rfc4379bis] is to take LSP Ping to an 139 Internet Standard, updates from [RFC5462] and [RFC6829] have been 140 incorporated. These updates of LSP-Ping has been considered in this 141 document. Extensions of LSP-Ping has been developed over the years. 142 There are for example extensions for performing LSP ping over P2MP 143 MPLS LSPs [RFC6425] and trace-route over MPLS tunnels [RFC6424] etc. 144 These extensions will be considered in update of this document. 146 3. Design of the Data Model 148 This YANG data model is defined to be used to configure and manage 149 LSP-Ping and it provides the following features: 151 1. Configuration of control information of a LSP-Ping test; 153 2. Configuration of schedule parameters of a LSP-Ping test; 155 3. Display of result information of a LSP-Ping test. 157 The top level container lsp-pings holds the configuration of control 158 information, schedule parameters and result information for multi 159 instances of LSP-Ping test. 161 3.1. Configuration of Control Information 163 Container lsp-pings:lsp-ping:control-info defines the configuration 164 parameters which control a LSP-Ping test. Examples are the target- 165 fec-type/target-fec of the echo request packet and the reply mode of 166 the echo reply packet. Values of some parameters may be auto- 167 assigned by the system, but in several cases there is a requirement 168 for configuration of these parameters. Examples of such parameters 169 are source address and outgoing interface. 171 The data hierarchy for control information configuration is presented 172 below: 174 module: ietf-lspping 175 +--rw lsp-pings 176 +--rw lsp-ping* [lsp-ping-name] 177 +--rw lsp-ping-name string 178 +--rw control-info 179 | +--rw target-fec-type? target-fec-type 180 | +--rw (target-fec)? 181 | | +--:(ip-prefix) 182 | | | +--rw ip-address? inet:ip-address 183 | | +--:(bgp) 184 | | | +--rw bgp? inet:ip-address 185 | | +--:(rsvp) 186 | | | +--rw tunnel-interface? uint32 187 | | +--:(vpn) 188 | | | +--rw vrf-name? uint32 189 | | | +--rw vpn-ip-address? inet:ip-address 190 | | +--:(pw) 191 | | | +--rw vcid? uint32 192 | | +--:(vpls) 193 | | +--rw vsi-name? string 194 | +--rw traffic-class? uint8 195 | +--rw reply-mode? reply-mode 196 | +--rw timeout? uint32 197 | +--rw timeout-units? units 198 | +--rw interval? uint32 199 | +--rw interval-units? units 200 | +--rw probe-count? uint32 201 | +--rw data-size? uint32 202 | +--rw data-fill? string 203 | +--rw description? string 204 | +--rw source-address-type? inet:ip-version 205 | +--rw source-address? inet:ip-address 206 | +--rw ttl? uint32 207 | +--rw (outbound)? 208 | +--:(interface) 209 | | +--rw interface-name? string 210 | +--:(nexthop) 211 | +--rw nexthop? inet:ip-address 213 3.2. Configuration of Schedule Parameters 215 Container lsp-pings:lsp-ping:schedule-parameters defines the schedule 216 parameters of a LSP-Ping test, which basically describes when to 217 start and when to end the test. Four start modes and three end modes 218 are defined respectively. To be noted that, the configuration of 219 "interval" and "probe-count" parameter defined in container lsp- 220 pings:lsp-ping:control-info could also determine when the test ends 221 implicitly. All these three parameters are optional. If "interval" 222 and "probe-count" are not configured by the user, the default values 223 will be used by the system. If "end-test" is configured by the user, 224 the actual end time of the LSP-Ping test is the smaller one between 225 the configuration value of "end-test" and the time implicitly 226 determined by the configuration value of "interval"/"probe-count". 228 The data hierarchy for schedule information configuration is 229 presented below: 231 module: ietf-lspping 232 +--rw lsp-pings 233 +--rw lsp-ping* [lsp-ping-name] 234 +--rw lsp-ping-name string 235 +--rw control-info 236 ... 237 +--rw schedule-parameters 238 | +--rw (start-test)? 239 | | +--:(now) 240 | | | +--rw start-test-now? empty 241 | | +--:(at) 242 | | | +--rw start-test-at? yang:date-and-time 243 | | +--:(delay) 244 | | | +--rw start-test-delay? uint32 245 | | | +--rw start-test-delay-units? units 246 | | +--:(daily) 247 | | +--rw start-test-daily? yang:date-and-time 248 | +--rw (end-test)? 249 | +--:(at) 250 | | +--rw end-test-at? yang:date-and-time 251 | +--:(delay) 252 | | +--rw end-test-delay? uint32 253 | | +--rw end-test-delay-units? units 254 | +--:(lifetime) 255 | +--rw end-test-lifetime? uint32 256 | +--rw lifetime-units? units 258 3.3. Display of Result Information 260 Container lsp-pings:lsp-ping:result-info shows the result of the 261 current LSP-Ping test. Both the statistical result e.g. min-rtt, max 262 rtt, and per test probe result e.g. return code, return subcode, are 263 shown. 265 The data hierarchy for display of result information is presented 266 below: 268 module: ietf-lspping 269 +--rw lsp-pings 270 +--rw lsp-ping* [lsp-ping-name] 271 +--rw lsp-ping-name string 272 +--rw control-info 273 ... 274 +--rw schedule-parameters 275 ... 276 +--ro result-info 277 +--ro operational-status? operational-status 278 +--ro source-address-type? inet:ip-version 279 +--ro source-address? inet:ip-address 280 +--ro target-fec-type? target-fec-type 281 +--ro (target-fec)? 282 | +--:(ip-prefix) 283 | | +--ro ip-address? inet:ip-address 284 | +--:(bgp) 285 | | +--ro bgp? inet:ip-address 286 | +--:(rsvp) 287 | | +--ro tunnel-interface? uint32 288 | +--:(vpn) 289 | | +--ro vrf-name? uint32 290 | | +--ro vpn-ip-address? inet:ip-address 291 | +--:(pw) 292 | | +--ro vcid? uint32 293 | +--:(vpls) 294 | +--ro vsi-name? string 295 +--ro min-rtt? uint32 296 +--ro max-rtt? uint32 297 +--ro average-rtt? uint32 298 +--ro probe-responses? uint32 299 +--ro sent-probes? uint32 300 +--ro sum-of-squares? uint32 301 +--ro last-good-probe? yang:date-and-time 302 +--ro probe-results 303 +--ro probe-result* [probe-index] 304 +--ro probe-index uint32 305 +--ro return-code? uint8 306 +--ro return-sub-code? uint8 307 +--ro rtt? uint32 308 +--ro result-type? result-type 310 4. Data Hierarchy 312 The complete data hierarchy of LSP-Ping YANG model is presented 313 below. 315 module: ietf-lspping 316 +--rw lsp-pings 317 +--rw lsp-ping* [lsp-ping-name] 318 +--rw lsp-ping-name string 319 +--rw control-info 320 | +--rw target-fec-type? target-fec-type 321 | +--rw (target-fec)? 322 | | +--:(ip-prefix) 323 | | | +--rw ip-address? inet:ip-address 324 | | +--:(bgp) 325 | | | +--rw bgp? inet:ip-address 326 | | +--:(rsvp) 327 | | | +--rw tunnel-interface? uint32 328 | | +--:(vpn) 329 | | | +--rw vrf-name? uint32 330 | | | +--rw vpn-ip-address? inet:ip-address 331 | | +--:(pw) 332 | | | +--rw vcid? uint32 333 | | +--:(vpls) 334 | | +--rw vsi-name? string 335 | +--rw traffic-class? uint8 336 | +--rw reply-mode? reply-mode 337 | +--rw timeout? uint32 338 | +--rw timeout-units? units 339 | +--rw interval? uint32 340 | +--rw interval-units? units 341 | +--rw probe-count? uint32 342 | +--rw data-size? uint32 343 | +--rw data-fill? string 344 | +--rw description? string 345 | +--rw source-address-type? inet:ip-version 346 | +--rw source-address? inet:ip-address 347 | +--rw ttl? uint32 348 | +--rw (outbound)? 349 | +--:(interface) 350 | | +--rw interface-name? string 351 | +--:(nexthop) 352 | +--rw nexthop? inet:ip-address 353 +--rw schedule-parameters 354 | +--rw (start-test)? 355 | | +--:(now) 356 | | | +--rw start-test-now? empty 357 | | +--:(at) 358 | | | +--rw start-test-at? yang:date-and-time 359 | | +--:(delay) 360 | | | +--rw start-test-delay? uint32 361 | | | +--rw start-test-delay-units? units 362 | | +--:(daily) 363 | | +--rw start-test-daily? yang:date-and-time 364 | +--rw (end-test)? 365 | +--:(at) 366 | | +--rw end-test-at? yang:date-and-time 367 | +--:(delay) 368 | | +--rw end-test-delay? uint32 369 | | +--rw end-test-delay-units? units 370 | +--:(lifetime) 371 | +--rw end-test-lifetime? uint32 372 | +--rw lifetime-units? units 373 +--ro result-info 374 +--ro operational-status? operational-status 375 +--ro source-address-type? inet:ip-version 376 +--ro source-address? inet:ip-address 377 +--ro target-fec-type? target-fec-type 378 +--ro (target-fec)? 379 | +--:(ip-prefix) 380 | | +--ro ip-address? inet:ip-address 381 | +--:(bgp) 382 | | +--ro bgp? inet:ip-address 383 | +--:(rsvp) 384 | | +--ro tunnel-interface? uint32 385 | +--:(vpn) 386 | | +--ro vrf-name? uint32 387 | | +--ro vpn-ip-address? inet:ip-address 388 | +--:(pw) 389 | | +--ro vcid? uint32 390 | +--:(vpls) 391 | +--ro vsi-name? string 392 +--ro min-rtt? uint32 393 +--ro max-rtt? uint32 394 +--ro average-rtt? uint32 395 +--ro probe-responses? uint32 396 +--ro sent-probes? uint32 397 +--ro sum-of-squares? uint32 398 +--ro last-good-probe? yang:date-and-time 399 +--ro probe-results 400 +--ro probe-result* [probe-index] 401 +--ro probe-index uint32 402 +--ro return-code? uint8 403 +--ro return-sub-code? uint8 404 +--ro rtt? uint32 405 +--ro result-type? result-type 407 5. Interaction with other MPLS OAM Tools Models 409 TBA 411 6. LSP-Ping Yang Module 413 file "ietf-lspping@2015-07-02.yang" 414 module ietf-lspping { 415 namespace "urn:ietf:params:xml:ns:yang:ietf-lspping"; 416 //namespace need to be assigned by IANA 417 prefix "lspping"; 419 import ietf-inet-types { 420 prefix inet; 421 } 422 import ietf-yang-types{ 423 prefix yang; 424 } 426 organization "IETF Multiprotocl Label Switching Working Group"; 427 contact "draft-zheng-mpls-lsp-ping-yang-cfg"; 428 description "MPLS LSP-PING Yang Module"; 429 revision "2016-03-18" { 430 description "03 version, refine the target fec type, 431 as per RFC4379; updates per draft-ietf-mpls-rfc4379bis"; 432 reference "draft-zheng-mpls-lsp-ping-yang-cfg"; 433 } 435 typedef target-fec-type { 436 type enumeration { 437 enum ip-prefix { 438 value "0"; 439 description "IPv4/IPv6 prefix"; 440 } 441 enum bgp { 442 value "1"; 443 description "BGP IPv4/IPv6 prefix"; 444 } 445 enum rsvp { 446 value "2"; 447 description "Tunnel interface"; 448 } 449 enum vpn { 450 value "3"; 451 description "VPN IPv4/IPv6 prefix"; 452 } 453 enum pw { 454 value "4"; 455 description "FEC 128 pseudowire IPv4/IPv6"; 456 } 457 enum vpls { 458 value "5"; 459 description "FEC 129 pseudowire IPv4/IPv6"; 460 } 461 } 462 description "Target FEC type."; 463 } 465 typedef reply-mode { 466 type enumeration { 467 enum do-not-reply { 468 value "1"; 469 description "Do not reply"; 470 } 471 enum reply-via-udp { 472 value "2"; 473 description "Reply via an IPv4/IPv6 UDP packet"; 474 } 475 enum reply-via-udp-router-alert { 476 value "3"; 477 description "Reply via an IPv4/IPv6 UDP packet with 478 Router Alert"; 479 } 480 enum reply-via-control-channel { 481 value "4"; 482 description "Reply via application level control 483 channel"; 484 } 485 } 486 description "Reply mode."; 487 } 489 typedef units { 490 type enumeration { 491 enum seconds { 492 description "Seconds"; 493 } 494 enum milliseconds { 495 description "Milliseconds"; 496 } 497 enum microseconds { 498 description "Microseconds"; 499 } 500 enum nanoseconds { 501 description "Nanoseconds"; 502 } 504 } 505 description "Time units"; 506 } 508 typedef operational-status { 509 type enumeration { 510 enum enabled { 511 value "1"; 512 description "The Test is active."; 513 } 514 enum disabled { 515 value "2"; 516 description "The test has stopped."; 517 } 518 enum completed { 519 value "3"; 520 description "The test is completed."; 521 } 522 } 523 description "Operational state of a LSP Ping test."; 524 } 526 typedef result-type { 527 type enumeration { 528 enum success { 529 value "1"; 530 description "The test probe is successed."; 531 } 532 enum fail { 533 value "2"; 534 description "The test probe has failed."; 535 } 536 enum timeout { 537 value "3"; 538 description "The test probe is timeout."; 539 } 540 } 541 description "Result of each LSP Ping test probe."; 542 } 544 container lsp-pings { 545 description "Multi instance of LSP Ping test."; 546 list lsp-ping { 547 key "lsp-ping-name"; 548 description "LSP Ping test"; 549 leaf lsp-ping-name { 550 type string { 551 length "1..31"; 553 } 554 mandatory "true"; 555 description "LSP Ping test name."; 556 } 557 container control-info { 558 description "Control information of the LSP Ping test."; 559 leaf target-fec-type { 560 type target-fec-type; 561 description "Specifies the address type of Target FEC."; 562 } 563 choice target-fec { 564 case ip-prefix { 565 leaf ip-address { 566 type inet:ip-address; 567 description "IPv4/IPv6 Prefix."; 568 } 569 } 570 case bgp { 571 leaf bgp { 572 type inet:ip-address; 573 description "BGP IPv4/IPv6 Prefix."; 574 } 575 } 576 case rsvp { 577 leaf tunnel-interface { 578 type uint32; 579 description "Tunnel interface"; 580 } 581 } 582 case vpn { 583 leaf vrf-name { 584 type uint32; 585 description "Layer3 VPN Name."; 586 } 587 leaf vpn-ip-address { 588 type inet:ip-address; 589 description "Layer3 VPN IPv4 Prefix."; 590 } 591 } 592 case pw { 593 leaf vcid { 594 type uint32; 595 description "VC ID"; 596 } 597 } 598 case vpls { 599 leaf vsi-name { 600 type string; 601 description "VPLS VSI"; 602 } 603 } 604 description "Specifies the address of Target FEC"; 605 } 606 leaf traffic-class { 607 type uint8; 608 description "Specifies the Traffic Class."; 609 } 610 leaf reply-mode { 611 type reply-mode; 612 description "Specifies the reply mode."; 613 } 614 leaf timeout { 615 type uint32; 616 description "Specifies the time-out value for a 617 LSP Ping operation."; 618 } 619 leaf timeout-units { 620 type units; 621 description "Time-out units."; 622 } 623 leaf interval { 624 type uint32; 625 default 1; 626 description "Specifies the interval to send a LSP Ping 627 echo request packet(probe) as part of one LSP Ping test."; 628 } 629 leaf interval-units { 630 type units; 631 default seconds; 632 description "Interval units."; 633 } 634 leaf probe-count { 635 type uint32; 636 default 5; 637 description "Specifies the number of probe sent of one 638 LSP Ping test."; 639 } 640 leaf data-size { 641 type uint32; 642 description "Specifies the size of the data portion to 643 be transmitted in a LSP Ping operation, in octets."; 644 } 645 leaf data-fill { 646 type string{ 647 length "0..1564"; 648 } 649 description "Used together with the corresponding 650 data-size value to determine how to fill the data 651 portion of a probe packet."; 652 } 653 leaf description { 654 type string{ 655 length "1..31"; 656 } 657 description "A descriptive name of the LSP Ping test."; 658 } 659 leaf source-address-type { 660 type inet:ip-version; 661 description "Specifies the type of the source address."; 662 } 663 leaf source-address { 664 type inet:ip-address; 665 description "Specifies the source address."; 666 } 667 leaf ttl { 668 type uint32; 669 default 255; 670 description "Time to live."; 671 } 672 choice outbound { 673 case interface { 674 leaf interface-name{ 675 type string{ 676 length "1..255"; 677 } 678 description "Specifies the outgoing interface."; 679 } 680 } 681 case nexthop{ 682 leaf nexthop { 683 type inet:ip-address; 684 description "Specifies the nexthop."; 685 } 686 } 687 description "Specifies the out interface or nexthop"; 688 } 689 } 691 container schedule-parameters { 692 description "LSP Ping test schedule parameter"; 693 choice start-test{ 694 case now { 695 leaf start-test-now { 696 type empty; 697 description "Start test now."; 698 } 699 } 700 case at { 701 leaf start-test-at { 702 type yang:date-and-time; 703 description "Start test at a specific time."; 704 } 705 } 706 case delay { 707 leaf start-test-delay { 708 type uint32; 709 description "Start after a specific delay."; 710 } 711 leaf start-test-delay-units { 712 type units; 713 default seconds; 714 description "Delay units."; 715 } 716 } 717 case daily { 718 leaf start-test-daily { 719 type yang:date-and-time; 720 description "Start test daily."; 721 } 722 } 723 description "Specifies when the test begins to start, 724 include 4 schedule method: start now(1), start at(2), 725 start delay(3), start daily(4)."; 726 } 728 choice end-test{ 729 case at { 730 leaf end-test-at{ 731 type yang:date-and-time; 732 description "End test at a specific time."; 733 } 734 } 735 case delay { 736 leaf end-test-delay { 737 type uint32; 738 description "End after a specific delay."; 739 } 740 leaf end-test-delay-units { 741 type units; 742 default seconds; 743 description "Delay units."; 744 } 746 } 747 case lifetime { 748 leaf end-test-lifetime { 749 type uint32; 750 description "Set the test lifetime."; 751 } 752 leaf lifetime-units { 753 type units; 754 default seconds; 755 description "Lifetime units."; 756 } 757 } 758 description "Specifies when the test ends, include 3 759 schedule method: end at(1), end delay(2), 760 end lifetime(3)."; 761 } 762 } 764 container result-info { 765 config "false"; 766 description "LSP Ping test result information."; 767 leaf operational-status { 768 type operational-status; 769 description "Operational state of a LSP Ping test"; 770 } 771 leaf source-address-type { 772 type inet:ip-version; 773 description "The source address type."; 774 } 775 leaf source-address { 776 type inet:ip-address; 777 description "The source address of the test."; 778 } 779 leaf target-fec-type { 780 type target-fec-type; 781 description "The Target FEC address type."; 782 } 783 choice target-fec { 784 case ip-prefix { 785 leaf ip-address { 786 type inet:ip-address; 787 description "IPv4/IPv6 Prefix."; 788 } 789 } 790 case bgp { 791 leaf bgp { 792 type inet:ip-address; 793 description "BGP IPv4/IPv6 Prefix."; 795 } 796 } 797 case rsvp { 798 leaf tunnel-interface { 799 type uint32; 800 description "Tunnel interface"; 801 } 802 } 803 case vpn { 804 leaf vrf-name { 805 type uint32; 806 description "Layer3 VPN Name."; 807 } 808 leaf vpn-ip-address { 809 type inet:ip-address; 810 description "Layer3 VPN IPv4 Prefix."; 811 } 812 } 813 case pw { 814 leaf vcid { 815 type uint32; 816 description "VC ID"; 817 } 818 } 819 case vpls { 820 leaf vsi-name { 821 type string; 822 description "VPLS VSI"; 823 } 824 } 825 description "The Target FEC address"; 826 } 827 leaf min-rtt { 828 type uint32; 829 description "The minimum LSP Ping round-trip-time (RTT) 830 received."; 831 } 832 leaf max-rtt { 833 type uint32; 834 description "The maximum LSP Ping round-trip-time (RTT) 835 received."; 836 } 837 leaf average-rtt { 838 type uint32; 839 description "The current average LSP Ping round-trip-time 840 (RTT)."; 841 } 842 leaf probe-responses { 843 type uint32; 844 description "Number of responses received for the 845 corresponding LSP Ping test."; 846 } 847 leaf sent-probes { 848 type uint32; 849 description "Number of probes sent for the 850 corresponding LSP Ping test."; 851 } 852 leaf sum-of-squares { 853 type uint32; 854 description "The sum of the squares for all 855 replys received."; 856 } 857 leaf last-good-probe { 858 type yang:date-and-time; 859 description "Date and time when the last response 860 was received for a probe."; 861 } 863 container probe-results { 864 description "Result info of test probes."; 865 list probe-result { 866 key "probe-index"; 867 description "Result info of each test probe."; 868 leaf probe-index { 869 type uint32; 870 description "Probe index"; 871 } 872 leaf return-code { 873 type uint8; 874 description "The Return Code set in the echo reply."; 875 } 876 leaf return-sub-code { 877 type uint8; 878 description "The Return Sub-code set in the 879 echo reply."; 880 } 881 leaf rtt { 882 type uint32; 883 description "The round-trip-time (RTT) received."; 884 } 885 leaf result-type { 886 type result-type; 887 description "The probe result type."; 888 } 889 } 890 } 892 } 893 } 894 } 895 } 896 898 7. Examples 900 The following examples shows the netconf RPC communication between 901 client and server for one LSP-Ping test case. 903 7.1. Configuration of Control Information 905 Configure the control-info for sample-test-case. 907 Request from netconf client: 908 909 910 911 912 913 914 915 916 sample-test-case 917 918 ip-prefix 919 112.80.248.74 920 reply-via-udp 921 1 922 seconds 923 1 924 seconds 925 6 926 enabled 927 64 928 this is a lsp ping test 929 ipv4 930 112.90.83.122 931 56 932 933 934 935 936 937 939 Reply from netconf server: 940 941 942 944 7.2. Configuration of Schedule Parameters 946 Set the schedule-parameters for sample-test-case to start the test. 948 Request from netconf client: 949 950 951 952 953 954 955 956 957 sample-test-case 958 959 960 961 962 963 964 965 967 Reply from netconf server: 968 969 970 972 7.3. Display of Result Information 974 Get the result-info of sample-test-case. 976 Request from netconf client: 977 978 979 980 981 982 sample-test-case 983 984 985 986 987 988 990 Reply from netconf server: 991 992 993 994 995 sample-test-case 996 997 completed 998 ipv4 999 112.90.83.122 1000 ip-prefix 1001 112.80.248.74 1002 10 1003 56 1004 36 1005 6 1006 6 1007 8882 1008 2015-07-01T10:36:56 1009 1010 1011 0 1012 0 1013 3 1014 10 1015 success 1016 1017 1018 1 1019 0 1020 3 1021 56 1022 success 1023 1024 1025 2 1026 0 1027 3 1028 35 1029 success 1030 1031 1032 3 1033 0 1034 3 1035 38 1036 success 1037 1038 1039 4 1040 0 1041 3 1042 36 1043 success 1045 1046 1047 5 1048 0 1049 3 1050 41 1051 success 1052 1053 1054 1055 1056 1057 1058 1060 8. Security Considerations 1062 The configuration and state data defined in this document is designed 1063 to be accessed via the NETCONF protocol [RFC6241]. The lowest 1064 NETCONF layer is the secure transport layer and the mandatory-to- 1065 implement secure transport is SSH [RFC6242]. The authors recommend 1066 to implement the NETCONF access control model [RFC6536] to restrict 1067 access for particular NETCONF users to a pre-configured subset of all 1068 available NETCONF protocol operations and content. 1070 There are a number of config true nodes defined in the YANG module 1071 which are writable/creatable/deletable. These data nodes may be 1072 considered sensitive or vulnerable in some network environments. 1073 Write operations to these data nodes without proper protection can 1074 have a negative effect on network operations. 1076 9. IANA Considerations 1078 The IANA is requested to as assign a new namespace URI from the IETF 1079 XML registry. 1081 URI:TBA 1083 10. Acknowledgements 1085 We would also like to thank XXX. 1087 11. References 1088 11.1. Normative References 1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1091 Requirement Levels", BCP 14, RFC 2119, 1092 DOI 10.17487/RFC2119, March 1997, 1093 . 1095 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1096 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1097 DOI 10.17487/RFC4379, February 2006, 1098 . 1100 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1101 the Network Configuration Protocol (NETCONF)", RFC 6020, 1102 DOI 10.17487/RFC6020, October 2010, 1103 . 1105 11.2. Informative References 1107 [I-D.ietf-lmap-framework] 1108 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1109 Aitken, P., and A. Akhter, "A framework for Large-Scale 1110 Measurement of Broadband Performance (LMAP)", draft-ietf- 1111 lmap-framework-14 (work in progress), April 2015. 1113 [I-D.ietf-mpls-rfc4379bis] 1114 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 1115 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 1116 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 1117 rfc4379bis-09 (work in progress), October 2016. 1119 [I-D.mahesh-netconf-persistent] 1120 Jethanandani, M., "NETCONF and persistent responses", 1121 draft-mahesh-netconf-persistent-00 (work in progress), 1122 October 2014. 1124 [RFC4560] Quittek, J., Ed. and K. White, Ed., "Definitions of 1125 Managed Objects for Remote Ping, Traceroute, and Lookup 1126 Operations", RFC 4560, DOI 10.17487/RFC4560, June 2006, 1127 . 1129 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1130 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1131 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1132 2009, . 1134 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1135 and A. Bierman, Ed., "Network Configuration Protocol 1136 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1137 . 1139 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1140 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1141 . 1143 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1144 Performing Label Switched Path Ping (LSP Ping) over MPLS 1145 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 1146 . 1148 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 1149 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 1150 Failures in Point-to-Multipoint MPLS - Extensions to LSP 1151 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 1152 . 1154 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1155 Protocol (NETCONF) Access Control Model", RFC 6536, 1156 DOI 10.17487/RFC6536, March 2012, 1157 . 1159 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label 1160 Switched Path (LSP) Ping for Pseudowire Forwarding 1161 Equivalence Classes (FECs) Advertised over IPv6", 1162 RFC 6829, DOI 10.17487/RFC6829, January 2013, 1163 . 1165 Authors' Addresses 1167 Lianshu Zheng 1168 Huawei Technologies 1169 China 1171 Email: vero.zheng@huawei.com 1173 Sam K. Aldrin 1174 Google 1175 USA 1177 Email: aldrin.ietf@gmail.com 1178 Guangying Zheng 1179 Huawei Technologies 1180 China 1182 Email: zhengguangying@huawei.com 1184 Greg Mirsky 1185 Ericsson 1186 USA 1188 Email: gregory.mirsky@ericsson.com 1190 Reshad Rahman 1191 Cisco Systems 1192 Canada 1194 Email: rrahman@cisco.com