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