idnits 2.17.00 (12 Aug 2021) /tmp/idnits33012/draft-ietf-lime-yang-connectionless-oam-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2017) is 1806 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) == Outdated reference: draft-ietf-bfd-yang has been published as RFC 9127 == Outdated reference: draft-ietf-i2rs-yang-network-topo has been published as RFC 8345 == Outdated reference: draft-ietf-lime-yang-connectionless-oam-methods has been published as RFC 8533 == Outdated reference: draft-ietf-netmod-schema-mount has been published as RFC 8528 == Outdated reference: draft-ietf-rtgwg-ni-model has been published as RFC 8529 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: draft-ietf-spring-sr-yang has been published as RFC 9020 == Outdated reference: A later version (-10) exists of draft-zheng-mpls-lsp-ping-yang-cfg-04 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kumar 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Wang 5 Expires: December 11, 2017 Q. Wu 6 Huawei 7 R. Rahman 8 S. Raghavan 9 Cisco 10 June 9, 2017 12 Generic YANG Data Model for Connectionless Operations, Administration, 13 and Maintenance(OAM) protocols 14 draft-ietf-lime-yang-connectionless-oam-06 16 Abstract 18 This document presents a base YANG Data model for connectionless 19 Operations Administration, and Maintenance(OAM) protocols. It 20 provides a technology-independent abstraction of key OAM constructs 21 for connectionless protocols. The base model presented here can be 22 extended to include technology specific details. This is leading to 23 uniformity between OAM protocols and support both nested OAM 24 workflows (i.e., performing OAM functions at different or same levels 25 through a unified interface). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 11, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions used in this document . . . . . . . . . . . . . . 3 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 65 3. Overview of the Connectionless OAM Model . . . . . . . . . . 4 66 3.1. TP Address . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. OAM-layers . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Test Point Locations Information . . . . . . . . . . . . 7 70 3.5. Test Point Locations . . . . . . . . . . . . . . . . . . 7 71 3.6. Path Discovery Data . . . . . . . . . . . . . . . . . . . 7 72 3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 8 73 4. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Connectionless model applicability . . . . . . . . . . . . . 33 75 5.1. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 34 76 5.1.1. Augment Method . . . . . . . . . . . . . . . . . . . 34 77 5.1.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 36 78 5.2. LSP ping extension . . . . . . . . . . . . . . . . . . . 38 79 5.2.1. Augment Method . . . . . . . . . . . . . . . . . . . 38 80 5.2.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 39 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 83 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 43 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 43 86 9.2. Informative References . . . . . . . . . . . . . . . . . 45 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 89 1. Introduction 91 Operations, Administration, and Maintenance (OAM) are important 92 networking functions that allow operators to: 94 1. Monitor networks connections (Reachability Verification, 95 Continuity Check). 97 2. Troubleshoot failures (Fault verification and localization). 99 3. Monitor Performance 101 An overview of OAM tools is presented at [RFC7276]. 103 Ping and Traceroute [RFC792], [RFC4443] are well-known fault 104 verification and isolation tools, respectively, for IP networks. 105 Over the years, different technologies have developed similar tools 106 for similar purposes. 108 The different OAM tools may support connection-oriented technologies 109 or connectionless technologies. In connection-oriented technologies, 110 a connection is established prior to the transmission of data. In 111 connectionless technologies, data is typically sent between end 112 points without prior arrangement [RFC7276]. Note that the 113 Connection-Oriented OAM YANG DATA model is defined in 114 [I-D.ietf-lime-yang-oam-model]. 116 In this document, we presents a base YANG Data model for 117 connectionless OAM protocols. The generic YANG model for 118 connectionless OAM only includes configuration data and state data. 119 It can be used in conjunction with data retrieval method model 120 [I-D.ietf-lime-yang-connectionless-oam-methods], which focuses on 121 data retrieval procedures like RPC. However it also can be used 122 independently of data retrieval method model. 124 2. Conventions used in this document 126 The following terms are defined in [RFC6241] and are not redefined 127 here: 129 o client 131 o configuration data 133 o server 135 o state data 137 The following terms are defined in [RFC6020] and are not redefined 138 here: 140 o augment 142 o data model 144 o data node 145 The terminology for describing YANG data models is found in 146 [RFC6020]. 148 2.1. Terminology 150 TP - Test Point 152 MAC - Media Access Control 154 BFD - Bidirectional Forwarding Detection 156 RPC - A Remote Procedure Call, as used within the NETCONF protocol 158 CC - Continuity Check [RFC7276] , Continuity Checks are used to 159 verify that a destination is reachable and therefore also referred to 160 as reachability verification 162 2.2. Prefixes in Data Node Names 164 In this document, names of data nodes, actions and other data model 165 objects are often used without a prefix, as long as it is clear from 166 the context in which YANG module each name is defined. Otherwise, 167 names are prefixed using the standard prefix associated with the 168 corresponding YANG module, as shown in Table 1. 170 +--------+-----------------------+----------------------------------+ 171 | Prefix | YANG module | Reference | 172 +--------+-----------------------+----------------------------------+ 173 | if | ietf-interfaces | [RFC7223] | 174 | | | | 175 | inet | ietf-inet-types | [RFC6991] | 176 | | | | 177 | yangmn | ietf-yang-schema- | [I-D.ietf-netmod-schema-mount] | 178 | t | mount | | 179 | | | | 180 | nd | ietf-network | [I-D.ietf-i2rs-yang-network-topo | 181 | | | ] | 182 | | | | 183 | ni | ietf-network-instance | [I-D.ietf-rtgwg-ni-model] | 184 +--------+-----------------------+----------------------------------+ 186 Table 1: Prefixes and corresponding YANG modules 188 3. Overview of the Connectionless OAM Model 190 At the top of the model, there is an 'cc-oper-data' container for 191 session statistics. Grouping is also defined for common session 192 statistics and these are applicable for proactive OAM sessions. 194 Multiple 'test-point-locations' keyed using technology specific keys 195 (eg., IPv4 address for IPv4 locations) are possible by augmented 196 network nodes which are defined in [I-D.ietf-i2rs-yang-network-topo] 197 to describe the network hierarchies and the inventory of nodes 198 contained in a network. Each 'test-point-location' is chosen based 199 on 'location-type' which when chosen, leads to a container that 200 includes a list of 'test-point-locations' keyed by technology 201 specific keys. Each test point location includes a 'test-point- 202 location-info'. The 'test-point-location-info' includes 'tp- 203 technology', 'tp-tools', and 'connectionless-oam-layers'. The 204 groupings of 'tp-address' and 'tp-address-vrf' are kept out of 'test- 205 point-location-info' to make it addressing agnostic and allow varied 206 composition. Depending upon the choice of the 'location-type' 207 (determined by the 'tp-address-vrf'), the containers differ in its 208 composition of 'test-point-locations' while the 'test-point-location- 209 info', is a common aspect of every 'test-point-location'. The vrf is 210 used to describe the corresponding network instance. The 'tp- 211 technology' indicate OAM technology details. The 'tp-tools' describe 212 the OAM tools supported. The 'connectionless-oam-layers' is used to 213 describe the relationship of one test point with other test points. 214 The level in 'oam-layers' indicate whether related OAM test point is 215 The level in oam-layers indicate whether related oam test point is in 216 client layer(lower layer described in section 3.3), server layer 217 (upper layer described in section 3.3) or the same layer as the 218 current test point under Test point Locations. The model is 219 augmented to "/nd:networks/nd:network/nd:node" using 'test-point- 220 locations' defined below. 222 3.1. TP Address 224 In connectionless OAM, the tp address is defined with the following 225 type: 227 o MAC address [RFC6136] 229 o IPv4 or IPv6 address 231 o TP-attribute 233 o System-id to represent the device or 234 node.[I-D.ietf-spring-sr-yang] 236 To define a forwarding treatment of a test packet, the 'tp-address' 237 needs to be associated with additional parameters, e.g. DSCP for IP 238 or TC for MPLS. In generic connectionless OAM YANG model, these 239 parameters are not explicit configured. The model user can add 240 corresponding parameters according to their requirements. 242 3.2. Tools 244 The different OAM tools may be used in one of two basic types of 245 activation: proactive and on-demand. The proactive OAM refers to OAM 246 actions which are carried out continuously to permit proactive 247 reporting of fault. The proactive OAM method requires persistent 248 configuration. The on-demand OAM refers to OAM actions which are 249 initiated via manual intervention for a limited time to carry out 250 diagnostics. The on-demand OAM method requires only transient 251 configuration.[RFC7276] [G.8013]. In connectionless OAM, 'session- 252 type' is defined to indicate which kind of activation will be used by 253 the current session. 255 In connectionless OAM, the tools attribute is used to describe a 256 toolset for fault detection and isolation. And it can serve as a 257 constraint condition when the base model be extended to specific OAM 258 technology. For example, to fulfill the ICMP PING configuration, the 259 "../coam:continuity-check" should be set to "true", and then the lime 260 base model should be augmented with ICMP PING specific details. 262 3.3. OAM-layers 264 As typical networks have a multi-layer architecture, the set of OAM 265 protocols similarly take a multi-layer structure; each layer may has 266 its own OAM protocol [RFC7276] and is corresponding to specific 267 administrative domain or path and has associated test points. OAM- 268 layers is referred to a list of server layer, client layer that are 269 related to current test point. This allows users to easily navigate 270 between related layer to efficiently troubleshoot a "loss of 271 continuity defect". In this model, we have kept level default as 0, 272 when all test points are located at the same layer. 'Level' defines 273 the relative technology level in a sequence of administrative 274 domains, and is provided to allow correlation of faults in related 275 OAM domains. For example, there is a network in which data traffic 276 between two customer edges is transported over three consecutive 277 administrative domains, where the current test point is located in 278 the second administrative domain. In this scenario second 279 administrative domain is acting as client to first administrative 280 domain and server to third administrative domain. For Test Point at 281 second administrative domain, client level is "-1", i.e. third 282 administrative domain and server level is "1", i.e. first 283 administrative domain. In another example, if the first 284 administrative domain and the second are in same level then it's 285 upstream or downstream administrative domain scenario and thus second 286 administrative domain level is set to "0". 288 list oam-layers { 289 key "index"; 290 leaf index { 291 type uint16 { 292 range "0..65535"; 293 } 294 } 295 leaf level { 296 type int32 { 297 range "-1..1"; 298 } 299 description 300 "Level"; 301 } 303 description 304 "List of related oam layers."; 305 } 307 3.4. Test Point Locations Information 309 This is a generic grouping for Test Point Locations Information. It 310 Provide details of Test Point Location using Tools, 'OAM-Layers' 311 grouping defined above. 313 3.5. Test Point Locations 315 This is a generic grouping for Test Point Locations. Choice 316 statement is used to define locations types, for example 'ipv4- 317 location-type', 'ipv6-location-type', etc. Container is defined 318 under each location type containing list keyed to test point address, 319 Test Point Location Information defined in section above, and routing 320 instance VRF name if required. 322 3.6. Path Discovery Data 324 This is a generic grouping for path discovery data model that can be 325 retrieved by any data retrieval methods including RPCs. Path 326 discovery data output from methods, includes 'src-test-point', 'dst- 327 test-point', 'sequence-number', 'hop-cnt', session statistics of 328 various kinds, path verification and path trace related information. 329 Path discovery includes data to be retrieved on a 'per-hop' basis via 330 a list of 'path-trace-info-list' which includes information like 331 'timestamps', 'ingress-interface', 'egress-interface' and 'app-meta- 332 data'. The path discovery data model is made generic enough to allow 333 different methods of data retrieval. None of the fields are made 334 mandatory for that reason. Noted that the retrieval methods are 335 defined in [I-D.ietf-lime-yang-connectionless-oam-methods]. 337 3.7. Continuity Check Data 339 This is a generic grouping for continuity check data model that can 340 be retrieved by any data retrieval methods including RPCs. 341 Continuity check data output from methods, includes 'src-test-point', 342 'dst-test-point', 'sequence-number', 'hop-cnt' and session statistics 343 of various kinds. The continuity check data model is made generic 344 enough to allow different methods of data retrieval. None of the 345 fields are made mandatory for that reason. Noted that the retrieval 346 methods are defined in 347 [I-D.ietf-lime-yang-connectionless-oam-methods]. 349 4. OAM YANG Module 351 file "ietf-connectionless-oam@2017-06-09.yang" 353 module ietf-connectionless-oam { 354 yang-version 1.1; 355 namespace "urn:ietf:params:xml:ns:yang:ietf-connectionless-oam"; 356 prefix coam; 358 import ietf-yang-schema-mount { 359 prefix yangmnt; 360 } 361 import ietf-network { 362 prefix nd; 363 } 364 import ietf-yang-types { 365 prefix yang; 366 } 367 import ietf-interfaces { 368 prefix if; 369 } 370 import ietf-inet-types { 371 prefix inet; 372 } 373 import ietf-network-instance { 374 prefix ni; 375 } 377 organization 378 "IETF LIME Working Group"; 379 contact 380 "Deepak Kumar dekumar@cisco.com 381 Qin Wu bill.wu@huawei.com 382 S Raghavan srihari@cisco.com 383 Zitao Wang wangzitao@huawei.com 384 R Rahman rrahman@cisco.com"; 386 description 387 "This YANG module defines the generic configuration, 388 data model, statistics for connectionless OAM to be 389 used within IETF in a protocol indpendent manner. 390 Functional level abstraction is indendent with 391 YANG modeling. It is assumed that each protocol maps 392 corresponding abstracts to its native format. 393 Each protocol may extend the YANG model defined 394 here to include protocol specific extensions"; 396 revision 2017-06-09 { 397 description 398 " Base model for Connectionless 399 Operations, Administration, 400 and Maintenance(OAM) "; 401 reference 402 " RFC XXXX: Connectionless 403 Operations, Administration, and 404 Maintenance(OAM)YANG Data Model"; 405 } 407 feature connection-less { 408 description 409 "This feature indicates that OAM solution is connection less."; 410 } 412 feature continuity-check { 413 description 414 "This feature indicates that the server supports 415 executing continuity check OAM command and 416 returning a response. Servers that do not advertise 417 this feature will not support executing 418 continuity check command or rpc model for 419 continuity check command."; 420 } 422 feature path-discovery { 423 description 424 "This feature indicates that the server supports 425 executing path discovery OAM command and 426 returning a response. Servers that do not advertise 427 this feature will not support executing 428 path discovery command or rpc model for 429 path discovery command."; 430 } 432 typedef router-id { 433 type yang:dotted-quad; 434 description 435 "A 32-bit number in the dotted quad format assigned to each 436 router. This number uniquely identifies the router within an 437 Autonomous System."; 438 } 440 typedef routing-instance-ref { 441 type leafref { 442 path "/ni:network-instances/ni:network-instance/ni:name"; 443 } 444 description 445 "This type is used for leafs that reference a routing instance 446 configuration."; 447 } 449 typedef ipv4-multicast-group-address { 450 type string { 451 pattern "(2((2[4-9])|(3[0-9]))\\.)"+" 452 (([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\\.)" 453 +"{2}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"; 454 } 455 description 456 "The ipv4-multicast-group-address type 457 represents an IPv4 multicast address 458 in dotted-quad notation."; 459 reference "RFC4607"; 460 } 462 typedef ipv6-multicast-group-address { 463 type string { 464 pattern "(((FF|ff)[0-9a-fA-F]{2}):)" 465 +"([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)" 466 +"?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|" 467 +"[01]?[0-9]?[0-9])\\.){3}(25[0-5]|2[0-4][0-9]|" 468 +"[01]?[0-9]?[0-9])))"; 469 pattern "(([^:]+:){6}(([^:]+:[^:]+)|(.*\\..*)))|" 470 +"((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)"; 471 } 472 description 473 "The ipv6-multicast-group-address 474 type represents an IPv6 address in full, 475 mixed, shortened, and shortened-mixed 476 notation."; 477 reference 478 "RFC4291 2.7. 479 ietf-inet-types:ipv6-address"; 480 } 481 typedef ip-multicast-group-address { 482 type union { 483 type ipv4-multicast-group-address; 484 type ipv6-multicast-group-address; 485 } 486 description 487 "The ip-multicast-group-address type 488 represents an IP multicast address and 489 is IP version neutral. The format of the 490 textual representations implies the IP version."; 491 } 493 identity address-attribute-types { 494 description 495 "This is base identity of address 496 attribute types which are ip-prefix, 497 bgp, tunnel, pwe3, vpls, etc."; 498 } 500 typedef address-attribute-type { 501 type identityref { 502 base address-attribute-types; 503 } 504 description 505 "Target address attribute type."; 506 } 508 identity time-resolution { 509 description 510 "Time interval resolution"; 511 } 513 identity hours { 514 base time-resolution; 515 description 516 "Time resolution in Hours"; 517 } 519 identity minutes { 520 base time-resolution; 521 description 522 "Time resolution in Minutes"; 523 } 525 identity seconds { 526 base time-resolution; 527 description 528 "Time resolution in Seconds"; 530 } 532 identity milliseconds { 533 base time-resolution; 534 description 535 "Time resolution in Milliseconds"; 536 } 538 identity microseconds { 539 base time-resolution; 540 description 541 "Time resolution in Microseconds"; 542 } 544 identity nanoseconds { 545 base time-resolution; 546 description 547 "Time resolution in Nanoseconds"; 548 } 550 grouping cc-session-statistics { 551 description 552 "Grouping for session statistics."; 553 container cc-session-statistics { 554 description 555 "cc session counters"; 556 leaf session-count { 557 type uint32; 558 description 559 "Number of Continuity Check sessions."; 560 } 561 leaf session-up-count { 562 type uint32; 563 description 564 "Number of sessions which are up."; 565 } 566 leaf session-down-count { 567 type uint32; 568 description 569 "Number of sessions which are down."; 570 } 571 leaf session-admin-down-count { 572 type uint32; 573 description 574 "Number of sessions which are admin-down."; 575 } 576 } 577 } 578 grouping session-packet-statistics { 579 description 580 "Grouping for per session packet statistics"; 581 container session-packet-statistics { 582 description 583 "Per session packet statistics."; 584 leaf rx-packet-count { 585 type uint32; 586 description 587 "Total number of received OAM packet count."; 588 } 589 leaf tx-packet-count { 590 type uint32; 591 description 592 "Total number of transmitted OAM packet count."; 593 } 594 leaf rx-bad-packet { 595 type uint32; 596 description 597 "Total number of received bad OAM packet."; 598 } 599 leaf tx-packet-failed { 600 type uint32; 601 description 602 "Total number of send OAM packet failed."; 603 } 604 } 605 } 607 grouping cc-per-session-statistics { 608 description 609 "Grouping for per session statistics"; 610 container cc-per-session-statistics { 611 description 612 "per session statistics."; 613 leaf create-time { 614 type yang:date-and-time; 615 description 616 "Time and date when session is created."; 617 } 618 leaf last-down-time { 619 type yang:date-and-time; 620 description 621 "Time and date last time session is down."; 622 } 623 leaf last-up-time { 624 type yang:date-and-time; 625 description 626 "Time and date last time session is up."; 627 } 628 leaf down-count { 629 type uint32; 630 description 631 "Total Continuity Check sessions down count."; 632 } 633 leaf admin-down-count { 634 type uint32; 635 description 636 "Total Continuity Check sessions admin down count."; 637 } 638 uses session-packet-statistics; 639 } 640 } 642 grouping session-error-statistics { 643 description 644 "Grouping for per session error statistics"; 645 container session-error-statistics { 646 description 647 "Per session error statistics."; 648 leaf packet-drops-count { 649 type uint32; 650 description 651 "Total received packet drops count."; 652 } 653 leaf packet-reorder-count { 654 type uint32; 655 description 656 "Total received packet reordered count."; 657 } 658 leaf packets-out-of-seq-count { 659 type uint32; 660 description 661 "Total received out of sequence count."; 662 } 663 leaf packets-dup-count { 664 type uint32; 665 description 666 "Total received packet duplicates count."; 667 } 668 } 669 } 671 grouping session-delay-statistics { 672 description 673 "Grouping for per session delay statistics"; 675 container session-delay-statistics { 676 description 677 "Session delay summarised information."; 678 leaf time-resolution-value { 679 type identityref { 680 base time-resolution; 681 } 682 description 683 "Time units among choice of s,ms,ns etc."; 684 } 685 leaf min-delay-value { 686 type uint32; 687 description 688 "Minimum delay value observed."; 689 } 690 leaf max-delay-value { 691 type uint32; 692 description 693 "Maximum delay value observed."; 694 } 695 leaf average-delay-value { 696 type uint32; 697 description 698 "Average delay value observed."; 699 } 700 } 701 } 703 grouping session-jitter-statistics { 704 description 705 "Grouping for per session jitter statistics"; 706 container session-jitter-statistics { 707 description 708 "Session jitter summarised information."; 709 leaf time-resolution-value { 710 type identityref { 711 base time-resolution; 712 } 713 description 714 "Time units among choice of s,ms,ns etc."; 715 } 716 leaf min-jitter-value { 717 type uint32; 718 description 719 "Minimum jitter value observed."; 720 } 721 leaf max-jitter-value { 722 type uint32; 723 description 724 "Maximum jitter value observed."; 725 } 726 leaf average-jitter-value { 727 type uint32; 728 description 729 "Average jitter value observed."; 730 } 731 } 732 } 734 grouping session-path-verification-statistics { 735 description 736 "Grouping for per session path verification statistics"; 737 container session-path-verification-statistics { 738 description 739 "OAM per session path verification statistics."; 740 leaf verified-count { 741 type uint32; 742 description 743 "Total number of OAM packets that 744 went through a path as intended."; 745 } 746 leaf failed-count { 747 type uint32; 748 description 749 "Total number of OAM packets that 750 went through an unintended path."; 751 } 752 } 753 } 755 grouping session-type { 756 description 757 "This object indicates the current session 758 definition."; 759 leaf session-type-enum { 760 type enumeration { 761 enum "proactive" { 762 description 763 "The current session is proactive"; 764 } 765 enum "on-demand" { 766 description 767 "The current session is on-demand."; 768 } 769 } 770 default "on-demand"; 771 description 772 "Session type enum"; 773 } 774 } 776 identity tp-address-technology-type { 777 description 778 "Test point address type"; 779 } 781 identity mac-address-type { 782 base tp-address-technology-type; 783 description 784 "MAC address type"; 785 } 787 identity ipv4-address-type { 788 base tp-address-technology-type; 789 description 790 "IPv4 address type"; 791 } 793 identity ipv6-address-type { 794 base tp-address-technology-type; 795 description 796 "IPv6 address type"; 797 } 799 identity tp-attribute-type { 800 base tp-address-technology-type; 801 description 802 "Test point attribute type"; 803 } 805 identity system-id-address-type { 806 base tp-address-technology-type; 807 description 808 "System id address type"; 809 } 811 identity as-number-address-type { 812 base tp-address-technology-type; 813 description 814 "AS number address type"; 815 } 817 identity group-ip-address-type { 818 base tp-address-technology-type; 819 description 820 "Group IP address type"; 821 } 823 identity route-distinguisher-address-type { 824 base tp-address-technology-type; 825 description 826 "Route Distinguisher address type"; 827 } 829 identity ip-prefix-address-type { 830 base tp-address-technology-type; 831 description 832 "IP prefix address type"; 833 } 835 identity tunnel-address-type { 836 base tp-address-technology-type; 837 description 838 "Tunnel address type"; 839 } 841 grouping tp-address { 842 leaf tp-location-type-value { 843 type identityref { 844 base tp-address-technology-type; 845 } 847 description 848 "Test point address type."; 849 } 850 choice tp-address { 851 case mac-address { 852 when "'tp-location-type-value' = 'mac-address-type'" { 853 description 854 "MAC address type"; 855 } 856 leaf mac-address { 857 type yang:mac-address; 858 description 859 "MAC Address"; 860 } 861 description 862 "MAC Address based MP Addressing."; 863 } 864 case ipv4-address { 865 when "'tp-location-type-value' = 'ipv4-address-type'" { 866 description 867 "IPv4 address type"; 868 } 869 leaf ipv4-address { 870 type inet:ipv4-address; 871 description 872 "IPv4 Address"; 873 } 874 description 875 "IP Address based MP Addressing."; 876 } 877 case ipv6-address { 878 when "'tp-location-type-value' = 'ipv6-address-type'" { 879 description 880 "IPv6 address type"; 881 } 882 leaf ipv6-address { 883 type inet:ipv6-address; 884 description 885 "IPv6 Address"; 886 } 887 description 888 "ipv6 Address based MP Addressing."; 889 } 890 case tp-attribute { 891 when "'tp-location-type-value' = 'tp-attribute-type'" { 892 description 893 "Test point attribute type"; 894 } 895 leaf tp-attribute-type { 896 type address-attribute-type; 897 description 898 "Test point type."; 899 } 900 choice tp-attribute-value { 901 description 902 "Test point value."; 903 case ip-prefix { 904 leaf ip-prefix { 905 type inet:ip-prefix; 906 description 907 "IP prefix."; 908 } 909 } 910 case bgp { 911 leaf bgp { 912 type inet:ip-prefix; 913 description 914 "BGP Labeled Prefix "; 916 } 917 } 918 case tunnel { 919 leaf tunnel-interface { 920 type uint32; 921 description 922 "VPN Prefix "; 923 } 924 } 925 case pw { 926 leaf remote-pe-address { 927 type inet:ip-address; 928 description 929 "Remote pe address."; 930 } 931 leaf pw-id { 932 type uint32; 933 description 934 "Pseudowire ID is a non-zero 32-bit ID."; 935 reference 936 "RFC 4379 :Detecting Multi-Protocol Label 937 Switched (MPLS) Data Plane Failures"; 938 } 939 } 940 case vpls { 941 leaf route-distinguisher { 942 type uint32; 943 description 944 "Route Distinguisher is an 8 octets identifier 945 used to distinguish information about various 946 L2VPN advertised by a node."; 947 reference 948 "RFC 4379 :Detecting Multi-Protocol Label 949 Switched (MPLS) Data Plane Failures"; 950 } 951 leaf sender-ve-id { 952 type uint32; 953 description 954 "Sender's VE ID. The VE ID (VPLS Edge Identifier) 955 is a 2-octet identifier."; 956 reference 957 "RFC 4379 :Detecting Multi-Protocol Label 958 Switched (MPLS) Data Plane Failures"; 959 } 960 leaf receiver-ve-id { 961 type uint32; 962 description 963 "Receiver's VE ID.The VE ID (VPLS Edge Identifier) 964 is a 2-octet identifier."; 965 reference 966 "RFC 4379 :Detecting Multi-Protocol Label 967 Switched (MPLS) Data Plane Failures"; 968 } 969 } 970 case mpls-mldp { 971 choice root-address { 972 description 973 "Root address choice."; 974 case ip-address { 975 leaf source-address { 976 type inet:ip-address; 977 description 978 "IP address."; 979 } 980 leaf group-ip-address { 981 type ip-multicast-group-address; 982 description 983 "Group ip address."; 984 } 985 } 986 case vpn { 987 leaf as-number { 988 type inet:as-number; 989 description 990 "The AS number represents autonomous system 991 numbers which identify an Autonomous System."; 992 } 993 } 994 case global-id { 995 leaf lsp-id { 996 type string; 997 description 998 "LSP ID is an identifier of a LSP 999 within a MPLS network."; 1000 reference 1001 "RFC 4379 :Detecting Multi-Protocol Label 1002 Switched (MPLS) Data Plane Failures"; 1003 } 1004 } 1005 } 1006 } 1007 } 1008 } 1009 case system-info { 1010 when "'tp-location-type-value' = 'system-id-address-type'" { 1011 description 1012 "System id address type"; 1013 } 1014 leaf system-id { 1015 type router-id; 1016 description 1017 "System ID assigned to this node."; 1018 } 1019 } 1020 description 1021 "TP Addressing."; 1022 } 1023 description 1024 "TP Address"; 1025 } 1027 grouping tp-address-vrf { 1028 description 1029 "Test point address with VRF."; 1030 leaf vrf { 1031 type routing-instance-ref; 1032 description 1033 "The vrf is used to describe the 1034 corresponding network instance"; 1035 } 1036 uses tp-address; 1037 } 1039 grouping connectionless-oam-layers { 1040 list oam-layers { 1041 key "index"; 1042 leaf index { 1043 type uint16 { 1044 range "0..65535"; 1045 } 1046 description 1047 "Index"; 1048 } 1049 leaf level { 1050 type int32 { 1051 range "-1..1"; 1052 } 1053 default "0"; 1054 description 1055 "Level 0 indicates default level, 1056 -1 means server and +1 means client layer. 1057 In relationship 0 means same layer."; 1058 } 1059 choice tp-location { 1060 case mac-address { 1061 leaf mac-address-location { 1062 type yang:mac-address; 1063 description 1064 "MAC Address"; 1065 } 1066 description 1067 "MAC Address based MP Addressing."; 1068 } 1069 case ipv4-address { 1070 leaf ipv4-location { 1071 type inet:ipv4-address; 1072 description 1073 "Ipv4 Address"; 1074 } 1075 description 1076 "IP Address based MP Addressing."; 1077 } 1078 case ipv6-location { 1079 leaf ipv6-address { 1080 type inet:ipv6-address; 1081 description 1082 "IPv6 Address"; 1083 } 1084 description 1085 "IPv6 Address based MP Addressing."; 1086 } 1087 case group-ip-address-location { 1088 leaf group-ip-address-location { 1089 type ip-multicast-group-address; 1090 description 1091 "Group IP address location"; 1092 } 1093 description 1094 "Group IP address"; 1095 } 1096 case as-number-location { 1097 leaf as-number-location { 1098 type inet:as-number; 1099 description 1100 "AS number location"; 1101 } 1102 description 1103 "AS number for point to multipoint OAM"; 1104 } 1105 case system-id-location { 1106 leaf system-id-location { 1107 type router-id; 1108 description 1109 "System id location"; 1110 } 1111 description 1112 "System ID"; 1113 } 1114 description 1115 "TP location."; 1116 } 1118 description 1119 "List of related oam layers. 1120 0 means they are in same level, especially 1121 interworking scenarios of stitching multiple 1122 technology at same layer. -1 means server layer, 1123 for eg:- in case of Overlay and Underlay, 1124 Underlay is server layer for Overlay Test Point. 1125 +1 means client layer, for example in case of 1126 Service OAM and Transport OAM, Service OAM is client 1127 layer to Transport OAM."; 1128 } 1129 description 1130 "Connectionless related OAM layer"; 1131 } 1133 grouping tp-technology { 1134 choice technology { 1135 default "technology-null"; 1136 case technology-null { 1137 description 1138 "This is a placeholder when no technology is needed."; 1139 leaf tech-null { 1140 type empty; 1141 description 1142 "There is no technology define"; 1143 } 1144 } 1145 description 1146 "Technology choice."; 1147 } 1148 description 1149 "OAM Technology"; 1150 } 1152 grouping tp-tools { 1153 description 1154 "Test Point OAM Toolset."; 1155 container tp-tools { 1156 leaf continuity-check { 1157 type boolean; 1158 mandatory true; 1159 description 1160 "A flag indicating whether or not the 1161 continuity check function is supported."; 1162 reference 1163 "RFC 792: INTERNET CONTROL MESSAGE PROTOCOL. 1164 RFC 4443: Internet Control Message Protocol (ICMPv6) 1165 for the Internet Protocol Version 6 (IPv6) Specification. 1166 RFC 5880: Bidirectional Forwarding Detection. 1167 RFC 5881: BFD for IPv4 and IPv6. 1168 RFC 5883: BFD for Multihop Paths. 1169 RFC 5884: BFD for MPLS Label Switched Paths. 1170 RFC 5885: BFD for PW VCCV. 1171 RFC 6450: Multicast Ping Protocol."; 1172 } 1173 leaf path-discovery { 1174 type boolean; 1175 mandatory true; 1176 description 1177 "A flag indicating whether or not the 1178 path discovery function is supported."; 1179 reference 1180 "RFC 792: INTERNET CONTROL MESSAGE PROTOCOL. 1181 RFC 4443: Internet Control Message Protocol (ICMPv6) 1182 for the Internet Protocol Version 6 (IPv6) Specification. 1183 RFC 4884: Extended ICMP to Support Multi-part Message. 1184 RFC 5837:Extending ICMP for Interface 1185 and Next-Hop Identification. 1186 RFC 4379: LSP-PING."; 1187 } 1188 description 1189 "Container for test point OAM tools set."; 1190 } 1191 } 1193 grouping test-point-location-info { 1194 uses tp-technology; 1195 uses tp-tools; 1196 anydata root { 1197 yangmnt:mount-point "root"; 1198 description 1199 "Root for models supported per 1200 test point"; 1201 } 1202 uses connectionless-oam-layers; 1203 description 1204 "Test point Location"; 1205 } 1207 grouping test-point-locations { 1208 description 1209 "Group of test point locations."; 1210 leaf tp-location-type-value { 1211 type identityref { 1212 base tp-address-technology-type; 1213 } 1214 description 1215 "Test point location type."; 1216 } 1217 choice location-type { 1218 case ipv4-location-type { 1219 when "'tp-location-type-value' = 'ipv4-address-type'" { 1220 description 1221 "When test point location type is equal to ipv4 address."; 1222 } 1223 container test-point-ipv4-location-list { 1224 list test-point-locations { 1225 key "ipv4-location"; 1226 leaf ipv4-location { 1227 type inet:ipv4-address; 1228 description 1229 "IPv4 Address."; 1230 } 1231 leaf vrf { 1232 type routing-instance-ref; 1233 description 1234 "The vrf is used to describe the 1235 corresponding network instance"; 1236 } 1237 uses test-point-location-info; 1239 description 1240 "List of test point locations."; 1241 } 1242 description 1243 "Serves as top-level container 1244 for test point location list."; 1245 } 1246 } 1247 case ipv6-location-type { 1248 when "'tp-location-type-value' = 'ipv6-address-type'" { 1249 description 1250 "when test point location is equal to ipv6 address"; 1251 } 1252 container test-point-ipv6-location-list { 1253 list test-point-locations { 1254 key "ipv6-location"; 1255 leaf ipv6-location { 1256 type inet:ipv6-address; 1257 description 1258 "IPv6 Address."; 1259 } 1260 leaf vrf { 1261 type routing-instance-ref; 1262 description 1263 "The vrf is used to describe the 1264 corresponding network instance"; 1265 } 1266 uses test-point-location-info; 1268 description 1269 "List of test point locations."; 1270 } 1271 description 1272 "Serves as top-level container 1273 for test point location list."; 1274 } 1275 } 1276 case mac-location-type { 1277 when "'tp-location-type-value' = 'mac-address-type'" { 1278 description 1279 "when test point location type is equal to mac address."; 1280 } 1281 container test-point-mac-address-location-list { 1282 list test-point-locations { 1283 key "mac-address-location"; 1284 leaf mac-address-location { 1285 type yang:mac-address; 1286 description 1287 "MAC Address"; 1288 } 1289 uses test-point-location-info; 1291 description 1292 "List of test point locations."; 1293 } 1294 description 1295 "Serves as top-level container 1296 for test point location list."; 1297 } 1298 } 1299 case group-ip-address-location-type { 1300 when "'tp-location-type-value' = 'group-ip-address-type'" { 1301 description 1302 "When test point location type is equal to 1303 group ip address."; 1304 } 1305 container test-point-group-ip-address-location-list { 1306 list test-point-locations { 1307 key "group-ip-address-location"; 1308 leaf group-ip-address-location { 1309 type ip-multicast-group-address; 1310 description 1311 "Group IP address."; 1312 } 1313 leaf vrf { 1314 type routing-instance-ref; 1315 description 1316 "The vrf is used to describe the 1317 corresponding network instance"; 1318 } 1319 uses test-point-location-info; 1321 description 1322 "List of test point locations."; 1323 } 1324 description 1325 "Serves as top-level container for 1326 test point location list."; 1327 } 1328 } 1329 case group-as-number-location-type { 1330 when "'tp-location-type-value' = 'as-number-address-type'" { 1331 description 1332 "When test point location type is equal to 1333 as-number."; 1334 } 1335 container test-point-as-number-location-list { 1336 list test-point-locations { 1337 key "as-number-location"; 1338 leaf as-number-location { 1339 type inet:as-number; 1340 description 1341 "AS number for point to multi point OAM."; 1342 } 1343 leaf vrf { 1344 type routing-instance-ref; 1345 description 1346 "The vrf is used to describe the 1347 corresponding network instance"; 1349 } 1350 uses test-point-location-info; 1352 description 1353 "List of test point locations."; 1354 } 1355 description 1356 "Serves as top-level container 1357 for test point location list."; 1358 } 1359 } 1360 case group-system-id-location-type { 1361 when "'tp-location-type-value' = 'system-id-address-type'" { 1362 description 1363 "When test point location is equal to 1364 system info."; 1365 } 1366 container test-point-system-info-location-list { 1367 list test-point-locations { 1368 key "system-id-location"; 1369 leaf system-id-location { 1370 type inet:uri; 1371 description 1372 "System Id."; 1373 } 1374 leaf vrf { 1375 type routing-instance-ref; 1376 description 1377 "The vrf is used to describe the 1378 corresponding network instance"; 1379 } 1380 uses test-point-location-info; 1382 description 1383 "List of test point locations."; 1384 } 1385 description 1386 "Serves as top-level container for 1387 test point location list."; 1388 } 1389 } 1390 description 1391 "Choice of address types."; 1392 } 1393 } 1395 augment "/nd:networks/nd:network/nd:node" { 1396 description 1397 "Augment test points of connectionless oam."; 1398 uses test-point-locations; 1399 } 1401 grouping uint64-timestamp { 1402 description 1403 "Grouping for timestamp."; 1404 leaf timestamp-sec { 1405 type uint32; 1406 description 1407 "Absolute timestamp in seconds as per IEEE1588v2 1408 or seconds part in 64-bit NTP timestamp."; 1409 } 1410 leaf timestamp-nanosec { 1411 type uint32; 1412 description 1413 "Fractional part in nanoseconds as per IEEE1588v2 1414 or Fractional part in 64-bit NTP timestamp."; 1415 } 1416 } 1418 grouping timestamp { 1419 description 1420 "Grouping for timestamp."; 1421 leaf timestamp-type { 1422 type uint32; 1423 description 1424 "Truncated PTP = 0, NTP = 1"; 1425 } 1426 uses uint64-timestamp; 1427 } 1429 grouping path-discovery-data { 1430 description 1431 "Path discovery related data output from nodes."; 1432 container src-test-point { 1433 description 1434 "Source test point."; 1435 uses tp-address-vrf; 1436 } 1437 container dest-test-point { 1438 description 1439 "Destination test point."; 1440 uses tp-address-vrf; 1441 } 1442 leaf sequence-number { 1443 type uint64; 1444 description 1445 "Sequence number in data packets."; 1446 } 1447 leaf hop-cnt { 1448 type uint8; 1449 description 1450 "Hop count."; 1451 } 1452 uses session-packet-statistics; 1453 uses session-error-statistics; 1454 uses session-delay-statistics; 1455 uses session-jitter-statistics; 1456 container path-verification { 1457 description 1458 "Optional path verification related information."; 1459 leaf flow-info { 1460 type string; 1461 description 1462 "Informations that refers to the flow."; 1463 } 1464 uses session-path-verification-statistics; 1465 } 1466 container path-trace-info { 1467 description 1468 "Optional path trace per-hop test point information. 1469 The list has typically a single element for per-hop 1470 cases like path-discovery RPC but allows a list of 1471 hop related information for other types of 1472 data retrieval methods."; 1473 list path-trace-info-list { 1474 key "index"; 1475 description 1476 "Path trace information list."; 1477 leaf index { 1478 type uint32; 1479 description 1480 "Trace information index."; 1481 } 1482 uses tp-address-vrf; 1483 uses timestamp; 1484 leaf ingress-intf-name { 1485 type if:interface-ref; 1486 description 1487 "Ingress interface name"; 1488 } 1489 leaf egress-intf-name { 1490 type if:interface-ref; 1491 description 1492 "Egress interface name"; 1494 } 1495 leaf queue-depth { 1496 type uint32; 1497 description 1498 "Length of the egress interface 1499 queue of the interface."; 1500 } 1501 leaf transit-delay { 1502 type uint32; 1503 description 1504 "Time in nano seconds 1505 packet spent transiting a node."; 1506 } 1507 leaf app-meta-data { 1508 type uint64; 1509 description 1510 "Application specific 1511 data added by node."; 1512 } 1513 } 1514 } 1515 } 1517 grouping continuity-check-data { 1518 description 1519 "Continuity check data output from nodes."; 1520 container src-test-point { 1521 description 1522 "Source test point."; 1523 uses tp-address-vrf; 1524 leaf egress-intf-name { 1525 type if:interface-ref; 1526 description 1527 "Egress interface name"; 1528 } 1529 } 1530 container dest-test-point { 1531 description 1532 "Destination test point."; 1533 uses tp-address-vrf; 1534 leaf ingress-intf-name { 1535 type if:interface-ref; 1536 description 1537 "Ingress interface name"; 1538 } 1539 } 1540 leaf sequence-number { 1541 type uint64; 1542 description 1543 "Sequence number."; 1544 } 1545 leaf hop-cnt { 1546 type uint8; 1547 description 1548 "Hop count."; 1549 } 1550 uses session-packet-statistics; 1551 uses session-error-statistics; 1552 uses session-delay-statistics; 1553 uses session-jitter-statistics; 1554 } 1556 container cc-session-statistics-data { 1557 if-feature "continuity-check"; 1558 config false; 1559 description 1560 "CC operational information."; 1561 container cc-ipv4-sessions-statistics { 1562 description 1563 "CC ipv4 sessions"; 1564 uses cc-session-statistics; 1565 } 1566 container cc-ipv6-sessions-statistics { 1567 description 1568 "CC ipv6 sessions"; 1569 uses cc-session-statistics; 1570 } 1571 } 1572 } 1574 1576 5. Connectionless model applicability 1578 "ietf-connectionless-oam" model defined in this document provides 1579 technology-independent abstraction of key OAM constructs for 1580 connectionless protocols. This model can be further extended to 1581 include technology specific details, e.g., adding new data nodes with 1582 technology specific functions and parameters into proper anchor 1583 points of the base model, so as to develop a technology-specific 1584 connectionless OAM model. 1586 This section demonstrates the usability of the connectionless YANG 1587 OAM data model to various connectionless OAM technologies, e.g., BFD, 1588 LSP ping. Note that, in this section, we only present several 1589 snippets of technology-specific model extensions for illustrative 1590 purposes. The complete model extensions should be worked on in 1591 respective protocol working groups. 1593 5.1. BFD Extension 1595 5.1.1. Augment Method 1597 The following sections shows how the "ietf-connectionless-oam" model 1598 can be extended to cover BFD technology. For this purpose, a set of 1599 extension are introduced such as technology-type extension and test- 1600 point attributes extension. 1602 Note that in BFD WG, there is a BFD yang data model 1603 [I-D.ietf-bfd-yang] to be produced. Users can choose to use "ietf- 1604 connectioless-oam" as basis and augment the "ietf-connectionless-oam" 1605 model with bfd specific details. The bfd specific details can be the 1606 grouping defined in the BFD model. 1608 5.1.1.1. Technology type extension 1610 No BFD technology type has been defined in the "ietf-connectionless- 1611 oam" model. Therefore a technology type extension is required in the 1612 model Extension. 1614 The snippet below depicts an example of augmenting "bfd" type into 1615 the ietf-connectionless-oam": 1617 augment "/nd:networks/nd:network/nd:node/" 1618 +"coam:location-type/coam:ipv4-location-type" 1619 +"/coam:test-point-ipv4-location-list/" 1620 +"coam:test-point-locations/coam:technology" 1621 +"/coam:technology-string" 1622 { 1623 leaf bfd{ 1624 type string; 1625 } 1626 } 1628 5.1.1.2. Test point attributes extension 1630 To support bfd technology, the "ietf-connectionless-oam" model can be 1631 extended and add bfd specific parameters under "test-point-location" 1632 list and/or add new location type such as "bfd over MPLS-TE" under 1633 "location-type". 1635 5.1.1.2.1. Define and insert new nodes into corresponding test-point- 1636 location 1638 In the "ietf-connectionless-oam" model, multiple "test-point- 1639 location" lists are defined under the "location-type" choice node. 1640 Therefore, to derive a model for some bfd technologies ( such as ip 1641 single-hop, ip multi-hops, etc), data nodes for bfd specific details 1642 need to be added into corresponding "test-point-locations" list. In 1643 this section, we reuse some groupings which are defined in 1644 [I-D.ietf-bfd-yang] as following: 1646 The snippet below shows how the "ietf-connectionless-oam" model can 1647 be extended to support "BFD IP single-hop": 1649 augment "/nd:networks/nd:network/nd:node/" 1650 +"coam:location-type/coam:ipv4-location-type" 1651 +"/coam:test-point-ipv4-location-list/" 1652 +"coam:test-point-locations" 1653 { 1654 container session-cfg { 1655 description "BFD IP single-hop session configuration"; 1656 list sessions { 1657 key "interface dest-addr"; 1658 description "List of IP single-hop sessions"; 1659 leaf interface { 1660 type if:interface-ref; 1661 description 1662 "Interface on which the BFD session is running."; 1663 } 1664 leaf dest-addr { 1665 type inet:ip-address; 1666 description "IP address of the peer"; 1667 } 1668 uses bfd:bfd-grouping-common-cfg-parms; 1669 uses bfd:bfd-grouping-echo-cfg-parms; 1670 } 1671 } 1672 } 1674 Similar augmentations can be defined to support other BFD 1675 technologies such as BFD IP multi-hop, BFD over MPLS, etc. 1677 5.1.1.2.2. Add new location-type cases 1679 In the "ietf-connectionless-oam" model, If there is no appropriate 1680 "location type" case that can be extended, a new "location-type" case 1681 can be defined and inserted into the "location-type" choice node. 1683 Therefore, the model user can flexibly add "location-type" to support 1684 other type of test point which are not defined in the "ietf- 1685 connectionless-oam" model. In this section, we add a new "location- 1686 type" case and reuse some groupings which are defined in 1687 [I-D.ietf-bfd-yang] as follows: 1689 The snippet below shows how the "ietf-connectionless-oam" model can 1690 be extended to support "BFD over MPLS-TE": 1692 augment "/nd:networks/nd:network/nd:node/coam:location-type"{ 1693 case te-location{ 1694 list test-point-location-list{ 1695 key "tunnel-name"; 1696 leaf tunnel-name{ 1697 type leafref{ 1698 path "/te:te/te:tunnels/te:tunnel/te:name"; 1699 } 1700 description 1701 "point to a te instance."; 1702 } 1703 uses bfd:bfd-grouping-common-cfg-parms; 1704 uses bfd-mpls:bfd-encap-cfg; 1705 } 1706 } 1707 } 1709 Similar augmentations can be defined to support other BFD 1710 technologies such as BFD over LAG, etc. 1712 5.1.2. Schema Mount 1714 And another alternative method is using schema mount mechanism 1715 [I-D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam". 1716 Within the "test-point-location" list, a "root" attribute is defined 1717 to provide a mounted point for models mounted per "test-point- 1718 location". Therefore, the "ietf-connectionless-oam" model can 1719 provide a place in the node hierarchy where other OAM YANG data 1720 models can be attached, without any special extension in the "ietf- 1721 connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount]. 1722 Note that the limitation of the Schema Mount method is it is not 1723 allowed to specify certain modules that are required to be mounted 1724 under a mount point. 1726 The snippet below depicts the definition of "root" attribute. 1728 anydata root { 1729 yangmnt:mount-point root; 1730 description 1731 "Root for models supported per 1732 test point"; 1733 } 1735 The following section shows how the "ietf-connectionless-oam" model 1736 can use schema mount to support BFD technology. 1738 5.1.2.1. BFD Modules be populated in schema-mount 1740 To support BFD technology, "ietf-bfd-ip-sh" and "ietf-bfd-ip-mh" YANG 1741 modules might be populated in the "schema-mounts" container: 1743 1745 1746 ietf-connectionless-oam 1747 root 1748 1749 root 1750 1751 1752 1753 root 1754 1755 ietf-bfd-ip-sh 1756 2016-07-04 1757 1758 urn:ietf:params:xml:ns:yang: ietf-bfd-ip-sh 1759 1760 implement 1761 1762 1763 ietf-bfd-ip-mh 1764 2016-07-04 1765 1766 urn:ietf:params:xml:ns:yang: ietf-bfd-ip-mh 1767 1768 implement 1769 1770 1771 1773 and the " ietf-connectionless-oam " module might have: 1775 1777 ...... 1778 1779 192.0.2.1 1780 ...... 1781 1782 1783 1784 foo 1785 ...... 1786 1787 1788 1789 1790 foo 1791 ...... 1792 1793 1794 1795 1796 1798 5.2. LSP ping extension 1800 5.2.1. Augment Method 1802 The following sections shows how the "ietf-connectionless-oam" model 1803 can be extended to support LSP ping technology. For this purpose, a 1804 set of extension are introduced such as technology-type extension and 1805 test-point attributes extension. 1807 Note that in MPLS WG, there is a LSP Ping yang data model 1808 [I-D.zheng-mpls-lsp-ping-yang-cfg] to be produced. Users can choose 1809 to use "ietf-connectioless-oam" as basis and augment the "ietf- 1810 connectionless-oam" model with LSP Ping specific details in the model 1811 extension. The LSP Ping specific details can be the grouping defined 1812 in the LSP ping model. 1814 5.2.1.1. Technology type extension 1816 No lsp-ping technology type has been defined in the "ietf- 1817 connectionless-oam" model. Therefore a technology type extension is 1818 required in the model extension. 1820 The snippet below depicts an example of augmenting the "ietf- 1821 connectionless-oam" with "lsp-ping" type: 1823 augment "/nd:networks/nd:network/nd:node/" 1824 +"coam:location-type/coam:ipv4-location-type" 1825 +"/coam:test-point-ipv4-location-list/" 1826 +"coam:test-point-locations/coam:technology" 1827 +"/coam:technology-string" 1828 { 1829 leaf lsp-ping{ 1830 type string; 1831 } 1832 } 1834 5.2.1.2. Test point attributes extension 1836 To support lsp-ping, the "ietf-connectionless-oam" model can be 1837 extended and add lsp-ping specific parameters can be defined and 1838 under "test-point-location" list. 1840 User can reuse the attributes or groupings which are defined in 1841 [I-D.zheng-mpls-lsp-ping-yang-cfg] as follows: 1843 The snippet below depicts an example of augmenting the "test-point- 1844 locations" list with lsp ping attributes: 1846 augment "/nd:networks/nd:network/nd:node/" 1847 +"coam:location-type/coam:ipv4-location-type" 1848 +"/coam:test-point-ipv4-location-list/" 1849 +"coam:test-point-locations" 1850 { 1851 list lsp-ping { 1852 key "lsp-ping-name"; 1853 leaf lsp-ping-name { 1854 type string { 1855 length "1..31"; 1856 } 1857 mandatory "true"; 1858 description "LSP Ping test name."; 1859 ...... 1860 } 1862 5.2.2. Schema Mount 1864 And another alternative method is using schema mount mechanism 1865 [I-D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam". 1866 Within the "test-point-location" list, a "root" attribute is defined 1867 to provide a mounted point for models mounted per "test-point- 1868 location". Therefore, the "ietf-connectionless-oam" model can 1869 provide a place in the node hierarchy where other OAM YANG data 1870 models can be attached, without any special extension in the "ietf- 1871 connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount]. 1872 Note that the limitation of the Schema Mount method is it is not 1873 allowed to specify certain modules that are required to be mounted 1874 under a mount point. 1876 The snippet below depicts the definition of "root" attribute. 1878 anydata root { 1879 yangmnt:mount-point root; 1880 description 1881 "Root for models supported per 1882 test point"; 1883 } 1885 The following section shows how the "ietf-connectionless-oam" model 1886 can use schema mount to support LSP-PING technology. 1888 5.2.2.1. LSP-PING Modules be populated in schema-mount 1890 To support LSP-PING technology, "ietf-lspping" YANG module 1891 [I-D.zheng-mpls-lsp-ping-yang-cfg] might be populated in the "schema- 1892 mounts" container: 1894 1896 1897 ietf-connectionless-oam 1898 root 1899 1900 root 1901 1902 1903 1904 root 1905 1906 ietf-lspping 1907 2016-03-18 1908 1909 urn:ietf:params:xml:ns:yang: ietf-lspping 1910 1911 implement 1912 1913 1914 1916 and the " ietf-connectionless-oam " module might have: 1918 1920 ...... 1921 1922 192.0.2.1 1923 ...... 1924 1925 1926 1927 foo 1928 ...... 1929 1930 1931 1932 1933 1935 6. Security Considerations 1937 The YANG module defined in this memo is designed to be accessed via 1938 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1939 secure transport layer and the mandatory-to-implement secure 1940 transport is SSH [RFC6242]. The NETCONF access control model 1941 [RFC6536] provides the means to restrict access for particular 1942 NETCONF users to a pre-configured subset of all available NETCONF 1943 protocol operations and content. 1945 There are a number of data nodes defined in the YANG module which are 1946 writable/creatable/deletable (i.e., config true, which is the 1947 default). These data nodes may be considered sensitive or vulnerable 1948 in some network environments. Write operations (e.g. ) 1949 to these data nodes without proper protection can have a negative 1950 effect on network operations. 1952 The vulnerable "config true" subtrees and data nodes are the 1953 following: 1955 /nd:networks/nd:network/nd:node/coam:location-type/coam:ipv4- 1956 location-type/coam:test-point-ipv4-location-list/coam:test-point- 1957 locations/ 1959 /nd:networks/nd:network/nd:node/coam:location-type/coam:ipv6- 1960 location-type/coam:test-point-ipv6-location-list/coam:test-point- 1961 locations/ 1963 /nd:networks/nd:network/nd:node/coam:location-type/coam:mac-location- 1964 type/coam:test-point-mac-address-location-list/coam:test-point- 1965 locations/ 1966 /nd:networks/nd:network/nd:node/coam:location-type/coam:tunnel- 1967 location-type/coam:test-point-tunnel-address-location-list/coam:test- 1968 point-locations/ 1970 /nd:networks/nd:network/nd:node/coam:location-type/coam:ip-prefix- 1971 location-type/coam:test-point-ip-prefix-location-list/coam:test- 1972 point-locations/ 1974 /nd:networks/nd:network/nd:node/coam:location-type/coam:route- 1975 distinguisher-location-type/coam:test-point-route-dist-location-list/ 1976 coam:test-point-locations/ 1978 /nd:networks/nd:network/nd:node/coam:location-type/coam:group-ip- 1979 address-location-type/coam:test-point-group-ip-address-location-list/ 1980 coam:test-point-locations/ 1982 /nd:networks/nd:network/nd:node/coam:location-type/coam:group-as- 1983 number-location-type/coam:test-point-as-number-location-list/ 1984 coam:test-point-locations/ 1986 /nd:networks/nd:network/nd:node/coam:location-type/coam:group-lsp-id- 1987 location-type/coam:test-point-lsp-id-location-list/coam:test-point- 1988 locations/ 1990 /nd:networks/nd:network/nd:node/coam:location-type/coam:group-system- 1991 id-location-type/coam:test-point-system-info-location-list/coam:test- 1992 point-locations/ 1994 Unauthorized access to any of these lists can adversely affect OAM 1995 management system handling of end-to-end OAM and coordination of OAM 1996 within underlying network layers. This may lead to inconsistent 1997 configuration, reporting, and presentation for the OAM mechanisms 1998 used to manage the network. 2000 7. IANA Considerations 2002 This document registers a URI in the IETF XML registry [RFC3688]. 2003 Following the format in [RFC3688] the following registration is 2004 requested to be made: 2006 URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam 2008 Registrant Contact: The IESG. 2010 XML: N/A, the requested URI is an XML namespace. 2012 This document registers a YANG module in the YANG Module Names 2013 registry [RFC6020]. 2015 name: ietf-connectionless-oam 2017 namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam 2019 prefix: coam 2021 reference: RFC XXXX 2023 8. Acknowlegements 2025 The authors of this document would like to thank Greg Mirsky and 2026 others for their sustainable review and comments, proposals to 2027 improve and stabilize document. 2029 9. References 2031 9.1. Normative References 2033 [I-D.ietf-bfd-yang] 2034 Rahman, R., Zheng, L., Networks, J., Jethanandani, M., and 2035 G. Mirsky, "Yang Data Model for Bidirectional Forwarding 2036 Detection (BFD)", draft-ietf-bfd-yang-05 (work in 2037 progress), March 2017. 2039 [I-D.ietf-i2rs-yang-network-topo] 2040 Clemm, A., Medved, J., Varga, R., Bahadur, N., 2041 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 2042 Topologies", draft-ietf-i2rs-yang-network-topo-12 (work in 2043 progress), March 2017. 2045 [I-D.ietf-lime-yang-connectionless-oam-methods] 2046 Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, 2047 "Retrieval Methods YANG Data Model for Connectionless 2048 Operations, Administration, and Maintenance(OAM) 2049 protocols", draft-ietf-lime-yang-connectionless-oam- 2050 methods-04 (work in progress), June 2017. 2052 [I-D.ietf-lime-yang-oam-model] 2053 Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 2054 for Connection Oriented Operations, Administration, and 2055 Maintenance(OAM) protocols", draft-ietf-lime-yang-oam- 2056 model-10 (work in progress), April 2017. 2058 [I-D.ietf-netmod-schema-mount] 2059 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 2060 ietf-netmod-schema-mount-05 (work in progress), May 2017. 2062 [I-D.ietf-rtgwg-ni-model] 2063 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 2064 "YANG Network Instances", draft-ietf-rtgwg-ni-model-02 2065 (work in progress), March 2017. 2067 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2068 DOI 10.17487/RFC3688, January 2004, 2069 . 2071 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2072 Control Message Protocol (ICMPv6) for the Internet 2073 Protocol Version 6 (IPv6) Specification", RFC 4443, 2074 DOI 10.17487/RFC4443, March 2006, 2075 . 2077 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2078 the Network Configuration Protocol (NETCONF)", RFC 6020, 2079 DOI 10.17487/RFC6020, October 2010, 2080 . 2082 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2083 and A. Bierman, Ed., "Network Configuration Protocol 2084 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2085 . 2087 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2088 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2089 . 2091 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2092 Protocol (NETCONF) Access Control Model", RFC 6536, 2093 DOI 10.17487/RFC6536, March 2012, 2094 . 2096 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2097 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2098 . 2100 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2101 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2102 . 2104 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 2105 September 1981. 2107 9.2. Informative References 2109 [G.8013] "OAM functions and mechanisms for Ethernet based 2110 networks", ITU-T Recommendation G.8013/Y.1731, 2013. 2112 [I-D.ietf-spring-sr-yang] 2113 Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG 2114 Data Model for Segment Routing", draft-ietf-spring-sr- 2115 yang-06 (work in progress), March 2017. 2117 [I-D.zheng-mpls-lsp-ping-yang-cfg] 2118 Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R. 2119 Rahman, "Yang Data Model for LSP-PING", draft-zheng-mpls- 2120 lsp-ping-yang-cfg-04 (work in progress), October 2016. 2122 [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual 2123 Private Network (L2VPN) Operations, Administration, and 2124 Maintenance (OAM) Requirements and Framework", RFC 6136, 2125 DOI 10.17487/RFC6136, March 2011, 2126 . 2128 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 2129 Weingarten, "An Overview of Operations, Administration, 2130 and Maintenance (OAM) Tools", RFC 7276, 2131 DOI 10.17487/RFC7276, June 2014, 2132 . 2134 Authors' Addresses 2136 Deepak Kumar 2137 CISCO Systems 2138 510 McCarthy Blvd 2139 Milpitas, CA 95035 2140 USA 2142 Email: dekumar@cisco.com 2144 Michael Wang 2145 Huawei Technologies,Co.,Ltd 2146 101 Software Avenue, Yuhua District 2147 Nanjing 210012 2148 China 2150 Email: wangzitao@huawei.com 2151 Qin Wu 2152 Huawei 2153 101 Software Avenue, Yuhua District 2154 Nanjing, Jiangsu 210012 2155 China 2157 Email: bill.wu@huawei.com 2159 Reshad Rahman 2160 CISCO Systems 2161 2000 Innovation Drive 2162 KANATA, ONTARIO K2K 3E8 2163 CANADA 2165 Email: rrahman@cisco.com 2167 Srihari Raghavan 2168 CISCO Systems 2169 TRIL INFOPARK SEZ, Ramanujan IT City 2170 NEVILLE BLOCK, 2nd floor, Old Mahabalipuram Road 2171 CHENNAI, TAMIL NADU 600113 2172 INDIA 2174 Email: srihari@cisco.com