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