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