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