idnits 2.17.00 (12 Aug 2021) /tmp/idnits40127/draft-ietf-lime-yang-connectionless-oam-16.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 7 instances of too long lines in the document, the longest one being 19 characters in excess of 72. -- 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 == Line 429 has weird spacing: '...y-check boo...' == Line 455 has weird spacing: '...y-check boo...' == Line 475 has weird spacing: '...ocation yan...' == Line 480 has weird spacing: '...y-check boo...' == Line 506 has weird spacing: '...y-check boo...' == (1 more instance...) -- The document date (October 30, 2017) is 1663 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) == Missing Reference: 'RFC5880' is mentioned on line 161, but not defined == Missing Reference: 'RFC1831' is mentioned on line 163, but not defined ** Obsolete undefined reference: RFC 1831 (Obsoleted by RFC 5531) == Missing Reference: 'RFC 4382' is mentioned on line 167, but not defined == Missing Reference: 'RFC 4656' is mentioned on line 169, but not defined == Missing Reference: 'RFC 5357' is mentioned on line 171, but not defined == Unused Reference: 'I-D.ietf-rtgwg-ni-model' is defined on line 2487, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 2517, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 2535, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 2539, but no explicit reference was found in the text == Unused Reference: 'RFC8029' is defined on line 2550, but no explicit reference was found in the text == Outdated reference: draft-ietf-i2rs-yang-network-topo has been published as RFC 8345 == Outdated reference: draft-ietf-rtgwg-ni-model has been published as RFC 8529 == Outdated reference: draft-ietf-rtgwg-routing-types has been published as RFC 8294 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: draft-ietf-bfd-yang has been published as RFC 9127 == Outdated reference: draft-ietf-lime-yang-connection-oriented-oam-model has been published as RFC 8531 == 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: A later version (-10) exists of draft-zheng-mpls-lsp-ping-yang-cfg-06 Summary: 6 errors (**), 0 flaws (~~), 25 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: May 3, 2018 Q. Wu 6 Huawei 7 R. Rahman 8 S. Raghavan 9 Cisco 10 October 30, 2017 12 Generic YANG Data Model for the Management of Operations, 13 Administration, and Maintenance (OAM) Protocols that use Connectionless 14 Communications 15 draft-ietf-lime-yang-connectionless-oam-16 17 Abstract 19 This document presents a base YANG Data model for Operations 20 Administration, and Maintenance(OAM) protocols that use 21 Connectionless Communications. The data model is defined using the 22 YANG in RFC7950 data modeling language. It provides a technology- 23 independent abstraction of key OAM constructs for OAM protocols that 24 use connectionless communication. The base model presented here can 25 be extended to include technology specific details. This is leading 26 to uniformity between OAM protocols and support both nested OAM 27 workflows (i.e., performing OAM functions at different or same levels 28 through a unified interface) and interacting OAM workflows (i.e., 29 performing OAM functions at same levels through a unified interface). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 3, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions used in this document . . . . . . . . . . . . . . 3 67 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Overview of the Connectionless OAM Model . . . . . . . . . . 5 70 3.1. TP Address . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3. OAM neighboring test points . . . . . . . . . . . . . . . 7 73 3.4. Test Point Locations Information . . . . . . . . . . . . 8 74 3.5. Test Point Locations . . . . . . . . . . . . . . . . . . 8 75 3.6. Path Discovery Data . . . . . . . . . . . . . . . . . . . 9 76 3.7. Continuity Check Data . . . . . . . . . . . . . . . . . . 9 77 3.8. OAM data hierarchy . . . . . . . . . . . . . . . . . . . 9 78 4. LIME Time Types YANG Module . . . . . . . . . . . . . . . . . 12 79 5. Connectionless OAM YANG Module . . . . . . . . . . . . . . . 14 80 6. Connectionless model applicability . . . . . . . . . . . . . 42 81 6.1. BFD Extension . . . . . . . . . . . . . . . . . . . . . . 43 82 6.1.1. Augment Method . . . . . . . . . . . . . . . . . . . 43 83 6.1.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 46 84 6.2. LSP ping extension . . . . . . . . . . . . . . . . . . . 48 85 6.2.1. Augment Method . . . . . . . . . . . . . . . . . . . 48 86 6.2.2. Schema Mount . . . . . . . . . . . . . . . . . . . . 49 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 89 9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 53 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 53 92 10.2. Informative References . . . . . . . . . . . . . . . . . 55 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 95 1. Introduction 97 Operations, Administration, and Maintenance (OAM) are important 98 networking functions that allow operators to: 100 1. Monitor networks communication (Reachability Verification, 101 Continuity Check). 103 2. Troubleshoot failures (Fault verification and localization). 105 3. Monitor Performance 107 An overview of OAM tools is presented at [RFC7276]. 109 Ping and Traceroute [RFC792], [RFC4443] are well-known fault 110 verification and isolation tools, respectively, for IP networks. 111 Over the years, different technologies have developed similar tools 112 for similar purposes. 114 The different OAM tools may support connection-oriented technologies 115 or connectionless technologies. In connection-oriented technologies, 116 a connection is established prior to the transmission of data. After 117 the connection is established, no additional control information such 118 as signaling or operations and maintenance information is required to 119 transmit the data. In connectionless technologies, data is typically 120 sent between end points without prior arrangement, but control 121 information is required to identify destination.[G.800][RFC7276]. 122 Note that the YANG Data model for OAM protcols using connection- 123 oriented communications is defined in 124 [I-D.ietf-lime-yang-connection-oriented-oam-model]. 126 This document defines a base YANG Data model for OAM protocols that 127 use Connectionless Communications. The data model is defined using 128 the YANG [RFC7950] data modeling language. This generic YANG model 129 for connectionless OAM only includes configuration data and state 130 data. It can be used in conjunction with data retrieval method model 131 described in [I-D.ietf-lime-yang-connectionless-oam-methods], which 132 focuses on data retrieval procedures such as RPC. However it also 133 can be used independently of this data retrieval method model. 135 2. Conventions used in this document 137 The following terms are defined in [RFC6241] and are not redefined 138 here: 140 o client 142 o configuration data 143 o server 145 o state data 147 The following terms are defined in [RFC7950] and are not redefined 148 here: 150 o augment 152 o data model 154 o data node 156 The terminology for describing YANG data models is found in 157 [RFC7950]. 159 2.1. Abbreviations 161 BFD - Bidirectional Forwarding Detection [RFC5880]. 163 RPC - A Remote Procedure Call [RFC1831]. 165 DSCP - Differentiated Services Code Point. 167 VRF - Virtual Routing and Forwarding (VRF) [RFC 4382]. 169 OWAMP - One-Way Active Measurement Protocol [RFC 4656]. 171 TWAMP - Two-Way Active Measurement Protocol (TWAMP) [RFC 5357]. 173 AS - Autonomous System. 175 LSP - Label Switched Path. 177 TE - Traffic Engineering. 179 MPLS - Multiprotocol Label Switching. 181 NI - Network Instance. 183 PTP - Precision Time Protocol [IEEE.1588]. 185 NTP - Network Time Protocol [RFC5905]. 187 2.2. Terminology 189 MAC address- Address for data link layer interface. 191 TP - Test Point. Test point is a functional entity that is defined 192 at a node in the network and can initiate and/or react to OAM 193 diagnostic test. This document focuses on the data-plane 194 functionality of TPs, while TPs interact with the control plane and 195 with the management plane as well. 197 RPC operation - A specific Remote Procedure Call. 199 CC - Continuity Check.[RFC7276], Continuity Checks are used to verify 200 that a destination is reachable and therefore also referred to as 201 reachability verification. 203 3. Overview of the Connectionless OAM Model 205 The YANG data model for OAM protocols that use Connectionless 206 Communications has been split into two modules: 208 o The module ietf-lime-common-types.yang provides common definitions 209 such as Time-specific data types and Timestamp specific data 210 types. 212 o The module ietf-connectionless-oam.yang defines technology- 213 independent abstraction of key OAM constructs for OAM protocols 214 that use Connectionless communication. 216 The ietf-connectionless-oam module augments the "/networks/network/ 217 node" path defined in the ietf- network module 218 [I-D.ietf-i2rs-yang-network-topo] with 'test-point-locations' 219 grouping defined in Section 3.5. The network node in 220 "/networks/network/node" path are used to describe the network 221 hierarchies and the inventory of nodes contained in a network. 223 Under the 'test-point-locations' grouping, each test point location 224 is chosen based on 'tp-location-type' leaf which when chosen, leads 225 to a container that includes a list of 'test-point-locations'. 227 Each 'test-point-locations' list includes a 'test-point-location- 228 info' grouping. The 'test-point-location-info' grouping includes: 230 o 'tp-technology' grouping, 232 o 'tp-tools' grouping, 234 o and 'connectionless-oam-tps' grouping. 236 The groupings of 'tp-address' and 'tp-address-ni' are kept out of 237 'test- point-location-info' grouping to make it addressing agnostic 238 and allow varied composition. Depending upon the choice of the 'tp- 239 location-type' (determined by the 'tp-address-ni'), the containers 240 differ in its composition of 'test-point-locations' while the 'test- 241 point-location-info', is a common aspect of every 'test-point- 242 locations'. 244 The 'tp-address-ni' grouping is used to describe the corresponding 245 network instance. The 'tp-technology' grouping indicate OAM 246 technology details. The 'connectionless-oam-tps' grouping is used to 247 describe the relationship of one test point with other test points. 248 The 'tp-tools' grouping describe the OAM tools supported. 250 In addition, at the top of the model, there is an 'cc-oper-data' 251 container for session statistics. Grouping is also defined for 252 common session statistics and these are only applicable for proactive 253 OAM sessions. 255 3.1. TP Address 257 With connectionless OAM protocols, the TP address can be one of the 258 following types: 260 o MAC address [RFC6136] at link layer for TPs 262 o IPv4 or IPv6 address at IP layer for TPs 264 o TP-attribute identifying a TP associated with an application layer 265 function 267 o Router-id to represent the device or node, which is commonly used 268 to identify nodes in routing and other control plane 269 protocols.[I-D.ietf-rtgwg-routing-types] 271 To define a forwarding treatment of a test packet, the 'tp-address' 272 grouping needs to be associated with additional parameters, e.g., 273 DSCP for IP or EXP (renamed to Traffic Classic in [RFC5462]) for 274 MPLS. In generic connectionless OAM YANG model, these parameters are 275 not explicitly configured. The model user can add corresponding 276 parameters according to their requirements. 278 3.2. Tools 280 The different OAM tools may be used in one of two basic types of 281 activation: proactive and on-demand. The proactive OAM refers to OAM 282 actions which are carried out continuously to permit proactive 283 reporting of fault. The proactive OAM method requires persistent 284 configuration. The on-demand OAM refers to OAM actions which are 285 initiated via manual intervention for a limited time to carry out 286 diagnostics. The on-demand OAM method requires only transient 287 configuration.[RFC7276] [G.8013]. In connectionless OAM, 'session- 288 type' grouping is defined to indicate which kind of activation will 289 be used by the current session. 291 In connectionless OAM, the tools attribute is used to describe a 292 toolset for fault detection and isolation. And it can serve as a 293 constraint condition when the base model be extended to specific OAM 294 technology. For example, to fulfill the ICMP PING configuration, the 295 "../coam:continuity-check" leaf should be set to "true", and then the 296 lime base model should be augmented with ICMP PING specific details. 298 3.3. OAM neighboring test points 300 As typical network communication stacks have a multi-layer 301 architecture, the set of associated OAM protocols may similarly have 302 a multi-layer structure; each communication layer in the stack may 303 have its own OAM protocol [RFC7276] that may also be linked to a 304 specific administrative domain. Management of these OAM protocols 305 will necessitate associated test points in the nodes accessible by 306 appropriate management domains. Accordingly, a given network 307 interface may present several test points. 309 OAM neighboring test points are referred to a list of neighboring 310 test points in adjacent layers up and down the stack for the same 311 interface that are related to the current test point. This allows 312 users to easily navigate between related neighboring layers to 313 efficiently troubleshoot a defect. In this model, the 'position' 314 leaf defines the relative position of the neighboring test point 315 corresponding to the current test point, and is provided to allow 316 correlation of faults at different locations. If there is one 317 neighboring test point placed before the current test point, the 318 'position' leaf is set to -1. If there is one neighboring test point 319 placed after the current test point, the 'position' leaf is set to 1. 320 If there is no neighboring test point placed before or after the 321 current test point, the 'position' leaf is set to 0. 323 list oam-neighboring-tps { 324 key "index"; 325 leaf index { 326 type uint16 { 327 range "0..65535"; 328 } 329 description 330 "Index of a list of neighboring test points 331 in adjacent layers up and down the stack for 332 the same interface that are related to the 333 current test point."; 334 } 335 leaf position { 336 type int8 { 337 range "-1..1"; 338 } 339 description 340 "The relative position 341 of neighboring test point 342 corresponding to the current 343 test point"; 344 } 346 description 347 "List of related neighboring test points in adjacent 348 layers up and down the stack for the same interface 349 that are related to the current test point."; 351 } 353 3.4. Test Point Locations Information 355 This is a generic grouping for Test Point Locations Information 356 (i.e., test-point-location-info grouping). It Provide details of 357 Test Point Location using 'tp-technology','tp-tools' grouping, 'oam- 358 neighboring-tps' grouping defined above. 360 3.5. Test Point Locations 362 This is a generic grouping for Test Point Locations. 'tp-location- 363 type 'leaf is used to define locations types, for example 'ipv4- 364 location-type', 'ipv6-location-type', etc. Container is defined 365 under each location type containing list keyed to test point address, 366 Test Point Location Information defined in section above, and network 367 instance name(e.g., VRF instance name) if required. 369 3.6. Path Discovery Data 371 This is a generic grouping for path discovery data model that can be 372 retrieved by any data retrieval methods including RPC operations. 373 Path discovery data output from methods, includes 'src-test-point' 374 container, 'dst-test-point' container, 'sequence-number'leaf, 'hop- 375 cnt'leaf, session statistics of various kinds, path verification and 376 path trace related information. Path discovery includes data to be 377 retrieved on a 'per-hop' basis via a list of 'path-trace-info- 378 list'list which includes information like 'timestamp'grouping, ' 379 ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'. The 380 path discovery data model is made generic enough to allow different 381 methods of data retrieval. None of the fields are made mandatory for 382 that reason. Noted that the retrieval methods are defined in 383 [I-D.ietf-lime-yang-connectionless-oam-methods]. 385 3.7. Continuity Check Data 387 This is a generic grouping for continuity check data model that can 388 be retrieved by any data retrieval methods including RPC operations. 389 Continuity check data output from methods, includes 'src-test- 390 point'container, 'dst-test-point'container, 'sequence-number' leaf, 391 'hop-cnt'leaf and session statistics of various kinds. The 392 continuity check data model is made generic enough to allow different 393 methods of data retrieval. None of the fields are made mandatory for 394 that reason. Noted that the retrieval methods are defined in 395 [I-D.ietf-lime-yang-connectionless-oam-methods]. 397 3.8. OAM data hierarchy 399 The complete data hierarchy related to the OAM YANG model is 400 presented below. 402 module: ietf-connectionless-oam 403 +--ro cc-session-statistics-data {continuity-check}? 404 +--ro cc-session-statistics* [type] 405 +--ro type identityref 406 +--ro cc-ipv4-sessions-statistics 407 | +--ro cc-session-statistics 408 | +--ro session-count? uint32 409 | +--ro session-up-count? uint32 410 | +--ro session-down-count? uint32 411 | +--ro session-admin-down-count? uint32 412 +--ro cc-ipv6-sessions-statistics 413 +--ro cc-session-statistics 414 +--ro session-count? uint32 415 +--ro session-up-count? uint32 416 +--ro session-down-count? uint32 417 +--ro session-admin-down-count? uint32 418 augment /nd:networks/nd:network/nd:node: 419 +--rw tp-location-type? identityref 420 +--rw ipv4-location-type 421 | +--rw test-point-ipv4-location-list 422 | +--rw test-point-locations* [ipv4-location ni] 423 | +--rw ipv4-location inet:ipv4-address 424 | +--rw ni routing-instance-ref 425 | +--rw (technology)? 426 | | +--:(technology-null) 427 | | +--rw tech-null? empty 428 | +--rw tp-tools 429 | | +--rw continuity-check boolean 430 | | +--rw path-discovery boolean 431 | +--rw root? 432 | +--rw oam-neighboring-tps* [index] 433 | +--rw index uint16 434 | +--rw position? int8 435 | +--rw (tp-location)? 436 | +--:(mac-address) 437 | | +--rw mac-address-location? yang:mac-address 438 | +--:(ipv4-address) 439 | | +--rw ipv4-address-location? inet:ipv4-address 440 | +--:(ipv6-address) 441 | | +--rw ipv6-address-location? inet:ipv6-address 442 | +--:(as-number) 443 | | +--rw as-number-location? inet:as-number 444 | +--:(router-id) 445 | +--rw router-id-location? rt:router-id 446 +--rw ipv6-location-type 447 | +--rw test-point-ipv6-location-list 448 | +--rw test-point-locations* [ipv6-location ni] 449 | +--rw ipv6-location inet:ipv6-address 450 | +--rw ni routing-instance-ref 451 | +--rw (technology)? 452 | | +--:(technology-null) 453 | | +--rw tech-null? empty 454 | +--rw tp-tools 455 | | +--rw continuity-check boolean 456 | | +--rw path-discovery boolean 457 | +--rw root? 458 | +--rw oam-neighboring-tps* [index] 459 | +--rw index uint16 460 | +--rw position? int8 461 | +--rw (tp-location)? 462 | +--:(mac-address) 463 | | +--rw mac-address-location? yang:mac-address 464 | +--:(ipv4-address) 465 | | +--rw ipv4-address-location? inet:ipv4-address 466 | +--:(ipv6-address) 467 | | +--rw ipv6-address-location? inet:ipv6-address 468 | +--:(as-number) 469 | | +--rw as-number-location? inet:as-number 470 | +--:(router-id) 471 | +--rw router-id-location? rt:router-id 472 +--rw mac-location-type 473 | +--rw test-point-mac-address-location-list 474 | +--rw test-point-locations* [mac-address-location] 475 | +--rw mac-address-location yang:mac-address 476 | +--rw (technology)? 477 | | +--:(technology-null) 478 | | +--rw tech-null? empty 479 | +--rw tp-tools 480 | | +--rw continuity-check boolean 481 | | +--rw path-discovery boolean 482 | +--rw root? 483 | +--rw oam-neighboring-tps* [index] 484 | +--rw index uint16 485 | +--rw position? int8 486 | +--rw (tp-location)? 487 | +--:(mac-address) 488 | | +--rw mac-address-location? yang:mac-address 489 | +--:(ipv4-address) 490 | | +--rw ipv4-address-location? inet:ipv4-address 491 | +--:(ipv6-address) 492 | | +--rw ipv6-address-location? inet:ipv6-address 493 | +--:(as-number) 494 | | +--rw as-number-location? inet:as-number 495 | +--:(router-id) 496 | +--rw router-id-location? rt:router-id 497 +--rw group-as-number-location-type 498 | +--rw test-point-as-number-location-list 499 | +--rw test-point-locations* [as-number-location] 500 | +--rw as-number-location inet:as-number 501 | +--rw ni? routing-instance-ref 502 | +--rw (technology)? 503 | | +--:(technology-null) 504 | | +--rw tech-null? empty 505 | +--rw tp-tools 506 | | +--rw continuity-check boolean 507 | | +--rw path-discovery boolean 508 | +--rw root? 509 | +--rw oam-neighboring-tps* [index] 510 | +--rw index uint16 511 | +--rw position? int8 512 | +--rw (tp-location)? 513 | +--:(mac-address) 514 | | +--rw mac-address-location? yang:mac-address 515 | +--:(ipv4-address) 516 | | +--rw ipv4-address-location? inet:ipv4-address 517 | +--:(ipv6-address) 518 | | +--rw ipv6-address-location? inet:ipv6-address 519 | +--:(as-number) 520 | | +--rw as-number-location? inet:as-number 521 | +--:(router-id) 522 | +--rw router-id-location? rt:router-id 523 +--rw group-router-id-location-type 524 +--rw test-point-system-info-location-list 525 +--rw test-point-locations* [router-id-location] 526 +--rw router-id-location rt:router-id 527 +--rw ni? routing-instance-ref 528 +--rw (technology)? 529 | +--:(technology-null) 530 | +--rw tech-null? empty 531 +--rw tp-tools 532 | +--rw continuity-check boolean 533 | +--rw path-discovery boolean 534 +--rw root? 535 +--rw oam-neighboring-tps* [index] 536 +--rw index uint16 537 +--rw position? int8 538 +--rw (tp-location)? 539 +--:(mac-address) 540 | +--rw mac-address-location? yang:mac-address 541 +--:(ipv4-address) 542 | +--rw ipv4-address-location? inet:ipv4-address 543 +--:(ipv6-address) 544 | +--rw ipv6-address-location? inet:ipv6-address 545 +--:(as-number) 546 | +--rw as-number-location? inet:as-number 547 +--:(router-id) 548 +--rw router-id-location? rt:router-id 550 4. LIME Time Types YANG Module 552 file "ietf-lime-time-types@2017-09-06.yang" 554 module ietf-lime-time-types { 555 yang-version 1.1; 556 namespace "urn:ietf:params:xml:ns:yang:ietf-lime-time-types"; 557 prefix "lime"; 559 organization 560 "IETF Layer Independent OAM Management(LIME) 561 Working Group"; 563 contact 564 "WG Web: 565 WG List: 567 Editor: Qin Wu 568 "; 570 description 571 "This module provides time related definitions used by the data 572 models written for Layer Independent OAM Management(LIME). 573 This module defines identities but no schema tree elements."; 575 revision "2017-09-06" { 576 description 577 "Initial version"; 578 reference 579 "RFC xxxx: A YANG Data Model for OAM Protocols that use Connectionless 580 Communications"; 581 } 583 /*** Collection of common types related to time ***/ 584 /*** Time unit identity ***/ 585 identity time-unit-type { 586 description 587 "Time unit type"; 588 } 589 identity hours { 590 base time-unit-type; 591 description 592 "Time unit in Hours"; 593 } 594 identity minutes { 595 base time-unit-type; 596 description 597 "Time unit in Minutes"; 598 } 599 identity seconds { 600 base time-unit-type; 601 description 602 "Time unit in Seconds"; 603 } 604 identity milliseconds { 605 base time-unit-type; 606 description 607 "Time unit in Milliseconds"; 608 } 609 identity microseconds { 610 base time-unit-type; 611 description 612 "Time unit in Microseconds"; 613 } 614 identity nanoseconds { 615 base time-unit-type; 616 description 617 "Time unit in Nanoseconds"; 618 } 619 /*** Timestamp format Identity ***/ 620 identity timestamp-type { 621 description 622 "Base identity for Timestamp Type."; 623 } 624 identity truncated-ptp { 625 base timestamp-type; 626 description 627 "Identity for 64bit short format PTP timestamp."; 628 } 629 identity truncated-ntp { 630 base timestamp-type; 631 description 632 "Identity for 32bit short format NTP timestamp."; 633 } 634 identity ntp64 { 635 base timestamp-type; 636 description 637 "Identity for 64bit NTP timestamp."; 638 } 639 identity icmp { 640 base timestamp-type; 641 description 642 "Identity for 32bit ICMP timestamp."; 643 } 644 } 646 648 5. Connectionless OAM YANG Module 650 file "ietf-connectionless-oam@2017-09-06.yang" 652 module ietf-connectionless-oam { 653 yang-version 1.1; 654 namespace "urn:ietf:params:xml:ns:yang:ietf-connectionless-oam"; 655 prefix cl-oam; 656 import ietf-yang-schema-mount { 657 prefix yangmnt; 658 } 659 import ietf-network { 660 prefix nd; 661 } 662 import ietf-yang-types { 663 prefix yang; 664 } 665 import ietf-interfaces { 666 prefix if; 667 } 668 import ietf-inet-types { 669 prefix inet; 670 } 671 import ietf-network-instance { 672 prefix ni; 673 } 674 import ietf-routing-types { 675 prefix rt; 676 } 677 import ietf-lime-time-types { 678 prefix lime; 679 } 680 organization 681 "IETF LIME Working Group"; 682 contact 683 "Deepak Kumar dekumar@cisco.com 684 Qin Wu bill.wu@huawei.com 685 S Raghavan srihari@cisco.com 686 Zitao Wang wangzitao@huawei.com 687 R Rahman rrahman@cisco.com"; 688 description 689 "This YANG module defines the generic configuration, 690 data model, and statistics for OAM protocols using 691 connectionless communications, described in a 692 protocol independent manner.It is assumed that each 693 protocol maps corresponding abstracts to its native 694 format. Each protocol mayextend the YANG model defined 695 here to include protocol specific extensions."; 696 revision 2017-09-06 { 697 description 698 " Base model for Connectionless 699 Operations, Administration, 700 and Maintenance(OAM) "; 701 reference 702 " RFC XXXX: Connectionless 703 Operations, Administration, and 704 Maintenance(OAM)YANG Data Model"; 706 } 707 feature connectionless { 708 description 709 "This feature indicates that OAM solution is connectionless."; 710 } 711 feature continuity-check { 712 description 713 "This feature indicates that the server supports 714 executing continuity check OAM command and 715 returning a response. Servers that do not advertise 716 this feature will not support executing 717 continuity check command or RPC operation model for 718 continuity check command."; 719 } 720 feature path-discovery { 721 description 722 "This feature indicates that the server supports 723 executing path discovery OAM command and 724 returning a response. Servers that do not advertise 725 this feature will not support executing 726 path discovery command or RPC operation model for 727 path discovery command."; 728 } 729 feature ptp-long-format { 730 description 731 "This feature indicates that timestamp is PTP long format."; 732 } 733 feature ntp-short-format { 734 description 735 "This feature indicates that timestamp is NTP short format."; 736 } 737 feature icmp-timestamp { 738 description 739 "This feature indicates that timestamp is ICMP timestamp."; 740 } 741 identity traffic-type { 742 description 743 "This is base identity of traffic type 744 which include IPv4 and IPv6,etc."; 745 } 746 identity ipv4 { 747 base traffic-type; 748 description 749 "identity for IPv4 traffic type."; 750 } 751 identity ipv6 { 752 base traffic-type; 753 description 754 "identity for IPv4 traffic type."; 755 } 756 identity address-attribute-types { 757 description 758 "This is base identity of address 759 attribute types which are Generic 760 IPv4/IPv6 Prefix,BGP Labeled 761 IPv4/IPv6 Prefix,Tunnel ID, 762 PW ID, vpls VE ID, etc.(See RFC8029 763 for details.)"; 764 } 765 typedef address-attribute-type { 766 type identityref { 767 base address-attribute-types; 768 } 769 description 770 "Target address attribute type."; 771 } 772 typedef percentage { 773 type decimal64 { 774 fraction-digits 5; 775 range "0..100"; 776 } 777 description "Percentage"; 778 } 779 typedef routing-instance-ref { 780 type leafref { 781 path "/ni:network-instances/ni:network-instance/ni:name"; 782 } 783 description 784 "This type is used for leafs that reference a routing instance 785 configuration."; 786 } 787 grouping cc-session-statistics { 788 description 789 "Grouping for session statistics."; 790 container cc-session-statistics { 791 description 792 "cc session counters"; 793 leaf session-count { 794 type uint32; 795 default "0"; 796 description 797 "Number of Continuity Check sessions. 798 A value of zero indicates that no session 799 count is sent."; 800 } 801 leaf session-up-count { 802 type uint32; 803 default "0"; 804 description 805 "Number of sessions which are up. 806 A value of zero indicates that no up 807 session count is sent."; 808 } 809 leaf session-down-count { 810 type uint32; 811 default "0"; 812 description 813 "Number of sessions which are down. 814 A value of zero indicates that no down 815 session count is sent."; 816 } 817 leaf session-admin-down-count { 818 type uint32; 819 default "0"; 820 description 821 "Number of sessions which are admin-down. 822 A value of zero indicates that no admin 823 down session count is sent."; 824 } 825 } 826 } 827 grouping session-packet-statistics { 828 description 829 "Grouping for per session packet statistics"; 830 container session-packet-statistics { 831 description 832 "Per session packet statistics."; 834 leaf rx-packet-count { 835 type uint32{ 836 range "0..4294967295"; 837 } 838 default "0"; 839 description 840 "Total number of received OAM packet count. 841 The value of count will be set to zero (0) 842 on creation and will thereafter increase 843 monotonically until it reaches a maximum value 844 of 2^32-1 (4294967295 decimal), when it wraps 845 around and starts increasing again from zero."; 846 } 847 leaf tx-packet-count { 848 type uint32{ 849 range "0..4294967295"; 850 } 851 default "0"; 852 description 853 "Total number of transmitted OAM packet count. 854 The value of count will be set to zero (0) 855 on creation and will thereafter increase 856 monotonically until it reaches a maximum value 857 of 2^32-1 (4294967295 decimal), when it wraps 858 around and starts increasing again from zero."; 859 } 860 leaf rx-bad-packet { 861 type uint32 { 862 range "0..4294967295"; 863 } 864 default "0"; 865 description 866 "Total number of received bad OAM packet. 867 The value of count will be set to zero (0) 868 on creation and will thereafter increase 869 monotonically until it reaches a maximum value 870 of 2^32-1 (4294967295 decimal), when it wraps 871 around and starts increasing again from zero."; 872 } 873 leaf tx-packet-failed { 874 type uint32 { 875 range "0..4294967295"; 876 } 877 default "0"; 878 description 879 "Total number of failed sending OAM packet. 880 The value of count will be set to zero (0) 881 on creation and will thereafter increase 882 monotonically until it reaches a maximum value 883 of 2^32-1 (4294967295 decimal), when it wraps 884 around and starts increasing again from zero."; 885 } 886 } 887 } 888 grouping cc-per-session-statistics { 889 description 890 "Grouping for per session statistics"; 891 container cc-per-session-statistics { 892 description 893 "per session statistics."; 895 leaf create-time { 896 type yang:date-and-time; 897 description 898 "Time and date when session is created."; 899 } 900 leaf last-down-time { 901 type yang:date-and-time; 902 description 903 "Time and date last time session is down."; 904 } 905 leaf last-up-time { 906 type yang:date-and-time; 907 description 908 "Time and date last time session is up."; 909 } 910 leaf down-count { 911 type uint32 { 912 range "0..4294967295"; 913 } 914 default "0"; 915 description 916 "Total Continuity Check sessions down count. 917 The value of count will be set to zero (0) 918 on creation and will thereafter increase 919 monotonically until it reaches a maximum value 920 of 2^32-1 (4294967295 decimal), when it wraps 921 around and starts increasing again from zero."; 922 } 923 leaf admin-down-count { 924 type uint32 { 925 range "0..4294967295"; 926 } 927 default "0"; 928 description 929 "Total Continuity Check sessions admin down count. 930 The value of count will be set to zero (0) 931 on creation and will thereafter increase 932 monotonically until it reaches a maximum value 933 of 2^32-1 (4294967295 decimal), when it wraps 934 around and starts increasing again from zero."; 935 } 936 uses session-packet-statistics; 937 } 938 } 939 grouping session-error-statistics { 940 description 941 "Grouping for per session error statistics"; 942 container session-error-statistics { 943 description 944 "Per session error statistics."; 945 leaf packet-loss-count { 946 type uint32 { 947 range "0..4294967295"; 948 } 949 default "0"; 950 description 951 "Total received packet drops count. 952 The value of count will be set to zero (0) 953 on creation and will thereafter increase 954 monotonically until it reaches a maximum value 955 of 2^32-1 (4294967295 decimal), when it wraps 956 around and starts increasing again from zero."; 957 } 958 leaf loss-ratio{ 959 type percentage; 960 description 961 "Loss ratio of the packets. Express as percentage 962 of packets lost with respect to packets sent."; 963 } 964 leaf packet-reorder-count { 965 type uint32 { 966 range "0..4294967295"; 967 } 968 default "0"; 969 description 970 "Total received packet reordered count. 971 The value of count will be set to zero (0) 972 on creation and will thereafter increase 973 monotonically until it reaches a maximum value 974 of 2^32-1 (4294967295 decimal), when it wraps 975 around and starts increasing again from zero."; 976 } 977 leaf packets-out-of-seq-count { 978 type uint32 { 979 range "0..4294967295"; 980 } 981 description 982 "Total received out of sequence count. 983 The value of count will be set to zero (0) 984 on creation and will thereafter increase 985 monotonically until it reaches a maximum value 986 of 2^32-1 (4294967295 decimal), when it wraps 987 around and starts increasing again from zero.."; 988 } 989 leaf packets-dup-count { 990 type uint32 { 991 range "0..4294967295"; 992 } 993 description 994 "Total received packet duplicates count. 995 The value of count will be set to zero (0) 996 on creation and will thereafter increase 997 monotonically until it reaches a maximum value 998 of 2^32-1 (4294967295 decimal), when it wraps 999 around and starts increasing again from zero."; 1000 } 1001 } 1002 } 1003 grouping session-delay-statistics { 1004 description 1005 "Grouping for per session delay statistics"; 1006 container session-delay-statistics { 1007 description 1008 "Session delay summarised information.By default, 1009 one way measurement protocol (e.g., OWAMP)is used 1010 to measure delay. When two way measurement protocol 1011 (e.g., TWAMP) is used instead, it can be indicated 1012 using and protocol-id defined in RPC operation of 1013 draft-ietf-lime-yang-connectionless-oam-methods,i.e., 1014 set protocol-id as OWAMP. Note that only one measurement 1015 protocol for delay is specified for interoperability reason."; 1016 leaf time-unit-value { 1017 type identityref { 1018 base lime:time-unit-type; 1019 } 1020 default lime:milliseconds; 1021 description 1022 "Time units among choice of s,ms,ns etc."; 1023 } 1024 leaf min-delay-value { 1025 type uint32; 1026 description 1027 "Minimum delay value observed."; 1028 } 1029 leaf max-delay-value { 1030 type uint32; 1031 description 1032 "Maximum delay value observed."; 1033 } 1034 leaf average-delay-value { 1035 type uint32; 1036 description 1037 "Average delay value observed."; 1038 } 1039 } 1040 } 1041 grouping session-jitter-statistics { 1042 description 1043 "Grouping for per session jitter statistics"; 1044 container session-jitter-statistics { 1045 description 1046 "Session jitter summarised information. By default, 1047 jitter is measured using IP Packet Delay Variation 1048 (IPDV) as defined in RFC3393. When the other measurement 1049 method is used instead(e.g., Packet Delay Variation used in 1050 Y.1540, it can be indicated using protocol-id-meta-data 1051 defined in RPC operation of 1052 draft-ietf-lime-yang-connectionless-oam-methods. Note that 1053 only one measurement method for jitter is specified 1054 for interoperability reason."; 1055 leaf unit-value { 1056 type identityref { 1057 base lime:time-unit-type; 1058 } 1059 default lime:milliseconds; 1060 description 1061 "Time units among choice of s,ms,ns etc."; 1062 } 1063 leaf min-jitter-value { 1064 type uint32; 1065 description 1066 "Minimum jitter value observed."; 1067 } 1068 leaf max-jitter-value { 1069 type uint32; 1070 description 1071 "Maximum jitter value observed."; 1072 } 1073 leaf average-jitter-value { 1074 type uint32; 1075 description 1076 "Average jitter value observed."; 1077 } 1078 } 1079 } 1080 grouping session-path-verification-statistics { 1081 description 1082 "Grouping for per session path verification statistics"; 1083 container session-path-verification-statistics { 1084 description 1085 "OAM per session path verification statistics."; 1086 leaf verified-count { 1087 type uint32 { 1088 range "0..4294967295"; 1089 } 1090 description 1091 "Total number of OAM packets that 1092 went through a path as intended. 1093 The value of count will be set to zero (0) 1094 on creation and will thereafter increase 1095 monotonically until it reaches a maximum value 1096 of 2^32-1 (4294967295 decimal), when it wraps 1097 around and starts increasing again from zero."; 1098 } 1099 leaf failed-count { 1100 type uint32 { 1101 range "0..4294967295"; 1102 } 1103 description 1104 "Total number of OAM packets that 1105 went through an unintended path. 1106 The value of count will be set to zero (0) 1107 on creation and will thereafter increase 1108 monotonically until it reaches a maximum value 1109 of 2^32-1 (4294967295 decimal), when it wraps 1110 around and starts increasing again from zero."; 1111 } 1112 } 1113 } 1114 grouping session-type { 1115 description 1116 "This object indicates which kind 1117 of activation will be used by the current 1118 session."; 1119 leaf session-type { 1120 type enumeration { 1121 enum "proactive" { 1122 description 1123 "The current session is proactive session."; 1124 } 1125 enum "on-demand" { 1126 description 1127 "The current session is on-demand session."; 1128 } 1129 } 1130 default "on-demand"; 1131 description 1132 "Indicate which kind of activation will be used 1133 by the current session"; 1134 } 1135 } 1136 identity tp-address-technology-type { 1137 description 1138 "Test point address type"; 1139 } 1140 identity mac-address-type { 1141 base tp-address-technology-type; 1142 description 1143 "MAC address type"; 1144 } 1145 identity ipv4-address-type { 1146 base tp-address-technology-type; 1147 description 1148 "IPv4 address type"; 1149 } 1150 identity ipv6-address-type { 1151 base tp-address-technology-type; 1152 description 1153 "IPv6 address type"; 1154 } 1155 identity tp-attribute-type { 1156 base tp-address-technology-type; 1157 description 1159 "Test point attribute type"; 1160 } 1161 identity router-id-address-type { 1162 base tp-address-technology-type; 1163 description 1164 "System id address type"; 1165 } 1166 identity as-number-address-type { 1167 base tp-address-technology-type; 1168 description 1169 "AS number address type"; 1170 } 1171 identity route-distinguisher-address-type { 1172 base tp-address-technology-type; 1173 description 1174 "Route Distinguisher address type"; 1175 } 1176 grouping tp-address { 1177 leaf tp-location-type { 1178 type identityref { 1179 base tp-address-technology-type; 1180 } 1181 mandatory true; 1182 description 1183 "Test point address type."; 1184 } 1185 container mac-address { 1186 when "derived-from-or-self(../tp-location-type,"+ 1187 "'cl-oam:mac-address-type')" { 1188 description 1189 "MAC address type"; 1190 } 1191 leaf mac-address { 1192 type yang:mac-address; 1193 mandatory true; 1194 description 1195 "MAC Address"; 1196 } 1197 description 1198 "MAC Address based TP Addressing."; 1199 } 1200 container ipv4-address { 1201 when "derived-from-or-self(../tp-location-type,"+ 1202 "'cl-oam:ipv4-address-type')" { 1203 description 1204 "IPv4 address type"; 1205 } 1206 leaf ipv4-address { 1207 type inet:ipv4-address; 1208 mandatory true; 1210 description 1211 "IPv4 Address"; 1212 } 1213 description 1214 "IP Address based TP Addressing."; 1215 } 1216 container ipv6-address { 1217 when "derived-from-or-self(../tp-location-type,"+ 1218 "'cl-oam:ipv6-address-type')" { 1219 description 1220 "IPv6 address type"; 1221 } 1222 leaf ipv6-address { 1224 type inet:ipv6-address; 1225 mandatory true; 1226 description 1227 "IPv6 Address"; 1228 } 1229 description 1230 "ipv6 Address based TP Addressing."; 1231 } 1232 container tp-attribute { 1233 when "derived-from-or-self(../tp-location-type,"+ 1234 "'cl-oam:tp-attribute-type')" { 1235 description 1236 "Test point attribute type"; 1237 } 1238 leaf tp-attribute-type { 1239 type address-attribute-type; 1240 description 1241 "Test point type."; 1242 } 1243 choice tp-attribute-value { 1244 description 1245 "Test point value."; 1246 case ip-prefix { 1247 leaf ip-prefix { 1248 type inet:ip-prefix; 1249 description 1250 "Generic IPv4/IPv6 prefix.See Section 3.2.13 and 1251 Section 3.2.14 of RFC8029."; 1252 reference 1253 "RFC 8029 :Detecting Multi-Protocol Label 1254 Switched (MPLS) Data Plane Failures"; 1255 } 1256 } 1257 case bgp { 1258 leaf bgp { 1259 type inet:ip-prefix; 1260 description 1261 "BGP Labeled IPv4/IPv6 Prefix.See section 1262 3.2.11 and section 3.2.12 of RFC8029 for details. "; 1263 reference 1264 "RFC 8029 :Detecting Multi-Protocol Label 1265 Switched (MPLS) Data Plane Failures"; 1266 } 1267 } 1268 case tunnel { 1269 leaf tunnel-interface { 1270 type uint32; 1271 description 1272 "Basic IPv4/IPv6 Tunnel ID. See section 3.2.3 1273 and Section 3.2.4 of RFC8029 for details."; 1274 reference 1275 "RFC 8029 :Detecting Multi-Protocol Label 1276 Switched (MPLS) Data Plane Failures."; 1277 } 1278 } 1279 case pw { 1280 leaf remote-pe-address { 1281 type inet:ip-address; 1282 description 1283 "Remote PE address,See section 3.2.8 1284 of RFC8029 for details."; 1285 reference 1286 "RFC 8029 :Detecting Multi-Protocol Label 1287 Switched (MPLS) Data Plane Failures"; 1288 } 1289 leaf pw-id { 1290 type uint32; 1291 description 1292 "Pseudowire ID is a non-zero 32-bit ID.See section 1293 3.2.8 and Section 3.2.9 for details."; 1294 reference 1295 "RFC 8029 :Detecting Multi-Protocol Label 1296 Switched (MPLS) Data Plane Failures"; 1297 } 1298 } 1299 case vpls { 1300 leaf route-distinguisher { 1301 type rt:route-distinguisher; 1302 description 1303 "Route Distinguisher is an 8 octets identifier 1304 used to distinguish information about various 1305 L2VPN advertised by a node."; 1306 reference 1307 "RFC 8029 :Detecting Multi-Protocol Label 1308 Switched (MPLS) Data Plane Failures"; 1309 } 1310 leaf sender-ve-id { 1311 type uint16; 1312 description 1313 "Sender's VE ID. The VE ID (VPLS Edge Identifier) 1314 is a 2-octet identifier."; 1315 reference 1316 "RFC 8029 :Detecting Multi-Protocol Label 1317 Switched (MPLS) Data Plane Failures"; 1318 } 1319 leaf receiver-ve-id { 1320 type uint16; 1321 description 1322 "Receiver's VE ID.The VE ID (VPLS Edge Identifier) 1323 is a 2-octet identifier."; 1324 reference 1325 "RFC 8029 :Detecting Multi-Protocol Label 1326 Switched (MPLS) Data Plane Failures"; 1327 } 1328 } 1329 case mpls-mldp { 1330 choice root-address { 1331 description 1332 "Root address choice."; 1333 case ip-address { 1334 leaf source-address { 1335 type inet:ip-address; 1336 description 1337 "IP address."; 1338 } 1339 leaf group-ip-address { 1340 type inet:ip-address; 1341 description 1342 "Group ip address."; 1343 } 1344 } 1345 case vpn { 1346 leaf as-number { 1347 type inet:as-number; 1348 description 1349 "The AS number represents autonomous system 1350 numbers which identify an Autonomous System."; 1351 } 1352 } 1353 case global-id { 1354 leaf lsp-id { 1355 type string; 1356 description 1357 "LSP ID is an identifier of a LSP 1358 within a MPLS network."; 1359 reference 1360 "RFC 8029 :Detecting Multi-Protocol Label 1361 Switched (MPLS) Data Plane Failures"; 1362 } 1363 } 1364 } 1365 } 1366 } 1367 description 1368 "Test Point Attribute Container"; 1369 } 1370 container system-info { 1371 when "derived-from-or-self(../tp-location-type,"+ 1372 "'cl-oam:router-id-address-type')" { 1373 description 1374 "System id address type"; 1375 } 1376 leaf router-id { 1377 type rt:router-id; 1378 description 1379 "Router ID assigned to this node."; 1380 } 1381 description 1382 "Router ID container."; 1383 } 1384 description 1385 "TP Address"; 1386 } 1387 grouping tp-address-ni { 1388 description 1389 "Test point address with VRF."; 1390 leaf ni { 1391 type routing-instance-ref; 1392 description 1393 "The ni is used to describe virtual resource partitioning 1394 that may be present on a network device.Example of common 1395 industry terms for virtual resource partitioning is VRF 1396 instance."; 1397 } 1398 uses tp-address; 1399 } 1400 grouping connectionless-oam-tps { 1401 list oam-neighboring-tps { 1402 key "index"; 1403 leaf index { 1404 type uint16{ 1405 range "0..65535"; 1406 } 1407 description 1408 "List of related neighboring test points in adjacent 1409 layers up and down the stack for the same interface 1410 that are related to the current test point"; 1411 } 1412 leaf position { 1413 type int8 { 1414 range "-1..1"; 1415 } 1416 default "0"; 1417 description 1418 "The relative position 1419 of neighboring test point 1420 corresponding to the current 1421 test point.Level 0 indicates no neighboring 1422 test points placed before or after the current 1423 test point in the same layer.-1 means there is 1424 a neighboring test point placed before the current 1425 test point in the same layer and +1 means there is 1426 a neighboring test point placed after the current 1427 test point in same layer."; 1428 } 1429 choice tp-location { 1430 case mac-address { 1431 leaf mac-address-location { 1432 type yang:mac-address; 1433 description 1434 "MAC Address"; 1435 } 1436 description 1437 "MAC Address based TP Addressing."; 1438 } 1439 case ipv4-address { 1440 leaf ipv4-address-location { 1441 type inet:ipv4-address; 1442 description 1443 "Ipv4 Address"; 1444 } 1445 description 1446 "IP Address based TP Addressing."; 1447 } 1448 case ipv6-address { 1449 leaf ipv6-address-location { 1450 type inet:ipv6-address; 1451 description 1452 "IPv6 Address"; 1453 } 1454 description 1455 "IPv6 Address based TP Addressing."; 1456 } 1457 case as-number { 1458 leaf as-number-location { 1459 type inet:as-number; 1460 description 1461 "AS number location"; 1462 } 1463 description 1464 "AS number for point to multipoint OAM"; 1465 } 1466 case router-id { 1467 leaf router-id-location { 1468 type rt:router-id; 1469 description 1470 "System id location"; 1471 } 1473 description 1474 "System ID"; 1475 } 1476 description 1477 "TP location."; 1478 } 1479 description 1480 "List of neighboring test points in the same layer that are related to current test 1481 point. If the neighboring test-point is placed after the current test point, the 1482 position is specified as +1. If neighboring test-point 1483 is placed before the current test point, the position is specified 1484 as -1, if no neighboring test points placed before or after the current 1485 test point in the same layer, the position is specified as 0."; 1486 } 1487 description 1488 "Connectionless OAM related neighboring test points list."; 1489 } 1490 grouping tp-technology { 1491 choice technology { 1492 default "technology-null"; 1493 case technology-null { 1494 description 1495 "This is a placeholder when no technology is needed."; 1496 leaf tech-null { 1497 type empty; 1498 description 1499 "There is no technology to be defined."; 1500 } 1501 } 1502 description 1503 "Technology choice."; 1504 } 1505 description 1506 "OAM Technology"; 1507 } 1508 grouping tp-tools { 1509 description 1510 "Test Point OAM Toolset."; 1511 container tp-tools { 1512 leaf continuity-check { 1513 type boolean; 1514 mandatory true; 1515 description 1516 "A flag indicating whether or not the 1517 continuity check function is supported."; 1518 reference 1520 "RFC 792: INTERNET CONTROL MESSAGE PROTOCOL. 1521 RFC 4443: Internet Control Message Protocol (ICMPv6) 1522 for the Internet Protocol Version 6 (IPv6) Specification. 1523 RFC 5880: Bidirectional Forwarding Detection. 1524 RFC 5881: BFD for IPv4 and IPv6. 1525 RFC 5883: BFD for Multihop Paths. 1527 RFC 5884: BFD for MPLS Label Switched Paths. 1528 RFC 5885: BFD for PW VCCV. 1529 RFC 6450: Multicast Ping Protocol. 1530 RFC 8029: Detecting Multiprotocol Label Switched 1531 (MPLS) Data-Plane Failures."; 1532 } 1533 leaf path-discovery { 1534 type boolean; 1535 mandatory true; 1536 description 1537 "A flag indicating whether or not the 1538 path discovery function is supported."; 1539 reference 1540 "RFC 792: INTERNET CONTROL MESSAGE PROTOCOL. 1541 RFC 4443: Internet Control Message Protocol (ICMPv6) 1542 for the Internet Protocol Version 6 (IPv6) Specification. 1543 RFC 4884: Extended ICMP to Support Multi-part Message. 1544 RFC 5837:Extending ICMP for Interface. 1545 and Next-Hop Identification. 1546 RFC 8029: Detecting Multiprotocol Label Switched (MPLS) 1547 Data-Plane Failures."; 1548 } 1549 description 1550 "Container for test point OAM tools set."; 1551 } 1552 } 1553 grouping test-point-location-info { 1554 uses tp-technology; 1555 uses tp-tools; 1556 anydata root { 1557 yangmnt:mount-point "root"; 1558 description 1559 "Root for models supported per 1560 test point"; 1561 } 1562 uses connectionless-oam-tps; 1563 description 1564 "Test point Location"; 1565 } 1566 grouping test-point-locations { 1567 description 1568 "Group of test point locations."; 1569 leaf tp-location-type { 1571 type identityref { 1572 base tp-address-technology-type; 1573 } 1574 description 1575 "Test point location type."; 1576 } 1577 container ipv4-location-type { 1578 when "derived-from-or-self(../tp-location-type,"+ 1579 "'cl-oam:ipv4-address-type')" { 1580 description 1581 "When test point location type is equal to ipv4 address."; 1582 } 1583 container test-point-ipv4-location-list { 1584 list test-point-locations { 1585 key "ipv4-location ni"; 1586 leaf ipv4-location { 1587 type inet:ipv4-address; 1588 description 1589 "IPv4 Address."; 1590 } 1591 leaf ni { 1592 type routing-instance-ref; 1593 description 1594 "The ni is used to describe the 1595 corresponding network instance"; 1596 } 1597 uses test-point-location-info; 1598 description 1599 "List of test point locations."; 1600 } 1601 description 1602 "Serves as top-level container 1603 for test point location list."; 1604 } 1605 description 1606 "ipv4 location type container."; 1607 } 1608 container ipv6-location-type { 1609 when "derived-from-or-self(../tp-location-type,"+ 1610 "'cl-oam:ipv6-address-type')" { 1611 description 1612 "when test point location is equal to ipv6 address"; 1613 } 1614 container test-point-ipv6-location-list { 1615 list test-point-locations { 1616 key "ipv6-location ni"; 1617 leaf ipv6-location { 1618 type inet:ipv6-address; 1619 description 1620 "IPv6 Address."; 1621 } 1622 leaf ni { 1623 type routing-instance-ref; 1624 description 1625 "The ni is used to describe the 1626 corresponding network instance"; 1627 } 1628 uses test-point-location-info; 1629 description 1630 "List of test point locations."; 1631 } 1632 description 1633 "Serves as top-level container 1634 for test point location list."; 1635 } 1636 description 1637 "ipv6 location type container."; 1638 } 1639 container mac-location-type { 1640 when "derived-from-or-self(../tp-location-type,"+ 1641 "'cl-oam:mac-address-type')" { 1642 description 1643 "when test point location type is equal to mac address."; 1644 } 1645 container test-point-mac-address-location-list { 1646 list test-point-locations { 1647 key "mac-address-location"; 1648 leaf mac-address-location { 1649 type yang:mac-address; 1650 description 1651 "MAC Address"; 1652 } 1653 uses test-point-location-info; 1654 description 1655 "List of test point locations."; 1656 } 1657 description 1658 "Serves as top-level container 1659 for test point location list."; 1660 } 1661 description 1662 "mac address location type container."; 1663 } 1664 container group-as-number-location-type { 1665 when "derived-from-or-self(../tp-location-type,"+ 1666 "'cl-oam:as-number-address-type')" { 1667 description 1668 "when test point location type is equal to as-number."; 1669 } 1670 container test-point-as-number-location-list { 1671 list test-point-locations { 1672 key "as-number-location"; 1673 leaf as-number-location { 1674 type inet:as-number; 1675 description 1676 "AS number for point to multi point OAM."; 1677 } 1678 leaf ni { 1679 type routing-instance-ref; 1680 description 1681 "The ni is used to describe the 1682 corresponding network instance"; 1683 } 1684 uses test-point-location-info; 1685 description 1686 "List of test point locations."; 1687 } 1688 description 1689 "Serves as top-level container 1690 for test point location list."; 1691 } 1692 description 1693 "as number location type container."; 1694 } 1695 container group-router-id-location-type { 1696 when "derived-from-or-self(../tp-location-type,"+ 1697 "'cl-oam:router-id-address-type')" { 1698 description 1699 "when test point location type is equal to system-info."; 1700 } 1701 container test-point-system-info-location-list { 1702 list test-point-locations { 1703 key "router-id-location"; 1704 leaf router-id-location { 1705 type rt:router-id; 1706 description 1707 "System Id."; 1708 } 1709 leaf ni { 1710 type routing-instance-ref; 1711 description 1712 "The ni is used to describe the 1713 corresponding network instance"; 1714 } 1715 uses test-point-location-info; 1716 description 1717 "List of test point locations."; 1718 } 1719 description 1720 "Serves as top-level container for 1721 test point location list."; 1722 } 1723 description 1724 "system ID location type container."; 1725 } 1726 } 1727 augment "/nd:networks/nd:network/nd:node" { 1728 description 1729 "augments the /networks/network/node path defined in the ietf- 1730 network module (I-D.ietf-i2rs-yang-network-topo) with test-point- 1731 locations grouping."; 1732 uses test-point-locations; 1733 } 1734 grouping timestamp { 1735 description 1736 "Grouping for timestamp."; 1737 leaf timestamp-type { 1738 type identityref { 1739 base lime:timestamp-type; 1740 } 1741 description 1742 "Type of Timestamp, such as Truncated PTP, NTP."; 1743 } 1744 container timestamp-64bit { 1745 when "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ptp')"+ 1746 "or derived-from-or-self(../timestamp-type,'cl-oam:ntp64')" { 1747 description 1748 "Only applies when Truncated NTP or 64bit NTP Timestamp."; 1749 } 1750 leaf timestamp-sec { 1751 type uint32; 1752 description 1753 "Absolute timestamp in seconds as per IEEE1588v2 1754 or seconds part in 64-bit NTP timestamp."; 1755 } 1756 leaf timestamp-nanosec { 1757 type uint32; 1758 description 1759 "Fractional part in nanoseconds as per IEEE1588v2 1760 or Fractional part in 64-bit NTP timestamp."; 1761 } 1762 description 1763 "Container for 64bit timestamp."; 1764 } 1765 container timestamp-80bit { 1766 when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{ 1767 description 1768 "Only applies when 80bit PTP Timestamp."; 1769 } 1770 if-feature ptp-long-format; 1771 leaf timestamp-sec { 1772 type uint64 { 1773 range "0..281474976710655"; 1774 } 1775 description 1776 "48bit Timestamp in seconds as per IEEE1588v2."; 1777 } 1778 leaf timestamp-nanosec { 1779 type uint32; 1780 description 1781 "Fractional part in nanoseconds as per IEEE1588v2 1782 or Fractional part in 64-bit NTP timestamp."; 1783 } 1784 description 1785 "Container for 80bit timestamp."; 1786 } 1787 container ntp-timestamp-32bit { 1788 when "derived-from-or-self(../timestamp-type, 'cl-oam:truncated-ntp')"{ 1789 description 1790 "Only applies when 32 bit NTP Short format Timestamp."; 1791 } 1792 if-feature ntp-short-format; 1793 leaf timestamp-sec { 1794 type uint16; 1795 description 1796 "Timestamp in seconds as per short format NTP."; 1797 } 1798 leaf timestamp-nanosec { 1799 type uint16; 1800 description 1801 "Truncated Fractional part in 16-bit NTP timestamp."; 1802 } 1803 description 1804 "Container for 32bit timestamp."; 1805 } 1806 container icmp-timestamp-32bit { 1807 when "derived-from-or-self(../timestamp-type, 'cl-oam:icmp-ntp')"{ 1808 description 1809 "Only applies when Truncated NTP or 64bit NTP Timestamp."; 1810 } 1811 if-feature icmp-timestamp; 1812 leaf timestamp-millisec { 1813 type uint32; 1815 description 1816 "timestamp in milliseconds for ICMP timestamp."; 1817 } 1818 description 1819 "Container for 32bit timestamp."; 1820 } 1821 } 1822 grouping path-discovery-data { 1823 description 1824 "Path discovery related data output from nodes."; 1825 container src-test-point { 1826 description 1827 "Source test point."; 1828 uses tp-address-ni; 1829 } 1830 container dest-test-point { 1831 description 1832 "Destination test point."; 1833 uses tp-address-ni; 1834 } 1835 leaf sequence-number { 1836 type uint64; 1837 default "0"; 1838 description 1839 "Sequence number in data packets.A value of 1840 zero indicates that no sequence number is sent."; 1841 } 1842 leaf hop-cnt { 1843 type uint8; 1844 default "0"; 1845 description 1846 "Hop count.A value of zero indicates 1847 that no hop count is sent"; 1848 } 1849 uses session-packet-statistics; 1850 uses session-error-statistics; 1851 uses session-delay-statistics; 1852 uses session-jitter-statistics; 1853 container path-verification { 1854 description 1855 "Optional path verification related information."; 1856 leaf flow-info { 1857 type string; 1858 description 1859 "Informations that refers to the flow."; 1860 } 1861 uses session-path-verification-statistics; 1862 } 1863 container path-trace-info { 1864 description 1865 "Optional path trace per-hop test point information. 1866 The path trace information list has typically a single 1867 element for per-hop cases like path-discovery RPC operation 1868 but allows a list of hop related information for other types of 1869 data retrieval methods."; 1870 list path-trace-info-list { 1871 key "index"; 1872 description 1873 "Path trace information list."; 1874 leaf index { 1875 type uint32; 1876 description 1877 "Trace information index."; 1878 } 1879 uses tp-address-ni; 1880 uses timestamp; 1881 leaf ingress-intf-name { 1882 type if:interface-ref; 1883 description 1884 "Ingress interface name"; 1885 } 1886 leaf egress-intf-name { 1887 type if:interface-ref; 1888 description 1889 "Egress interface name"; 1890 } 1891 leaf queue-depth { 1892 type uint32; 1893 description 1894 "Length of the queue of the interface from where 1895 the packet is forwarded out. The queue depth could 1896 be the current number of memory buffers used by the 1897 queue and a packet can consume one or more memory buffers 1898 thus constituting device-level information."; 1899 } 1900 leaf transit-delay { 1901 type uint32; 1902 description 1903 "Time in nano seconds 1904 packet spent transiting a node."; 1905 } 1906 leaf app-meta-data { 1907 type uint64; 1908 description 1910 "Application specific 1911 data added by node."; 1912 } 1913 } 1914 } 1915 } 1916 grouping continuity-check-data { 1917 description 1918 "Continuity check data output from nodes."; 1919 container src-test-point { 1920 description 1921 "Source test point."; 1922 uses tp-address-ni; 1923 leaf egress-intf-name { 1924 type if:interface-ref; 1925 description 1926 "Egress interface name."; 1927 } 1928 } 1929 container dest-test-point { 1930 description 1931 "Destination test point."; 1932 uses tp-address-ni; 1933 leaf ingress-intf-name { 1934 type if:interface-ref; 1935 description 1936 "Ingress interface name."; 1937 } 1938 } 1939 leaf sequence-number { 1940 type uint64; 1941 default "0"; 1942 description 1943 "Sequence number in data packets.A value of 1944 zero indicates that no sequence number is sent."; 1945 } 1946 leaf hop-cnt { 1947 type uint8; 1948 default "0"; 1949 description 1950 "Hop count.A value of zero indicates 1951 that no hop count is sent"; 1952 } 1953 uses session-packet-statistics; 1954 uses session-error-statistics; 1955 uses session-delay-statistics; 1956 uses session-jitter-statistics; 1957 } 1958 container cc-session-statistics-data { 1959 if-feature "continuity-check"; 1960 config false; 1961 list cc-session-statistics { 1962 key type; 1963 leaf type { 1964 type identityref { 1965 base traffic-type; 1966 } 1967 description 1968 "Type of traffic."; 1969 } 1970 container cc-ipv4-sessions-statistics { 1971 when "../type = 'ipv4'" { 1972 description 1973 "Only applies when traffic type is Ipv4."; 1974 } 1975 description 1976 "CC ipv4 sessions"; 1977 uses cc-session-statistics; 1978 } 1979 container cc-ipv6-sessions-statistics { 1980 when "../type = 'ipv6'" { 1981 description 1982 "Only applies when traffic type is Ipv6."; 1983 } 1984 description 1985 "CC ipv6 sessions"; 1986 uses cc-session-statistics; 1987 } 1988 description 1989 "List of CC session statistics data."; 1990 } 1991 description 1992 "CC operational information."; 1993 } 1994 } 1996 1998 6. Connectionless model applicability 2000 The "ietf-connectionless-oam" model defined in this document provides 2001 a technology-independent abstraction of key OAM constructs for 2002 connectionless protocols. This model can be further extended to 2003 include technology specific details, e.g., adding new data nodes with 2004 technology specific functions and parameters into proper anchor 2005 points of the base model, so as to develop a technology-specific 2006 connectionless OAM model. 2008 This section demonstrates the usability of the connectionless YANG 2009 OAM data model to various connectionless OAM technologies, e.g., BFD, 2010 LSP ping. Note that, in this section, several snippets of 2011 technology-specific model extensions are presented for illustrative 2012 purposes. The complete model extensions should be worked on in 2013 respective protocol working groups. 2015 6.1. BFD Extension 2017 RFC 7276 defines BFD as a connection-oriented protocol. It is used 2018 to monitor a connectionless protocol in the case of basic BFD for IP. 2020 6.1.1. Augment Method 2022 The following sections shows how the "ietf-connectionless-oam" model 2023 can be extended to cover BFD technology. For this purpose, a set of 2024 extension are introduced such as technology-type extension and test- 2025 point attributes extension. 2027 Note that a dedicated BFD YANG data model [I-D.ietf-bfd-yang] is also 2028 standardized. Augmentation of the "ietf-connectionless-oam" model 2029 with BFD specific details provides an alternative approach that 2030 provides a unified view of management information across various OAM 2031 protocols. The BFD specific details can be the grouping defined in 2032 the BFD model avoiding duplication of effort. 2034 6.1.1.1. Technology type extension 2036 No BFD technology type has been defined in the "ietf-connectionless- 2037 oam" model. Therefore a technology type extension is required in the 2038 model Extension. 2040 The snippet below depicts an example of adding the "bfd" type as an 2041 augment to the ietf-connectionless-oam" model: 2043 augment "/nd:networks/nd:network/nd:node/" 2044 +"coam:location-type/coam:ipv4-location-type" 2045 +"/coam:test-point-ipv4-location-list/" 2046 +"coam:test-point-locations/coam:technology" 2047 { 2048 leaf bfd{ 2049 type string; 2050 } 2051 } 2053 6.1.1.2. Test point attributes extension 2055 To support BFD technology, the "ietf-connectionless-oam" model can be 2056 extended by adding specific parameters into the "test-point- 2057 locations" list and/or adding a new location type such as "BFD over 2058 MPLS TE" under "location-type". 2060 6.1.1.2.1. Define and insert new nodes into corresponding test-point- 2061 location 2063 In the "ietf-connectionless-oam" model, multiple "test-point- 2064 location" lists are defined under the "location-type" choice node. 2065 Therefore, to derive a model for some BFD technologies ( such as ip 2066 single-hop, ip multi-hops, etc), data nodes for BFD specific details 2067 need to be added into corresponding "test-point-locations" list. In 2068 this section, some groupings which are defined in [I-D.ietf-bfd-yang] 2069 are reused as follow: 2071 The snippet below shows how the "ietf-connectionless-oam" model can 2072 be extended to support "BFD IP single-hop": 2074 augment "/nd:networks/nd:network/nd:node/" 2075 +"coam:location-type/coam:ipv4-location-type" 2076 +"/coam:test-point-ipv4-location-list/" 2077 +"coam:test-point-locations" 2078 { 2079 container session-cfg { 2080 description "BFD IP single-hop session configuration"; 2081 list sessions { 2082 key "interface dest-addr"; 2083 description "List of IP single-hop sessions"; 2084 leaf interface { 2085 type if:interface-ref; 2086 description 2087 "Interface on which the BFD session is running."; 2088 } 2089 leaf dest-addr { 2090 type inet:ip-address; 2091 description "IP address of the peer"; 2092 } 2093 uses bfd:bfd-grouping-common-cfg-parms; 2094 uses bfd:bfd-grouping-echo-cfg-parms; 2095 } 2096 } 2097 } 2099 Similar augmentations can be defined to support other BFD 2100 technologies such as BFD IP multi-hop, BFD over MPLS, etc. 2102 6.1.1.2.2. Add new location-type cases 2104 In the "ietf-connectionless-oam" model, If there is no appropriate 2105 "location type" case that can be extended, a new "location-type" case 2106 can be defined and inserted into the "location-type" choice node. 2108 Therefore, the model user can flexibly add "location-type" to support 2109 other type of test point which are not defined in the "ietf- 2110 connectionless-oam" model. In this section, a new "location-type" 2111 case is added and some groupings that are defined in 2112 [I-D.ietf-bfd-yang] are reused as follows: 2114 The snippet below shows how the "ietf-connectionless-oam" model can 2115 be extended to support "BFD over MPLS-TE": 2117 augment "/nd:networks/nd:network/nd:node/coam:location-type"{ 2118 case te-location{ 2119 list test-point-location-list{ 2120 key "tunnel-name"; 2121 leaf tunnel-name{ 2122 type leafref{ 2123 path "/te:te/te:tunnels/te:tunnel/te:name"; 2124 } 2125 description 2126 "point to a te instance."; 2127 } 2128 uses bfd:bfd-grouping-common-cfg-parms; 2129 uses bfd-mpls:bfd-encap-cfg; 2130 } 2131 } 2132 } 2134 Similar augmentations can be defined to support other BFD 2135 technologies such as BFD over LAG, etc. 2137 6.1.2. Schema Mount 2139 Another alternative method is using the schema mount mechanism [I- 2140 D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam" model. 2141 Within the "test-point-locations" list, a "root" attribute is defined 2142 to provide a mount point for models mounted per "test-point- 2143 locations". Therefore, the "ietf-connectionless-oam" model can 2144 provide a place in the node hierarchy where other OAM YANG data 2145 models can be attached, without any special extension in the "ietf- 2146 connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount]. 2147 Note that the limitation of the Schema Mount method is it is not 2148 allowed to specify certain modules that are required to be mounted 2149 under a mount point. 2151 The snippet below depicts the definition of the "root" attribute. 2153 anydata root { 2154 yangmnt:mount-point root; 2155 description 2156 "Root for models supported per 2157 test point"; 2158 } 2160 The following section shows how the "ietf-connectionless-oam" model 2161 can use schema mount to support BFD technology. 2163 6.1.2.1. BFD Modules be populated in schema-mount 2165 To support BFD technology, "ietf-bfd-ip-sh" and "ietf-bfd-ip-mh" YANG 2166 modules might be populated in the "schema-mounts" container: 2168 2170 2171 ietf-connectionless-oam 2172 root 2173 2174 root 2175 2176 2177 2178 root 2179 2180 ietf-bfd-ip-sh 2181 2016-07-04 2182 2183 urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh 2184 2185 implement 2186 2187 2188 ietf-bfd-ip-mh 2189 2016-07-04 2190 2191 urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh 2192 2193 implement 2194 2195 2196 2198 and the " ietf-connectionless-oam " module might have: 2200 2202 ...... 2203 2204 192.0.2.1 2205 ...... 2206 2207 2208 2209 foo 2210 ...... 2211 2212 2213 2214 2215 foo 2216 ...... 2217 2218 2219 2220 2221 2223 6.2. LSP ping extension 2225 6.2.1. Augment Method 2227 The following sections shows how the "ietf-connectionless-oam" model 2228 can be extended to support LSP ping technology. For this purpose, a 2229 set of extensions are introduced such as the "technology-type" 2230 extension and the test-point "attributes" extension. 2232 Note that a LSP Ping YANG data model 2233 [I-D.zheng-mpls-lsp-ping-yang-cfg] has been standardized. As with 2234 BFD, users can choose to use the "ietf-connectioless-oam" as basis 2235 and augment the "ietf- connectionless-oam" model with LSP Ping 2236 specific details in the model extension to provide a unified view 2237 across different technologies. The LSP Ping specific details can be 2238 the grouping defined in the LSP ping model to avoid duplication of 2239 effort. 2241 6.2.1.1. Technology type extension 2243 No lsp-ping technology type has been defined in the "ietf- 2244 connectionless-oam" model. Therefore a technology type extension is 2245 required in the model extension. 2247 The snippet below depicts an example of augmenting the "ietf- 2248 connectionless-oam" with "lsp-ping" type: 2250 augment "/nd:networks/nd:network/nd:node/" 2251 +"coam:location-type/coam:ipv4-location-type" 2252 +"/coam:test-point-ipv4-location-list/" 2253 +"coam:test-point-locations/coam:technology" 2254 { 2255 leaf lsp-ping{ 2256 type string; 2257 } 2258 } 2260 6.2.1.2. Test point attributes extension 2262 To support lsp-ping, the "ietf-connectionless-oam" model can be 2263 extended and add lsp-ping specific parameters can be defined and 2264 under "test-point-locations" list. 2266 Users can reuse the attributes or groupings which are defined in 2267 [I-D.zheng-mpls-lsp-ping-yang-cfg] as follows: 2269 The snippet below depicts an example of augmenting the "test-point- 2270 locations" list with lsp ping attributes: 2272 augment "/nd:networks/nd:network/nd:node/" 2273 +"coam:location-type/coam:ipv4-location-type" 2274 +"/coam:test-point-ipv4-location-list/" 2275 +"coam:test-point-locations" 2276 { 2277 list lsp-ping { 2278 key "lsp-ping-name"; 2279 leaf lsp-ping-name { 2280 type string { 2281 length "1..31"; 2282 } 2283 mandatory "true"; 2284 description "LSP Ping test name."; 2285 ...... 2286 } 2288 6.2.2. Schema Mount 2290 And another alternative method is using schema mount mechanism 2291 [I-D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam". 2292 Within the "test-point-locations" list, a "root" attribute is defined 2293 to provide a mounted point for models mounted per "test-point- 2294 locations". Therefore, the "ietf-connectionless-oam" model can 2295 provide a place in the node hierarchy where other OAM YANG data 2296 models can be attached, without any special extension in the "ietf- 2297 connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount]. 2298 Note that the limitation of the Schema Mount method is it is not 2299 allowed to specify certain modules that are required to be mounted 2300 under a mount point. 2302 The snippet below depicts the definition of "root" attribute. 2304 anydata root { 2305 yangmnt:mount-point root; 2306 description 2307 "Root for models supported per 2308 test point"; 2309 } 2311 The following section shows how the "ietf-connectionless-oam" model 2312 can use schema mount to support LSP-PING technology. 2314 6.2.2.1. LSP-PING Modules be populated in schema-mount 2316 To support LSP-PING technology, "ietf-lspping" YANG module 2317 [I-D.zheng-mpls-lsp-ping-yang-cfg] might be populated in the "schema- 2318 mounts" container: 2320 2322 2323 ietf-connectionless-oam 2324 root 2325 2326 root 2327 2328 2329 2330 root 2331 2332 ietf-lspping 2333 2016-03-18 2334 2335 urn:ietf:params:xml:ns:yang: ietf-lspping 2336 2337 implement 2338 2339 2340 2342 and the " ietf-connectionless-oam " module might have: 2344 2346 ...... 2347 2348 192.0.2.1 2349 ...... 2350 2351 2352 2353 foo 2354 ...... 2355 2356 2357 2358 2359 2361 7. Security Considerations 2363 The YANG module defined in this document is designed to be accessed 2364 via network management protocols such as NETCONF [RFC6241] or 2365 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 2366 layer, and the mandatory-to-implement secure transport is Secure 2367 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 2368 mandatory-to-implement secure transport is TLS [RFC5246]. 2370 The NETCONF access control model [RFC6536] provides the means to 2371 restrict access for particular NETCONF or RESTCONF users to a 2372 preconfigured subset of all available NETCONF or RESTCONF protocol 2373 operations and content. 2375 There are a number of data nodes defined in this YANG module that are 2376 writable/creatable/deletable (i.e., config true, which is the 2377 default). These data nodes may be considered sensitive or vulnerable 2378 in some network environments. Write operations (e.g., edit-config) 2379 to these data nodes without proper protection can have a negative 2380 effect on network operations. 2382 The vulnerable "config true" subtrees and data nodes are the 2383 following: 2385 /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:ipv4- 2386 location-type/cl-oam:test-point-ipv4-location-list/cl-oam:test- 2387 point-locations/ 2389 /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:ipv6- 2390 location-type/cl-oam:test-point-ipv6-location-list/cl-oam:test- 2391 point-locations/ 2392 /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:mac- 2393 location-type/cl-oam:test-point-mac-address-location-list/cl- 2394 oam:test-point-locations/ 2396 /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:group- 2397 as-number-location-type/cl-oam:test-point-as-number-location-list/ 2398 cl-oam:test-point-locations/ 2400 /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:group- 2401 router-id-location-type/cl-oam:test-point-system-info-location- 2402 list/cl-oam:test-point-locations/ 2404 Unauthorized access to any of these lists can adversely affect OAM 2405 management system handling of end-to-end OAM and coordination of OAM 2406 within underlying network layers. This may lead to inconsistent 2407 configuration, reporting, and presentation for the OAM mechanisms 2408 used to manage the network. 2410 Some of the readable data nodes in this YANG module may be considered 2411 sensitive or vulnerable in some network environments. It is thus 2412 important to control read access (e.g., via get, get-config, or 2413 notification) to these data nodes. These are the subtrees and data 2414 nodes and their sensitivity/vulnerability: 2416 /coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions- 2417 statistics/cl-oam:cc-session-statistics/cl-oam:session-count/ 2419 /coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions- 2420 statistics/cl-oam:cc-session-statistics/cl-oam:session-up-count/ 2422 /coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions- 2423 statistics/cl-oam:cc-session-statistics/cl-oam: session-down- 2424 count/ 2426 /coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions- 2427 statistics/cl-oam:cc-session-statistics/cl-oam:session-admin-down- 2428 count/ 2430 /coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions- 2431 statistics/cl-oam:cc-session-statistics/cl-oam:session-count/ 2433 /coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions- 2434 statistics/cl-oam:cc-session-statistics/cl-oam:session-up-count// 2436 /coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions- 2437 statistics/cl-oam:cc-session-statistics/cl-oam:session-down-count/ 2438 /coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions- 2439 statistics/cl-oam:cc-session-statistics/cl-oam:session-admin-down- 2440 count/ 2442 8. IANA Considerations 2444 This document registers a URI in the IETF XML registry [RFC3688]. 2445 Following the format in [RFC3688] the following registration is 2446 requested to be made: 2448 URI: urn:ietf:params:xml:ns:yang:ietf-lime-time-types 2449 Registrant Contact: The IESG. 2450 XML: N/A; the requested URI is an XML namespace. 2452 URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam 2453 Registrant Contact: The IESG. 2454 XML: N/A, the requested URI is an XML namespace. 2456 This document registers a YANG module in the YANG Module Names 2457 registry [RFC7950]. 2459 Name: ietf-lime-common-types 2460 Namespace: urn:ietf:params:xml:ns:yang:ietf-lime-time-types 2461 Prefix: lime 2462 Reference: RFC XXXX 2464 Name: ietf-connectionless-oam 2465 Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam 2466 Prefix: cl-oam 2467 Reference: RFC XXXX 2469 9. Acknowlegements 2471 The authors of this document would like to thank Elwyn Davies, Alia 2472 Atlas,Brian E Carpenter,Greg Mirsky,Adam Roach,Alissa Cooper,Eric 2473 Rescorla,Ben Campbell, Benoit Claise,Kathleen Moriarty and others for 2474 their sustainable review and comments, proposals to improve and 2475 stabilize document. 2477 10. References 2479 10.1. Normative References 2481 [I-D.ietf-i2rs-yang-network-topo] 2482 Clemm, A., Medved, J., Varga, R., Bahadur, N., 2483 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 2484 Topologies", draft-ietf-i2rs-yang-network-topo-17 (work in 2485 progress), October 2017. 2487 [I-D.ietf-rtgwg-ni-model] 2488 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 2489 Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- 2490 model-04 (work in progress), September 2017. 2492 [I-D.ietf-rtgwg-routing-types] 2493 Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 2494 "Routing Area Common YANG Data Types", draft-ietf-rtgwg- 2495 routing-types-17 (work in progress), October 2017. 2497 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2498 DOI 10.17487/RFC3688, January 2004, 2499 . 2501 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2502 Control Message Protocol (ICMPv6) for the Internet 2503 Protocol Version 6 (IPv6) Specification", STD 89, 2504 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2505 . 2507 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2508 (TLS) Protocol Version 1.2", RFC 5246, 2509 DOI 10.17487/RFC5246, August 2008, 2510 . 2512 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2513 "Network Time Protocol Version 4: Protocol and Algorithms 2514 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2515 . 2517 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 2518 RFC 6021, DOI 10.17487/RFC6021, October 2010, 2519 . 2521 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2522 and A. Bierman, Ed., "Network Configuration Protocol 2523 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2524 . 2526 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2527 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2528 . 2530 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2531 Protocol (NETCONF) Access Control Model", RFC 6536, 2532 DOI 10.17487/RFC6536, March 2012, 2533 . 2535 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2536 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2537 . 2539 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2540 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2541 . 2543 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 2544 September 1981. 2546 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2547 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2548 . 2550 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 2551 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 2552 Switched (MPLS) Data-Plane Failures", RFC 8029, 2553 DOI 10.17487/RFC8029, March 2017, 2554 . 2556 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2557 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2558 . 2560 10.2. Informative References 2562 [G.800] "Unified functional architecture of transport networks", 2563 ITU-T Recommendation G.800, 2016. 2565 [G.8013] "OAM functions and mechanisms for Ethernet based 2566 networks", ITU-T Recommendation G.8013/Y.1731, 2013. 2568 [I-D.ietf-bfd-yang] 2569 Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and 2570 G. Mirsky, "YANG Data Model for Bidirectional Forwarding 2571 Detection (BFD)", draft-ietf-bfd-yang-06 (work in 2572 progress), June 2017. 2574 [I-D.ietf-lime-yang-connection-oriented-oam-model] 2575 Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 2576 for Connection Oriented Operations, Administration, and 2577 Maintenance(OAM) protocols", draft-ietf-lime-yang- 2578 connection-oriented-oam-model-00 (work in progress), June 2579 2017. 2581 [I-D.ietf-lime-yang-connectionless-oam-methods] 2582 Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, 2583 "Retrieval Methods YANG Data Model for Connectionless 2584 Operations, Administration, and Maintenance(OAM) 2585 protocols", draft-ietf-lime-yang-connectionless-oam- 2586 methods-12 (work in progress), October 2017. 2588 [I-D.ietf-netmod-schema-mount] 2589 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 2590 ietf-netmod-schema-mount-08 (work in progress), October 2591 2017. 2593 [I-D.zheng-mpls-lsp-ping-yang-cfg] 2594 Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R. 2595 Rahman, "YANG Data Model for LSP-Ping", draft-zheng-mpls- 2596 lsp-ping-yang-cfg-06 (work in progress), October 2017. 2598 [IEEE.1588] 2599 "IEEE Standard for a Precision Clock Synchronization 2600 Protocol for Networked Measurement and Control Systems", 2601 IEEE IEEE Std 1588-2008, 2008. 2603 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 2604 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 2605 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2606 2009, . 2608 [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual 2609 Private Network (L2VPN) Operations, Administration, and 2610 Maintenance (OAM) Requirements and Framework", RFC 6136, 2611 DOI 10.17487/RFC6136, March 2011, 2612 . 2614 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 2615 Weingarten, "An Overview of Operations, Administration, 2616 and Maintenance (OAM) Tools", RFC 7276, 2617 DOI 10.17487/RFC7276, June 2014, 2618 . 2620 Authors' Addresses 2622 Deepak Kumar 2623 CISCO Systems 2624 510 McCarthy Blvd 2625 Milpitas, CA 95035 2626 USA 2628 Email: dekumar@cisco.com 2629 Michael Wang 2630 Huawei Technologies,Co.,Ltd 2631 101 Software Avenue, Yuhua District 2632 Nanjing 210012 2633 China 2635 Email: wangzitao@huawei.com 2637 Qin Wu 2638 Huawei 2639 101 Software Avenue, Yuhua District 2640 Nanjing, Jiangsu 210012 2641 China 2643 Email: bill.wu@huawei.com 2645 Reshad Rahman 2646 Cisco Systems 2647 2000 Innovation Drive 2648 Kanata, Ontario K2K 3E8 2649 Canada 2651 Email: rrahman@cisco.com 2653 Srihari Raghavan 2654 Cisco Systems 2655 Tril Infopark Sez, Ramanujan IT City 2656 Neville Block, 2nd floor, Old Mahabalipuram Road 2657 Chennai, Tamil Nadu 600113 2658 India 2660 Email: srihari@cisco.com