idnits 2.17.1 draft-zhuang-lime-yang-oam-model-applicability-02.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 26 characters in excess of 72. ** The abstract seems to contain references ([GENYANGOAM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 564: '... parameters MUST not be carried usin...' RFC 2119 keyword, line 586: '... parameters MUST not be carried usin...' RFC 2119 keyword, line 1038: '... parameters MUST not be carried usin...' RFC 2119 keyword, line 1108: '... parameters MUST not be carried usin...' RFC 2119 keyword, line 1523: '... parameters MUST not be carried usin...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 181 has weird spacing: '...terface if:...' == Line 1621 has weird spacing: '...nterval uin...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that MD level configuration parameters provides context information for management system to correlate faults, defects, network failures with location information, which helps quickly identify root causes of network failures.MD level configuration parameters MUST not be carried using IP Ping and traceroute protocol since IP Ping and traceroute doesn't support transport of these management information. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that MA level configuration parameters provides context information for management system to correlate faults, defects, network failures with location information, which helps quickly identify root causes of network failures.MA level configuration parameters MUST not be carried using IP Ping and traceroute protocol since IP Ping and traceroute doesn't support transport of these management information. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that MD level configuration parameters provides context information for management system to correlate faults, defects, network failures with location information, which helps quickly identify root causes of network failures. MD level configuration parameters MUST not be carried using MPLS OAM protocol(e.g., LSP Ping) since MPLS OAM protocol doesn't support transport of these management information. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that MA level configuration parameters provides context information for management system to correlate faults, defects, network failures with location information, which helps quickly identify root causes of network failures. MA level configuration parameters MUST not be carried using MPLS OAM protocol(e.g., LSP Ping) since MPLS OAM protocol doesn't support transport of these management information. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that MD level configuration parameters provides context information for management system to correlate faults, defects, network failures with location information, which helps quickly identify root causes of network failures. MD level configuration parameters MUST not be carried using BFD protocol since BFD doesn't support transport of these management information. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that MA level configuration parameters provides context information for management system to correlate faults, defects, network failures with location information, which helps quickly identify root causes of network failures. MA level configuration parameters MUST not be carried using BFD protocol since BFD doesn't support transport of these management information. -- The document date (December 11, 2015) is 3052 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MA-name-string' is mentioned on line 362, but not defined == Missing Reference: 'RFC6427' is mentioned on line 1177, but not defined == Missing Reference: 'RFC6374' is mentioned on line 1200, but not defined == Missing Reference: 'RFC6370' is mentioned on line 1354, but not defined == Missing Reference: 'RFC4364' is mentioned on line 1337, but not defined == Missing Reference: 'RFC6435' is mentioned on line 1388, but not defined == Missing Reference: 'RFC6375' is mentioned on line 1408, but not defined -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Taylor, Ed. 3 Internet-Draft PT Taylor Consulting 4 Intended status: Informational Y. Zhuang, Ed. 5 Expires: June 13, 2016 Huawei 6 December 11, 2015 8 Applicability of Generic YANG Data Model for layer Independent OAM 9 Management 10 draft-zhuang-lime-yang-oam-model-applicability-02 12 Abstract 14 A generic YANG data model for Operations, Administration, and 15 Maintenance (OAM) has been defined in [GENYANGOAM], with the 16 intention that technology-specific extensions will be developed to be 17 able reference/use the Generic YANG model. In this document, we 18 describe the applicability of the generic YANG OAM data model to 19 specific OAM technologies. To be concrete, we also demonstrate the 20 usability and extensibility of the generic YANG OAM model with OAM 21 protocols such as IP Ping, traceroute, BFD and MPLS LSP Ping. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 13, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Basic Structure of Generic YANG Model for OAM . . . . . . . . 4 61 3.1. Performance Management Support . . . . . . . . . . . . . 6 62 4. Guidelines For Extending the LIME Base Data Model . . . . . . 6 63 4.1. Extend configuration structure with technology specific 64 parameters . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.1. Maintenance domain (MD) at the root level . . . . . . 8 66 4.1.2. Maintenance Association (MA) at the second level . . 9 67 4.1.3. Maintenance Association Endpoint (MEP) at the third 68 level . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1.4. Session at the fourth level . . . . . . . . . . . . . 10 70 4.1.5. Interface at the fifth level . . . . . . . . . . . . 10 71 4.2. Extend RPC structure with technology specific parameters 10 72 4.3. Extend Notification structure with technology specific 73 parameters . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.4. Define New RPCs and Notifications . . . . . . . . . . . . 12 75 5. Applicability of LIME Model to Various Technologies . . . . . 12 76 5.1. Generic YANG Model extension for IP OAM . . . . . . . . . 13 77 5.1.1. MD Configuration Extension . . . . . . . . . . . . . 13 78 5.1.2. MA Configuration Extension . . . . . . . . . . . . . 13 79 5.1.3. MEP Configuration Extension . . . . . . . . . . . . . 14 80 5.1.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 14 81 5.1.5. Performance Monitoring Extension . . . . . . . . . . 15 82 5.2. Generic YANG Model extension for TRILL OAM . . . . . . . 16 83 5.2.1. MD Configuration Extension . . . . . . . . . . . . . 16 84 5.2.2. MA Configuration Extension . . . . . . . . . . . . . 16 85 5.2.3. MEP Configuration Extension . . . . . . . . . . . . . 17 86 5.2.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 18 87 5.2.5. Performance Management (PM) Extension . . . . . . . . 19 88 5.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 19 89 5.3. Generic YANG Model extension for MPLS OAM . . . . . . . . 23 90 5.3.1. MD Configuration Extension . . . . . . . . . . . . . 23 91 5.3.2. MA Configuration Extension . . . . . . . . . . . . . 24 92 5.3.3. MEP Configuration Extension . . . . . . . . . . . . . 25 93 5.3.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 26 94 5.3.5. Performance Management Extension . . . . . . . . . . 26 95 5.3.6. Usage Example . . . . . . . . . . . . . . . . . . . . 27 96 5.4. Generic YANG Model extension for MPLS-TP OAM . . . . . . 28 97 5.4.1. MD Configuration Extension . . . . . . . . . . . . . 28 98 5.4.2. MA Configuration Extension . . . . . . . . . . . . . 29 99 5.4.3. MEP Configuration Extension . . . . . . . . . . . . . 30 100 5.4.4. RPC Extension . . . . . . . . . . . . . . . . . . . . 30 101 5.4.5. Performance Monitoring Extension . . . . . . . . . . 31 102 5.5. Generic YANG Model extension for NVO3 OAM . . . . . . . . 31 103 5.5.1. Technology Type Extension . . . . . . . . . . . . . . 31 104 5.5.2. Sub Technology Type Extension . . . . . . . . . . . . 32 105 5.5.3. MEP Configuration Extension . . . . . . . . . . . . . 32 106 5.5.4. Connectivity-Context Extension . . . . . . . . . . . 33 107 5.5.5. RPC Extension . . . . . . . . . . . . . . . . . . . . 33 108 5.5.6. ECMP Extension . . . . . . . . . . . . . . . . . . . 33 109 5.6. Generic YANG Model extension for BFD . . . . . . . . . . 34 110 5.6.1. MD Level configuration extension . . . . . . . . . . 34 111 5.6.2. MA configuration extension . . . . . . . . . . . . . 35 112 5.6.3. MEP configuration extension . . . . . . . . . . . . . 36 113 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 114 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 115 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 116 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 117 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 118 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 119 10.2. Informative References . . . . . . . . . . . . . . . . . 38 120 Appendix A. Contributing Authors Infomation . . . . . . . . . . 40 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 123 1. Introduction 125 The Generic YANG [RFC6020] over NETCONF [RFC6241] data model for OAM 126 defined in [GENYANGOAM], aims at providing consistent configuration, 127 reporting and representation of OAM mechanisms at any layer for any 128 technology. 130 In this document, we discuss the applicability of the generic YANG 131 OAM model to various OAM technologies and demonstrates that the YANG 132 model(s) developed in the LIME WG are usable and extensible for those 133 technologies. The demonstration uses IP Ping, traceroute, BFD and 134 LSP Ping as specific examples. 136 2. Conventions Used In This Document 138 This document contains no normative language. 140 2.1. Terminology 142 MP Maintenance Point [IEEE802.1Q]. 144 MEP Maintenance association End Point [RFC7174] [IEEE802.1Q] 145 [RFC6371]. 147 MIP Maintenance domain Intermediate Point [RFC7174] [IEEE802.1Q] 148 [RFC6371]. 150 MA Maintenance Association [IEEE802.1Q] [RFC7174]. 152 MD Maintenance Domain [IEEE802.1Q]. 154 OAM Operations, Administration, and Maintenance [RFC6291]. 156 TRILL Transparent Interconnection of Lots of Links [RFC6325]. 158 RPC Remote Procedure Call[RFC6020]. 160 3. Basic Structure of Generic YANG Model for OAM 162 As the basis of this document, the generic YANG model for OAM 163 specified as the LIME base model is shown in Figure 1. 165 module: ietf-gen-oam 166 +--rw domains 167 +--rw domain* [technology MD-name-string] 168 +--rw technology identityref 169 +--rw MD-name-string MD-name-string 170 ... 171 +--rw MAs 172 +--rw MA* [MA-name-string] 173 +--rw MA-name-string MA-name-string 174 ... 175 +--rw MEP* [mep-name] 176 | +--rw mep-name MEP-name 177 | ... 178 | +--rw session* [session-cookie] 179 | ... 180 +--rw MIP* [interface] 181 | +--rw interface if:interface-ref 182 +--rw related-oam-layer* [offset] 183 ... 184 rpcs: 185 +---x continuity-check 186 | ... 187 +---x continuity-verification {connectivity-verification}? 188 | ... 189 +---x path-discovery 190 ... 191 notifications: 192 +---n defect-condition-notification 193 ... 195 Figure 1: Structure of the Generic LIME Base Model 197 The generic YANG OAM model comprises three definitions for 198 configuration and operational state data: 200 o configuration model definition; 202 o Remote procedure call (RPC) definition; 204 o and notification definition. 206 The configuration model definition provides hierarchical structure to 207 describe fault domain (i.e., maintenance domain), test point (i.e., 208 maintenance point), technology type, layering, and session context 209 for trouble-shooting. This basic configuration model enables users 210 to select corresponding layers and nodes serving as anchor points to 211 define their specific technology OAM YANG models. 213 The RPC definition provides uniform APIs for common OAM functions 214 such as continuity check, connectivity verification, path discovery, 215 performance measurement and their equivalents. These APIs are used 216 by the network management system (NMS) to control OAM tools and 217 functionalities on network elements for measuring and monitoring the 218 data plane (e.g., LSP Ping, IP performance measurement protocol) and 219 troubleshooting (e.g., fault localization). These OAM tools 220 activation can be pro-active and on-demand. 222 The notification definition also provides a uniform API to report 223 defects, faults, and network failures at different layers. This API 224 is used by network elements to report to the network management 225 system (NMS). The content of each notification includes the fault 226 domain and the test point(s) that detected the fault and may generate 227 the error message. This API must be activated proactively. 229 3.1. Performance Management Support 231 To support OAM Performance Management, the generic YANG Data Model 232 for OAM needs to be extended by adding loss and delay measurements 233 support with the following model structure: 235 /* MEP Configuration extension */ 236 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP: 237 +--rw delay-measurements? 238 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP: 239 +--rw loss-measurements? 240 /* New rpcs */ 241 rpcs: 242 +---x create-loss-measurement 243 | ... 244 +---x abort-loss-measurement 245 | ... 246 +---x create-delay-measurement 247 | ... 248 +---x abort-delay-measurement 249 | ... 251 Both pro-active and on-demand loss and delay measurement are 252 supported by augument MEP configuration and RPCs with session type 253 parameter. The details of Performance management extension is 254 specified in the [I-D.wang-lime-yang-pm] 256 4. Guidelines For Extending the LIME Base Data Model 258 YANG allows a module to reference external modules to reuse data 259 already defined in those modules. Therefore a technology-specific 260 model can import data definitions from the LIME base model. 262 The import statements are used to make definitions available inside 263 other modules [RFC6020]. Users who want to develop a technology- 264 specific OAM model should import the ietf-gen-oam YANG model with the 265 following statements: 267 module example-ietf-xxx-oam { 268 namespace "urn:foo:params:xml:ns:yang:ietf-xxx-oam"; 269 prefix xxxoam; 271 import ietf-gen-oam { 272 prefix goam; 273 } 274 ...... 276 As described in Section 3, the LIME base model provides a 277 hierarchical structure for configuration, notification and RPCs. 278 Each of these three aspects should be extended with technology- 279 specific features and parameters relating to each technology of 280 interest. 282 YANG allows a module to insert additional nodes into data models, 283 including both the current module (and its submodules) or an external 284 module. This is useful to let specific technologies add specific 285 parameters into the LIME base model. 287 Here we summarize four ways to extend the LIME base model for 288 specific technologies: 290 o Extend structure for configuration with technology specific 291 parameters 293 o Extend structure for notification with technology specific 294 parameters 296 o Extend structure for RPC with technology specific parameters 298 o Define new RPCs and notifications in the technology specific OAM 299 data model. 301 4.1. Extend configuration structure with technology specific parameters 303 As described in [RFC6020], the "augment" statement defines the 304 location in the data model hierarchy where new nodes are inserted. 306 By using the "augment" statement, the hierarchy of configuration 307 structure can be extended with new data nodes that express 308 technology-specific parameters to meet the requirements of the 309 respective technologies. The technology-specific model developer 310 must take care to select the right layers and nodes in the 311 configuration structure as anchor points to insert these additional 312 data. 314 For example, assume a technology- specific OAM YANG model A. An "a" 315 node needs to be inserted within the MA (Maintenance Association): 317 augment /goam:domains/goam:domain/goam:MAs/goam:MA: 318 +--a? foo 320 Corresponding YANG encoding: 322 augment "/goam:domains/goam:domain/goam:MAs/goam:MA"{ 323 leaf a{ 324 type foo 325 description 326 "foo"; 327 } 328 } 330 There are the following five levels in the hierarchy of configuration 331 structure which we can choose as anchor point to insert additional 332 data definitions: 334 o Maintenance domain (MD) at the root level; 336 o Maintenance Association (MA) at the second level; 338 o Maintenance Association Endpoint (MEP) and Maintenance Association 339 Intermediate point(MIP) at the third level; 341 o Session at the fourth level; 343 o Interface at the fifth level; 345 4.1.1. Maintenance domain (MD) at the root level 347 At the Maintenance Domain level, domain data node at root level can 348 be augmented with technology type. [GENYANGOAM] defines a new 349 globally unique, abstract, and untyped "technology-types" base 350 identity by using the "identity" statement. "identity" and 351 "identityref" are used to Identify New Technology Types. Each 352 technology-specific module then can extend technology type in the 353 base model and specifies a corresponding concrete identity using this 354 base: ipv4, ipv6, trill, mpls, etc. 356 4.1.2. Maintenance Association (MA) at the second level 358 At the Maintenance Association level, an MA data node can be 359 augmented with connectivity context information. For example: 361 +--rw MAs 362 +--rw MA* [MA-name-string] 363 ... 364 +--rw (connectivity-context)? 365 | +--:(context-null) 366 | +--rw context-null? Empty 368 Corresponding YANG encoding: 370 choice connectivity-context { 371 default "context-null"; 372 case context-null { 373 description 374 "this is a place holder when no context is needed"; 375 leaf context-null { 376 type empty; 377 description 378 "there is no context defined"; 379 } 380 } 381 description 382 "connectivity context"; 383 } 385 ietf-gen-oam YANG model users who want to define a specific OAM 386 technology model can augment the corresponding choice node by 387 defining a new case to carry technology specific extensions. 389 For example, for a specific OAM technology YANG model A, an "a" node 390 is needed to indicate the connectivity context for this specific OAM 391 technology. To achieve this, it is only necessary to augment the 392 connectivity-context choice node in the ietf-gen-OAM YANG model by 393 defining a "connectivity-context-A" case as: 395 augment /goam:domains/goam:domain/goam:MAs/goam:MA 396 /goam:connectivity-context: 397 +--:(connectivity-context-A) 398 +--a? foo 400 Corresponding YANG encoding: 402 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" 403 +"/goam:connectivity-context" { 404 case connectivity-context-A { 405 leaf a{ 406 type foo;} 407 } 408 } 410 In some case when technology type in the Maintenance Domain level is 411 not sufficient to identify OAM technology with different 412 encapsulation method, MA data node can be further augmented with 413 technology sub type (see an example in the section 5.5). 415 4.1.3. Maintenance Association Endpoint (MEP) at the third level 417 At the Maintenance Association Endpoint level, a MEP data node can be 418 augmented with connectivity-context information, ECMP information and 419 session information respectively. 421 4.1.4. Session at the fourth level 423 At the session level, Session data node can be augmented with 424 technology specific information such as Session type, Session 425 interval,etc. 427 4.1.5. Interface at the fifth level 429 At the interface level under MEP/MIP or under session, the interface 430 data node can be augmented with technology specific information such 431 as context information, interface type,disable/enable button,etc. 433 4.2. Extend RPC structure with technology specific parameters 435 [GENYANGOAM] defines rpc model which abstracts OAM specific commands 436 in a technology independent manner. In this RPC model, three generic 437 RPC commands are specified. By using the "augment" statement,the RPC 438 structure for each OAM command can be extended with new data nodes 439 that express technology-specific OAM command parameters to meet the 440 requirements of the respective technologies. The technology-specific 441 model developer must take care to select the right layers and nodes 442 in the RPC structure as anchor points to insert these additional 443 data. There are two places which we can choose as anchor point to 444 insert additional data definitions: 446 o Input data node 448 Input data node can be augmented with technology type, sub-command 449 type, session type and other technology specific parameters. Here is 450 an example of sub-command type: 452 [GENYANGOAM] defines a "command-sub-type" abstract identity for 453 different RPC commands, e.g., to distinguish the types of IP ping 454 [RFC792], LSP ping [RFC4379]. Use of this identity is optional for 455 most cases. 457 The corresponding statements are shown as below. 459 identity command-sub-type { 460 description 461 "defines different rpc command subtypes, e.g rfc792 IP 462 ping, rfc4379 LSP ping, this is 463 optional for most cases"; 464 } 466 identity icmp-rfc792 { 467 base command-sub-type; 468 description 469 "Defines the command subtypes for ICMPv4 ping"; 470 reference "RFC 792"; 471 } 473 identity icmp-rfc4443 { 474 base command-sub-type; 475 description 476 "Defines the command subtypes for ICMPv6 ping"; 477 reference "RFC 4443"; 478 } 480 identity icmp-rfc4379 { 481 base command-sub-type; 482 description 483 "Defines the command subtypes for LSP ping"; 484 reference "RFC 4379"; 485 } 487 o Output data node 489 Similarly, output data nod can be augmented with technology specific 490 test results information collected by executing OAM command. 492 4.3. Extend Notification structure with technology specific parameters 494 [GENYANGOAM] defines one notification model which abstracts defects 495 notification in a technology independent manner. By using the 496 "augment" statement,the notification structure can be extended with 497 new data nodes that express technology-specific notification 498 parameters to meet the requirements of the respective technologies. 499 The technology-specific model developer must take care to select the 500 right layers and nodes in the notification structure as anchor points 501 to insert these additional data. 503 4.4. Define New RPCs and Notifications 505 The LIME base model presents three basic RPCs: continuity check, 506 connectivity verification and path discovery. Technology-specific 507 OAM models can either extend the existing RPCs and notifications 508 defined in the LIME base model or define new RPCs and notifications 509 if generic RPCs and notifications cannot be reused to meet their 510 requirements. 512 For example, a Multicast Tree Verification (MTV) [TRILLOAMYANG] RPC 513 command is defined in the TRILL OAM model to verify connectivity as 514 well as data-plane and control-plane integrity of TRILL multicast 515 forwarding as follows: 517 RPCs: 518 +---x mtv 519 +--ro input 520 | +--ro technology identityref 521 | +--ro MD-name-string MD-name-string 522 | +--ro MA-name-string? MA-name-string 523 | ... 524 +--ro output 525 +--ro response* [mep-address mep-id] 526 +--ro hop-count? uint8 527 +--ro mep-id tril-rb-nickname 528 +--ro mep-address tril-rb-nickname 529 ... 531 5. Applicability of LIME Model to Various Technologies 533 As mentioned above, the ietf-gen-oam model describes the abstract 534 common core configuration, statistics, RPCs, and notifications for 535 layer independent OAM management. 537 Following guidelines stated in Section 4, ietf-gen-oam YANG model 538 users can augment this base model by defining and adding new data 539 nodes with technology specific functions and parameters into proper 540 anchor points of the ietf-gen-oam model, so as to develop a 541 technology-specific OAM model. 543 With these guidelines in hand, this section further demonstrates the 544 usability of the ietf-gen-oam YANG model to various OAM technologies. 545 Note that, in this section, we only present several snippets of 546 technology-specific data model extensions for illustrative purposes. 547 The complete model extensions should be worked on in respective 548 protocol working groups. 550 5.1. Generic YANG Model extension for IP OAM 552 5.1.1. MD Configuration Extension 554 MD level configuration parameters are management information which 555 can be inherited in the TRILL OAM model and set by LIME base model as 556 default values. For example domain name can be set to area-ID in the 557 IP OAM case. In addition, at the Maintenance Domain level, domain 558 data node at root level can be augmented with technology type. 560 Note that MD level configuration parameters provides context 561 information for management system to correlate faults, defects, 562 network failures with location information, which helps quickly 563 identify root causes of network failures.MD level configuration 564 parameters MUST not be carried using IP Ping and traceroute protocol 565 since IP Ping and traceroute doesn't support transport of these 566 management information. 568 5.1.1.1. Technology Type Extension 570 The technology types ipv4 and ipv6 have already been defined in the 571 LIME base model. Therefore no technology type extension is required 572 in the IP OAM model. 574 5.1.2. MA Configuration Extension 576 MA level configuration parameters are management information which 577 can be inherited in the IP OAM model and set by LIME base model as 578 default values. In addition, at the Maintenance Association(MA) 579 level, MA data node at the second level can be augmented with 580 connectivity-context extension. 582 Note that MA level configuration parameters provides context 583 information for management system to correlate faults, defects, 584 network failures with location information, which helps quickly 585 identify root causes of network failures.MA level configuration 586 parameters MUST not be carried using IP Ping and traceroute protocol 587 since IP Ping and traceroute doesn't support transport of these 588 management information. 590 5.1.2.1. Connectivity-Context Extension 592 In IP OAM, one example of the connectivity-context is a 12 bit VLAN 593 ID. The LIME base model defines a placeholder for connectivity- 594 context. This allows other technologies to easily augment it to 595 include technology specific extensions. The snippet below depicts an 596 example of augmenting context-id to include VLAN ID. 598 augment /goam:domains/goam:domain/goam:MAs/goam:MA 599 /goam:MEP/goam:connectivity-context: 600 +--:(context-id-vlan) 601 +--rw context-id-vlan? vlan 602 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 603 /goam:session/goam:connectivity-context: 604 +--:(context-id-vlan) 605 +--rw context-id-vlan? vlan 607 5.1.3. MEP Configuration Extension 609 MEP configuration in the LIME base model already supports configuring 610 the interface on which the MEP is located with an IP address. There 611 is no additional MEP configuration extension needed for IP OAM. 613 However, IP Ping, traceroute do not use the MEPID in their message 614 headers. Therefore it is important to have method to derive the 615 MEPID in an automatic manner with no user intervention. 617 5.1.3.1. ECMP extension 619 The flow-entropy parameter in the LIME OAM configuration model is an 620 optional parameter. Since standard IP OAM protocols, e.g., IP Ping 621 and Traceroute, don't support ECMP path selection, the flow-entropy 622 parameter does not need to be supported in the IP OAM model. 624 5.1.4. RPC Extension 626 Technology type in the RPC definition has already been defined in the 627 LIME OAM base model. Therefore no technology type extension is 628 required in the RPC definition. For IP OAM, IP Ping and IP 629 Traceroute RPCs need to be supported. For the IP OAM model, the 630 continuity-check RPC with IPv4 or IPv6 as technology type can be 631 mapped to the IP Ping RPC, while the path-discovery RPC with IPv4 or 632 IPv6 as technology type can be mapped to IP Traceroute. 634 5.1.5. Performance Monitoring Extension 636 Editor Note: IP performance measurement (IPPM) and IP Ping and 637 Traceroute are discussed separately based on the [RFC7276] 638 classification of OAM technologies. Although IPPM and IP OAM are 639 both applied to the IP network, based on Table 4 of [RFC7276], IP OAM 640 does not support performance measurement. It is necessary to use 641 OWAMP and TWAMP, defined in IPPM, for that purpose. 643 5.1.5.1. MEP PM Configuration Extension 645 To support IP performance measurement, MEP configuration in the LIME 646 base model can be extended with: 648 o loss-stats-group: grouping object for loss measurement session 649 statistics. 651 o measurement-timing-group: grouping object used for proactive and 652 on-demand scheduling of PM measurement sessions. 654 o delay-measurement-configuration-group: grouping configuration 655 object for the delay measurement function. 657 o delay-measurement-stats-group: grouping object for delay 658 measurement session statistics. 660 o loss-measurement-configuration-group: grouping configuration 661 object for the loss measurement function. 663 o loss-measurement-stats-group: grouping object for loss measurement 664 session statistics. 666 5.1.5.2. RPC PM Extension 668 To support IP performance measurement, it is recommended that four 669 RPCs are defined in the IPPM model: 671 o create-loss-measurement RPC: allows scheduling of one-way or two- 672 way on-demand or proactive performance monitoring loss measurement 673 sessions. 675 o abort-loss-measurement RPC: allows aborting of currently running 676 or scheduled loss measurement session. 678 o create-delay-measurement RPC: allows scheduling of one-way or two- 679 way on-demand or proactive performance monitoring delay 680 measurement sessions. 682 o abort-delay-measurement RPC: allows aborting of currently running 683 or scheduled delay measurement sessions. 685 5.2. Generic YANG Model extension for TRILL OAM 687 5.2.1. MD Configuration Extension 689 MD level configuration parameters are management information which 690 can be inherited in the TRILL OAM model and set by LIME base model as 691 default values. For example domain name can be set to area-ID in the 692 TRILL OAM case. In addition, at the Maintenance Domain level, domain 693 data node at root level can be augmented with technology type. 695 Note that MD level configuration parameters provides context 696 information for management system to correlate faults, defects, 697 network failures with location information, which helps quickly 698 identify root causes of network failures. 700 5.2.1.1. Technology Type Extension 702 No TRILL technology type has been defined in the LIME base model. 703 Therefore a technology type extension is required in the TRILL OAM 704 model. The technology type "trill" is defined as an identity that 705 augments the base "technology-types" defined in the LIME base model: 707 identity trill{ 708 base goam:technology-types; 709 description 710 "trill type"; 711 } 713 5.2.2. MA Configuration Extension 715 MA level configuration parameters are management information which 716 can be inherited in the TRILL OAM model and set by LIME base model as 717 default values. In addition, at the Maintenance Association(MA) 718 level, MA data node at the second level can be augmented with 719 connectivity-context extension. 721 Note that MA level configuration parameters provides context 722 information for management system to correlate faults, defects, 723 network failures with location information, which helps quickly 724 identify root causes of network failures. 726 5.2.2.1. Connectivity-Context Extension 728 In TRILL OAM, one example of connectivity-context is either a 12 bit 729 VLAN ID or a 24 bit Fine Grain Label. The LIME base model defines a 730 placeholder for context-id. This allows other technologies to easily 731 augment that to include technology specific extensions. The snippet 732 below depicts an example of augmenting connectivity-context to 733 include either VLAN ID or Fine Grain Label. 735 augment /goam:domains/goam:domain/goam:MAs 736 /goam:MA /goam:connectivity-context: 737 +--:(connectivity-context-vlan) 738 | +--rw connectivity-context-vlan? vlan 739 +--:(connectivity-context-fgl) 740 +--rw connectivity-context-fgl? fgl 742 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 743 /goam:session/goam:connectivity-context: 744 +--:(connectivity-context-vlan) 745 | +--rw connectivity-context-vlan? vlan 746 +--:(connectivity-context-fgl) 747 +--rw connectivity-context-fgl? fgl 749 5.2.3. MEP Configuration Extension 751 The MEP configuration definition in the LIME base model already 752 supports configuring the interface of MEP with either MAC address or 753 IP address. In addition, the MEP address can be represented using a 754 2 octet RBridge Nickname in TRILL OAM . Hence, the TRILL OAM model 755 augments the MEP configuration in base model to add a nickname case 756 into the MEP address choice node as follows: 758 augment /goam:domains/goam:domain/goam:MAs 759 /goam:MA/ goam:MEP/goam:mep-address: 760 +--:( mep-address-trill) 761 | +--rw mep-address-trill? tril-rb-nickname 763 In addition, at the Maintenance Association Endpoint(MEP) level, MEP 764 data node at the third level can be augmented with ECMP extension. 766 5.2.3.1. ECMP Extension 768 The flow-entropy parameter in the LIME base model is an optional 769 parameter. Since TRILL supports ECMP path selection, flow-entropy in 770 TRILL is defined as a 96 octet field. The snippet below illustrates 771 its extension. 773 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 774 /goam:flow-entropy: 775 +--:(flow-entropy-trill) 776 +--rw flow-entropy-trill? flow-entropy-trill 777 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 778 /goam:session/goam:flow-entropy: 779 +--:(flow-entropy-trill) 780 +--rw flow-entropy-trill? flow-entropy-trill 782 5.2.4. RPC Extension 784 In the TRILL OAM YANG model, the continuity-check and path-discovery 785 RPC commands are extended with TRILL specific requirements. The 786 snippet below illustrates the TRILL OAM RPC extension. 788 augment /goam:continuity-check/goam:input: 789 +--ro (out-of-band)? 790 | +--:(ipv4-address) 791 | | +--ro ipv4-address? inet:ipv4-address 792 | +--:(ipv6-address) 793 | | +--ro ipv6-address? inet:ipv6-address 794 | +--:(trill-nickname) 795 | +--ro trill-nickname? tril-rb-nickname 796 +--ro diagnostic-vlan? boolean 797 augment /goam:continuity-check/goam:input/goam:flow-entropy: 798 +--:(flow-entropy-trill) 799 +--ro flow-entropy-trill? flow-entropy-trill 800 augment /goam:continuity-check/goam:output: 801 +--ro upstream-rbridge? tril-rb-nickname 802 +--ro next-hop-rbridge* tril-rb-nickname 803 augment /goam:path-discovery/goam:input: 804 +--ro (out-of-band)? 805 | +--:(ipv4-address) 806 | | +--ro ipv4-address? inet:ipv4-address 807 | +--:(ipv6-address) 808 | | +--ro ipv6-address? inet:ipv6-address 809 | +--:(trill-nickname) 810 | +--ro trill-nickname? tril-rb-nickname 811 +--ro diagnostic-vlan? boolean 812 augment /goam:path-discovery/goam:input/goam:flow-entropy: 813 +--:(flow-entropy-trill) 814 +--ro flow-entropy-trill? flow-entropy-trill 815 augment /goam:path-discovery/goam:output/goam:response: 816 +--ro upstream-rbridge? tril-rb-nickname 817 +--ro next-hop-rbridge* tril-rb-nickname 819 5.2.5. Performance Management (PM) Extension 821 5.2.5.1. MEP PM Configuration Extension 823 To support performance measurement for TRILL, MEP configuration in 824 the LIME base model can be extended with: 826 o loss-stats-group: grouping statistics object for TRILL Loss 827 measurement sessions; 829 o measurement-timing-group: grouping object used for proactive and 830 on-demand scheduling of PM measurement sessions; 832 o delay-measurement-configuration-group: grouping configuration 833 object for TRILL delay measurement function; 835 o delay-measurement-stats-group: grouping statistics object for 836 TRILL delay measurement sessions. 838 5.2.5.2. RPC PM Extension 840 To support performance measurement for TRILL, it is recommended that 841 four new RPCs are defined in the TRILL OAM PM model: 843 o create-loss-measurement RPC: allows scheduling of one-way or two- 844 way on-demand or proactive performance monitoring loss measurement 845 sessions. 847 o abort-loss-measurement RPC: allows aborting of currently running 848 or scheduled loss measurement sessions. 850 o create-delay-measurement RPC: allows scheduling of one-way or two- 851 way on-demand or proactive performance monitoring delay 852 measurement sessions. 854 o abort-delay-measurement RPC: allows aborting of currently running 855 or scheduled delay measurement sessions. 857 5.2.6. Usage example 859 This part gives a simple example of implementing the TRILL OAM model 860 onto network devices. 862 The scenario is shown in Figure 2, in which there are two companies: 863 A and B. Both have departments in City 1 and City 2. Meanwhile, 864 different departments within the same company should be able to 865 communicate with each other. However, the communication services of 866 these two companies should be separated from each other. 868 To meet the requirements above, two Ethernet Lease line, E-Line-1 and 869 E-Line-2, are set between NE1 and NE3: to isolate the communication 870 traffic between two companies. VLAN 100 associates port 3-EFF8-1 of 871 NE1 facing with company A while VLAN 200 associates port 3-EF8-2 of 872 NE1 facing with company B. For network maintenance, NE1, NE2 and NE3 873 are within a same maintenance domain: MD1. Two maintenance 874 associations MA1 and MA2 are configured and stand for E-Line-1 and 875 E-Line-2 under MD1. The MAC addresses of NE1, NE2, NE3 are MAC-FOO1, 876 MAC-FOO2, MAC-FOO3 respectively. 878 +------+ +-----+ +------+ 879 | | | | | | 880 | NE1 +-------| NE2 |-------+ NE3 | 881 | | | | | | 882 +-------+--+---+ +-----+ +---+--+---------+ 883 3-EFF8-1| |3-EFF8-2 | | 884 | | | | 885 +-+-+ +--++ +-+-+ +-+-+ 886 | | | | | | | | 887 +---+ +---+ +---+ +---+ 888 A B A B 889 CITY1 CITY2 891 Figure 2: TRILL OAM scenario 893 5.2.6.1. TRILL OAM Extension 895 To fulfill the TRILL OAM configuration, the LME base model should be 896 extended by augmenting the connectivity-context and inserting a port 897 node in the MEP list. The snippet below illustrates an example of 898 TRILL OAM model extension. 900 augment /goam:domains/goam:domain/goam:MAs 901 /goam:MA/goam:MEP /goam:mep-address: 902 +--:( mep-address-trill) 903 | +--rw mep-address-trill? tril-rb-nickname 904 augment /goam:domains/goam:domain/goam:MAs/goam:MA 905 /goam:connectivity-context: 906 +--:(connectivity-context-vlan) 907 | +--rw connectivity-context-vlan? vlan 908 +--:(connectivity-context-fgl) 909 +--rw connectivity-context-fgl? fgl 911 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 912 /goam:session/goam:connectivity-context: 913 +--:(connectivity-context-vlan) 914 | +--rw connectivity-context-vlan? vlan 915 +--:(connectivity-context-fgl) 916 +--rw connectivity-context-fgl? fgl 917 augment /goam:domains/goam:domain/goam:MAs/goam:MA 918 /goam:MEP/goam:flow-entropy: 919 +--:(flow-entropy-trill) 920 +--rw flow-entropy-trill? flow-entropy-trill 921 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP 922 /goam:session/goam:flow-entropy: 923 +--:(flow-entropy-trill) 924 +--rw flow-entropy-trill? flow-entropy-trill 925 augment /goam:continuity-check/goam:input: 926 +--ro (out-of-band)? 927 | +--:(ipv4-address) 928 | | +--ro ipv4-address? inet:ipv4-address 929 | +--:(ipv6-address) 930 | | +--ro ipv6-address? inet:ipv6-address 931 | +--:(trill-nickname) 932 | +--ro trill-nickname? tril-rb-nickname 933 +--ro diagnostic-vlan? boolean 934 augment /goam:continuity-check/goam:input/goam:flow-entropy: 935 +--:(flow-entropy-trill) 936 +--ro flow-entropy-trill? flow-entropy-trill 937 augment /goam:continuity-check/goam:output: 938 +--ro upstream-rbridge? tril-rb-nickname 939 +--ro next-hop-rbridge* tril-rb-nickname 940 augment /goam:path-discovery/goam:input: 941 +--ro (out-of-band)? 942 | +--:(ipv4-address) 943 | | +--ro ipv4-address? inet:ipv4-address 944 | +--:(ipv6-address) 945 | | +--ro ipv6-address? inet:ipv6-address 946 | +--:(trill-nickname) 947 | +--ro trill-nickname? tril-rb-nickname 948 +--ro diagnostic-vlan? boolean 949 augment /goam:path-discovery/goam:input/goam:flow-entropy: 950 +--:(flow-entropy-trill) 951 +--ro flow-entropy-trill? flow-entropy-trill 952 augment /goam:path-discovery/goam:output/goam:response: 953 +--ro upstream-rbridge? tril-rb-nickname 954 +--ro next-hop-rbridge* tril-rb-nickname 956 5.2.6.2. Corresponding XML Instance Example 958 This section gives an example of the corresponding XML instance for 959 devices to implement the example TRILL OAM data models in 960 Section 5.2.6.1. 962 963 964 ethernet 965 MD1 966 967 968 MA1 969 970 971 100 972 973 974 975 NE1 976 977 978 00-1E-4C-84-22-F1 979 980 981 982 984 NE3 985 3-EFF8-1 986 987 988 00-1E-4C-84-22-F3 989 990 991 992 NE2 993 994 995 MA2 996 997 998 200 999 1000 1001 1002 NE1 1003 1004 1005 00-1E-4C-84-22-F1 1006 1007 1008 1009 1010 NE3 1011 1012 1013 00-1E-4C-84-22-F3 1014 1015 1016 1017 NE2 1018 1019 1020 1021 1023 5.3. Generic YANG Model extension for MPLS OAM 1025 5.3.1. MD Configuration Extension 1027 MD level configuration parameters are management information which 1028 can be inherited in the MPLS OAM model and set by LIME base model as 1029 default values. For example domain name can be set to area-ID in the 1030 MPLS OAM case. In addition, at the Maintenance Domain level, domain 1031 data node at root level can be augmented with technology type and 1032 sub-technology type. 1034 Note that MD level configuration parameters provides context 1035 information for management system to correlate faults, defects, 1036 network failures with location information, which helps quickly 1037 identify root causes of network failures. MD level configuration 1038 parameters MUST not be carried using MPLS OAM protocol(e.g., LSP 1039 Ping) since MPLS OAM protocol doesn't support transport of these 1040 management information. 1042 5.3.1.1. Technology Type Extension 1044 No MPLS technology type has been defined in the LIME base model, 1045 hence it is required in the MPLS OAM model. The technology type 1046 "mpls" is defined as an identity that augments the base "technology- 1047 types" defined in the LIME base model: 1049 identity mpls{ 1050 base goam:technology-types; 1051 description 1052 "mpls type"; 1053 } 1055 5.3.1.2. Sub Technology Type Extension 1057 In MPLS, since different encapsulation types such as IP/UDP 1058 Encapsulation, PW-ACH encapsulation can be employed, the "technology- 1059 sub-type" data node is defined and added into the MPLS OAM model to 1060 further identify the encapsulation types within the MPLS OAM model. 1061 Based on it, we also define a technology sub-type for IP/UDP 1062 encapsulation and PW-ACH encapsulation. Other Encapsulation types 1063 can be defined in the same way. 1065 identity technology-sub-type { 1066 description 1067 "certain implementations can have different 1068 encapsulation types such as ip/udp, pw-ach and so on. 1069 Instead of defining separate models for each 1070 encapsulation, we define a technology sub-type to 1071 further identify different encapsulations. Technology 1072 sub-type is associated at the MA level"; 1073 } 1075 identity technology-sub-type-udp { 1076 base technology-sub-type; 1077 description 1078 "technology sub-type is IP/UDP encapsulation"; 1079 } 1081 identity technology-sub-type-ach { 1082 base technology-sub-type; 1083 description 1084 "technology sub-type is PW-ACH encapsulation"; 1085 } 1086 } 1088 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { 1089 leaf technology-sub-type { 1090 type identityref { 1091 base technology-sub-type; 1092 } 1093 } 1094 } 1096 5.3.2. MA Configuration Extension 1098 MA level configuration parameters are management information which 1099 can be inherited in the MPLS- OAM model and set by LIME base model as 1100 default values. In addition, at the Maintenance Association(MA) 1101 level, MA data node at the second level can be augmented with 1102 connectivity-context extension. 1104 Note that MA level configuration parameters provides context 1105 information for management system to correlate faults, defects, 1106 network failures with location information, which helps quickly 1107 identify root causes of network failures. MA level configuration 1108 parameters MUST not be carried using MPLS OAM protocol(e.g., LSP 1109 Ping) since MPLS OAM protocol doesn't support transport of these 1110 management information. 1112 5.3.2.1. Connectivity-Context Extension 1114 In MPLS, one example of context-id is a 20 bit MPLS label. The LIME 1115 base model defines a placeholder for context-id. This allows other 1116 technologies to easily augment that to include technology specific 1117 extensions. The snippet below depicts an example of augmenting 1118 context-id to include per VRF MPLS labels in IP VPN or per CE MPLS 1119 labels in IP VPN. 1121 augment "/goam:domains/goam:domain/goam:MAs/goam:MA 1122 /goam:connectivity-context" 1123 { 1124 case connectivity-context-mpls { 1125 leaf vrf-label { 1126 type vrf-label; 1127 } 1128 } 1129 } 1131 5.3.3. MEP Configuration Extension 1133 In MPLS, the MEP address is either an IPv4 or IPV6 address in case 1134 IP/UDP encapsulation. MEP-ID is either a 2 octet unsigned integer 1135 value in case IP/UDP encapsulation or a variable length label value 1136 in case of G-ACH encapsulation. In the LIME base model, MEP-ID is 1137 defined as a variable length label value and the same definition can 1138 be used for MPLS with no further modification. In addition, at the 1139 Maintenance Association Endpoint(MEP) level, MEP data node at the 1140 third level can be augmented with Session extension and interface 1141 extension. 1143 5.3.3.1. ECMP Extension 1145 Since MPLS supports ECMP path selection, the flow-entropy should be 1146 defined in MPLS OAM model. Technology type is used to extend the 1147 YANG model to specific usage. 1149 augment "/goam:domains/goam:domain/goam:MAs/goam:MA 1150 /goam:flow-entropy" { 1151 case flow-entropy-mpls { 1152 leaf flags-mpls { 1153 type flags-mpls; 1154 } 1155 leaf flow-entropy-mpls{ 1156 type flow-entropy-mpls; 1157 } 1158 } 1159 } 1161 5.3.3.2. Per interface Configuration Extension 1163 TBC. 1165 5.3.4. RPC Extension 1167 5.3.4.1. CV extension for LSP Ping 1169 5.3.4.2. Path Discovery Extension for LSP Ping 1171 5.3.4.3. New RPC Alarm Indication Signal (AIS) 1173 See [RFC6427]. 1175 5.3.4.4. New RPC for Lock Report (LKR) 1177 See [RFC6427]. 1179 5.3.5. Performance Management Extension 1181 5.3.5.1. MEP Configuration Extension 1183 To support performance monitoring for MPLS, MEP configuration in the 1184 LIME base model can be extended with: 1186 o TBC. 1188 5.3.5.2. RPC Extension 1190 To support performance monitoring for MPLS, it is recommended that 1191 five new RPCs are defined in the MPLS OAM PM model: 1193 o MPLS Direct Loss Measurement (DLM) RPC [RFC6374]; 1195 o MPLS Inferred Loss Measurement (ILM) RPC [RFC6374]; 1196 o MPLS Delay Measurement (DM) RPC [RFC6374]; 1198 o MPLS Direct Loss and Delay Measurement RPC [RFC6374]; 1200 o MPLS Inferred Loss and Delay Measurement RPC [RFC6374]. 1202 5.3.6. Usage Example 1204 In the MPLS tunnel scenario (see Figure 3): tunnel_1 is a static LSP 1205 tunnel passing through NE1-NE2-NE4. It is used to perform LSP PING. 1206 tunnel_3 is another static LSP tunnel passing through NE4-NE2-NE1, 1207 used to bring back the LSP PING result. tunnel_2 is a third static 1208 LSP tunnel passing through NE1-NE3-NE4, used to perform LSP 1209 Traceroute. tunnel_4 is a fourth static LSP tunnel passing through 1210 NE4-NE3-NE1, used to bring back the LSP Traceroute result. 1212 +-------+ 1213 | | 1214 +--------------->+ NE2 +----------------+ 1215 | ...............| |<.............. | 1216 | . +-------+ . | 1217 | . . | 1218 | v . v 1219 +---+---+ +---+---+ 1220 | | | | 1221 | NE1 | | NE4 | 1222 | | | | 1223 +---+---+ +---+--^+ 1224 . ^ | . 1225 . | | . 1226 . | +-------+ | . 1227 . | | | | . 1228 . +----------------+ NE3 +<---------------+ . 1229 ....................| |.................... 1230 +-------+ 1232 ----- forward direction LSP tunnel 1233 ......backward direction LSP tunnel 1235 Figure 3: MPLS OAM scenario 1237 5.3.6.1. MPLS OAM Model Extension 1239 TBD. 1241 5.3.6.2. Corresponding XML Instance Example 1243 TBD. 1245 5.4. Generic YANG Model extension for MPLS-TP OAM 1247 5.4.1. MD Configuration Extension 1249 MD level configuration parameters are management information which 1250 can be inherited in the MPLS-TP OAM model and set by LIME base model 1251 as default values. For example domain name can be set to area-ID or 1252 the provider's Autonomous System Number (ASN) [RFC6370] in the MPLS- 1253 TP OAM case. In addition, at the Maintenance Domain level, domain 1254 data node at root level can be augmented with technology type and 1255 sub-technology type. 1257 Note that MD level configuration parameters provides context 1258 information for management system to correlate faults, defects, 1259 network failures with location information, which helps quickly 1260 identify root causes of network failures 1262 5.4.1.1. Technology Type Extension 1264 No MPLS-TP technology type has been defined in the LIME base model, 1265 hence it is required in the MPLS OAM model. The technology type 1266 "mpls-tp" is defined as an identity that augments the base 1267 "technology- types" defined in the LIME base model: 1269 identity mpls-tp{ 1270 base goam:technology-types; 1271 description 1272 "mpls-tp type"; 1273 } 1275 5.4.1.2. Sub Technology Type Extension 1277 In MPLS-TP, since different encapsulation types such as IP/UDP 1278 Encapsulation, PW-ACH encapsulation can be employed, the "technology- 1279 sub-type" data node is defined and added into the MPLS OAM model to 1280 further identify the encapsulation types within the MPLS-TP OAM 1281 model. Based on it, we also define a technology sub-type for IP/UDP 1282 encapsulation and PW-ACH encapsulation. Other Encapsulation types 1283 can be defined in the same way. 1285 identity technology-sub-type { 1286 description 1287 "certain implementations can have different 1288 encapsulation types such as ip/udp, pw-ach and so on. 1289 Instead of defining separate models for each 1290 encapsulation, we define a technology sub-type to 1291 further identify different encapsulations. Technology 1292 sub-type is associated at the MA level"; 1293 } 1295 identity technology-sub-type-udp { 1296 base technology-sub-type; 1297 description 1298 "technology sub-type is IP/UDP encapsulation"; 1299 } 1301 identity technology-sub-type-ach { 1302 base technology-sub-type; 1303 description 1304 "technology sub-type is PW-ACH encapsulation"; 1305 } 1306 } 1308 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { 1309 leaf technology-sub-type { 1310 type identityref { 1311 base technology-sub-type; 1312 } 1313 } 1314 } 1316 5.4.2. MA Configuration Extension 1318 MA level configuration parameters are management information which 1319 can be inherited in the MPLS-TP OAM model and set by LIME base model 1320 as default values. One example of MA Name is MEG LSP ID or MEG 1321 Section ID or MEG PW ID[RFC6370]. In addition, at the Maintenance 1322 Association(MA) level, MA data node at the second level can be 1323 augmented with connectivity-context extension. 1325 Note that MA level configuration parameters provides context 1326 information for management system to correlate faults, defects, 1327 network failures with location information, which helps quickly 1328 identify root causes of network failures. 1330 5.4.2.1. Connectivity-Context Extension 1332 In MPLS-TP, one example of context-id is a 20 bit MPLS label. The 1333 LIME base model defines a placeholder for context-id. This allows 1334 other technologies to easily augment that to include technology 1335 specific extensions. The snippet below depicts an example of 1336 augmenting context-id to include per VRF MPLS labels in IP VPN 1337 [RFC4364] or per CE MPLS labels in IP VPN [RFC4364]. 1339 augment "/goam:domains/goam:domain/goam:MAs/goam:MA 1340 /goam:connectivity-context" 1341 { 1342 case connectivity-context-mpls { 1343 leaf vrf-label { 1344 type vrf-label; 1345 } 1346 } 1347 } 1349 5.4.3. MEP Configuration Extension 1351 In MPLS-TP, MEP-ID is either a variable length label value in case of 1352 G-ACH encapsulation or a 2 octet unsigned integer value in case of 1353 IP/UDP encapsulation. One example of MEP-ID is MPLS-TP LSP_MEP_ID 1354 [RFC6370]. In case of using IP/UDP encapsulation, the MEP address 1355 can be either an IPv4 or IPV6 address. In the LIME base model, MEP- 1356 ID is defined as a variable length label value and the same 1357 definition can be used for MPLS-TP with no further modification. In 1358 addition, at the Maintenance Association Endpoint(MEP) level, MEP 1359 data node at the third level can be augmented with Session extension 1360 and interface extension. 1362 5.4.3.1. ECMP Extension 1364 The flow-entropy parameter in the LIME OAM configuration model is an 1365 optional parameter. Standard MPLS-TP OAM protocol does not support 1366 ECMP path selection, so the flow-entropy parameter does not need to 1367 be supported in the MPLS-TP OAM model. 1369 5.4.3.2. Per interface Configuration Extension 1371 TBC. 1373 5.4.4. RPC Extension 1374 5.4.4.1. CC extension for MPLS-TP BFD CC Message 1376 5.4.4.2. CV extension for MPLS-TP BFD CV Message 1378 5.4.4.3. CV extension for On-Demand LSP CV with Non-IP Encapsulation 1380 5.4.4.4. CV extension for On-Demand LSP CV with IP Encapsulation 1382 5.4.4.5. New RPC for Remote Defect Indication 1384 See [RFC6435]. 1386 5.4.4.6. New RPC for Lock Instruct 1388 See [RFC6435]. 1390 5.4.5. Performance Monitoring Extension 1392 5.4.5.1. MEP Configuration Extension 1394 To support performance monitoring for MPLS-TP, MEP configuration in 1395 the LIME base model can be extended with: 1397 o TBC. 1399 5.4.5.2. RPC Extension 1401 To support performance monitoring for MPLS-TP, it is recommended that 1402 five new RPCs are defined in the MPLS OAM PM model: 1404 o MPLS-TP Loss Measurement (LM) Message RPC [RFC6375]; 1406 o MPLS-TP Test Message RPC [RFC6375]; 1408 o MPLS-TP Delay Measurement(DM) Message RPC [RFC6375]; 1410 5.5. Generic YANG Model extension for NVO3 OAM 1412 5.5.1. Technology Type Extension 1414 No NVO3 technology type has been defined in the LIME base model. 1415 Therefore technology type extension is required in the NVO3 OAM 1416 model. The technology type "nvo3" is defined as an identity that 1417 augments the base "technology-types" defined in the LIME base model: 1419 identity nvo3{ 1420 base goam:technology-types; 1421 description 1422 "nvo3 type"; 1423 } 1425 5.5.2. Sub Technology Type Extension 1427 In NVO3, since different overlay encapsulation types such as VxLAN, 1428 NVGRE can be employed, the "technology-sub-type" data node is defined 1429 and added into the NVO3 OAM model to further identify the overlay 1430 types within the NVO3 model. Based on it, we also define a 1431 technology sub-type for VxLAN encapsulation. NVGRE and GENEVE, sub- 1432 types can be defined in the same way. 1434 identity technology-sub-type { 1435 description 1436 "certain implementations such as nvo3 can have different 1437 encapsulation types such as vxlan, nvgre and so on. 1438 Instead of defining separate models for each 1439 encapsulation, we define a technology sub-type to 1440 further identify different encapsulations. Technology 1441 sub-type is associated at the MA level"; 1442 } 1444 identity technology-sub-type-vxlan { 1445 base technology-sub-type; 1446 description 1447 "technology sub-type is vxlan"; 1448 } 1449 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" { 1450 leaf technology-sub-type { 1451 type identityref { 1452 base technology-sub-type; 1453 } 1454 } 1455 } 1457 5.5.3. MEP Configuration Extension 1459 In NVO3, the MEP address is either an IPv4 or IPV6 address. In the 1460 LIME base model, MEP address is defined as an IP address and the same 1461 definition can be used for NVO3 with no further modification. 1463 5.5.4. Connectivity-Context Extension 1465 In NVO3, one example of context-id is a 24 bit virtual network 1466 identifier (VNI). The LIME base model defines a placeholder for 1467 context-id. This allows other technologies to easily augment that to 1468 include technology specific extensions. The snippet below depicts an 1469 example of augmenting context-id to include VNI. 1471 augment "/goam:domains/goam:domain/goam:MAs/goam:MA 1472 /goam:connectivity-context" 1473 { 1474 case connctivity-context-nvo3 { 1475 leaf vni { 1476 type vni; 1477 } 1478 } 1479 } 1481 5.5.5. RPC Extension 1483 In the NVO3 OAM YANG model, the End-Station-Locator RPC command is 1484 defined. This command locates an end-station within the NVO3 1485 deployment. [PTT -- what other tools are applicable??? Presumably 1486 one can use ICMP Ping, LSP Ping for CV, and the PM extensions, per 1487 RFC 7276 Table 4.] 1489 5.5.6. ECMP Extension 1491 In NVO3, flow-entropy depends on the technology sub-type, e.g., 1492 VxLAN. Technology sub-type is used to extend the base model to 1493 specific usage. The snippet below illustrates the extension for 1494 VxLAN. 1496 augment "/goam:domains/goam:domain/goam:MAs/goam:MA 1497 /goam:flow-entropy" { 1498 case flow-entropy-vxlan { 1499 leaf flags-vxlan { 1500 type flags-vxlan; 1501 } 1502 leaf flow-entropy-vxlan { 1503 type flow-entropy-vxlan; 1504 } 1505 } 1506 } 1508 5.6. Generic YANG Model extension for BFD 1510 5.6.1. MD Level configuration extension 1512 MD level configuration parameters are management information which 1513 can be inherited in the BFD model and set by LIME base model as 1514 default values. For example domain name can be set to area-ID in the 1515 BFD case. In addition, at the Maintenance Domain level, domain data 1516 node at root level can be augmented with technology type and sub- 1517 technology type. 1519 Note that MD level configuration parameters provides context 1520 information for management system to correlate faults, defects, 1521 network failures with location information, which helps quickly 1522 identify root causes of network failures. MD level configuration 1523 parameters MUST not be carried using BFD protocol since BFD doesn't 1524 support transport of these management information. 1526 5.6.1.1. Technology Type Extension 1528 No BFD technology type has been defined in the LIME base model. 1529 Therefore a technology type extension is required in the BFD OAM 1530 model. The technology type "bfd" is defined as an identity that 1531 augments the base "technology-types" defined in the LIME base model: 1533 5.6.1.2. Sub Technology Type Extension 1535 In BFD, since different encapsulation types such as IP/UDP 1536 Encapsulation, PW-ACH encapsulation can be employed. 1538 In lime-bfd-extension yang data model, we define an identity: 1539 "technology-sub-type" to further identify the encapsulation types 1540 within the BFD. And based on it, we also define four identity 1541 encapsulation types: 1543 o technology-sub-type-sh-udp: technology sub-type is single hop with 1544 IP/UDP encapsulation; 1546 o technology-sub-type-mh-udp: technology sub-type is multiple hop 1547 with IP/UDP encasulation; 1549 o technology-sub-type-sh-ach: technology sub-type is single hop with 1550 PW-ACH encapsulation; 1552 o technology-sub-type-mh-ach: technology sub-type is multiple hop 1553 with PW-ACH encapsulation; 1555 In MD level, we define a sub-technology leaf with an identityref type 1556 which base on the technology-sub-type: 1558 augment "/goam:domains/goam:domain/" { 1559 leaf sub-technology{ 1560 type identityref { 1561 base technology-sub-type; 1562 } 1563 } 1564 } 1566 5.6.2. MA configuration extension 1568 MA level configuration parameters are management information which 1569 can be inherited in the BFD model and set by LIME base model as 1570 default values. In addition, at the Maintenance Association(MA) 1571 level, MA data node at the second level can be augmented with 1572 connectivity-context extension. 1574 Note that MA level configuration parameters provides context 1575 information for management system to correlate faults, defects, 1576 network failures with location information, which helps quickly 1577 identify root causes of network failures. MA level configuration 1578 parameters MUST not be carried using BFD protocol since BFD doesn't 1579 support transport of these management information. 1581 5.6.2.1. Connectivity-Context Extension 1583 In BFD, one example of context-id is a 32bit local discriminator. 1584 The LIME base model defines a placeholder for context-id. This 1585 allows other technologies to easily augment that to include 1586 technology specific extensions. The snippet below depicts an example 1587 of augmenting context-id to include local discriminator. 1589 augment "/goam:domains/goam:domain/goam:MAs/goam:MA 1590 /goam:connectivity-context" 1591 { 1592 case connectivity-context-bfd { 1593 leaf local-discriminator { 1594 type local-discriminator; 1595 } 1596 } 1597 } 1599 5.6.3. MEP configuration extension 1601 In BFD, the MEP address is either an IPv4 or IPV6 address. MEP-ID is 1602 either a 2 octet unsigned integer value or a variable length label 1603 value. In the LIME base model, MEP-ID is defined as a variable 1604 length label value and the same definition can be used for BFD with 1605 no further modification. In addition, at the Maintenance Association 1606 Endpoint(MEP) level, MEP data node at the third level can be 1607 augmented with Session extension and interface extension. 1609 5.6.3.1. Session Configuration Extension 1611 At the Session level, Session data node at the fouth level can be 1612 augmented with 3 interval parameters and 2 TTL parameters. In 1613 [draft-zheng-bfd-yang], source and destination address in the bfd- 1614 session-cfg can be corresponding to Session configuration extension 1615 as source MEP and destination MEP. 1617 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: 1618 +--rw (interval-config-type)? 1619 | +--:(tx-rx-intervals) 1620 | | +--rw desired-min-tx-interval uint32 1621 | | +--rw required-min-rx-interval uint32 1622 | +--:(single-interval) 1623 | +--rw min-interval uint32 1625 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: 1626 +--rw tx-ttl? ttl 1627 +--rw rx-ttl ttl 1629 5.6.3.2. Interface configuration extension 1631 At the Interface level, interface data node at the fifth level can be 1632 augmented with the same parameters defined in per-interface 1633 configuration of [draft-zheng-bfd-yang]. 1635 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam: outgoing-interface: 1636 +--rw local-multiplier? multiplier 1637 +--rw (interval-config-type)? 1638 | +--:(tx-rx-intervals) 1639 | | +--rw desired-min-tx-interval uint32 1640 | | +--rw required-min-rx-interval uint32 1641 | +--:(single-interval) 1642 | +--rw min-interval uint32 1643 +--rw demand-enabled? boolean 1644 +--rw enable-authentication? boolean 1645 +--rw authentication-parms {bfd-authentication}? 1646 | +--rw key-chain-name? string 1647 | +--rw algorithm? bfd-auth-algorithm 1648 +--rw desired-min-echo-tx-interval? uint32 1649 +--rw required-min-echo-rx-interval? uint32 1651 5.6.3.3. New Notification definition 1653 [GENYANGOAM] defines a notification model which abstracts defects 1654 notification in a technology independent manner.However what BFD is 1655 required is state change notification, therefore a new notification 1656 definition can be specified to meet BFD requirement. 1658 notifications: 1659 +---n state-change-notification 1660 +--ro local-discriminator? uint32 1661 +--ro remote-discriminator? uint32 1662 +--ro new-state? enumeration 1663 +--ro state-change-reason? string 1664 +--ro time-in-previous-state? string 1665 +--ro dest-addr? inet:ip-address 1666 +--ro source-addr? inet:ip-address 1667 +--ro session-cookie? leafref 1668 +--ro technology-sub-type? identityref 1669 +--ro interface? leafref 1670 +--ro echo-enabled? boolean 1672 In this state-change-notification, technology-sub-type is used to 1673 identify whether the notification is for single hop or multi-hop or 1674 other types. 1676 6. Open Issues 1678 Do we need to specify usage examples for each technology-specific 1679 OAM model? 1681 Applicability of LIME base model structure on BFD in details 1682 Applicability of LIME base model structure on MPLS OAM and MPLS-TP 1683 OAM. 1685 7. Security Considerations 1687 TBD. 1689 8. IANA Considerations 1691 This document registers the following namespace URI in the IETF XML 1692 registry. 1694 URI:TBD 1696 9. Acknowledgements 1698 The authors would like to thank Gregory Mirsky for his valuable 1699 comments and suggestions on this document. 1701 10. References 1703 10.1. Normative References 1705 [GENYANGOAM] 1706 Senevirathne , T., Finn, N., Kumar, D., Salam, S., Wu, Q., 1707 and Z. Wang, "Generic YANG Data Model for Operations, 1708 Administration, and Maintenance (OAM)", ID 1709 https://datatracker.ietf.org/doc/draft-tissa-lime-yang- 1710 oam-model/, June 2015. 1712 [IEEE802.1Q] 1713 "Media Access Control (MAC) Bridges and Virtual Bridged 1714 Local Area Networks", IEEE Std 802.1Q-2011, August 2011. 1716 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1717 the Network Configuration Protocol (NETCONF)", RFC 6020, 1718 DOI 10.17487/RFC6020, October 2010, 1719 . 1721 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1722 Bierman, "Network Configuration Protocol (NETCONF)", June 1723 2011. 1725 10.2. Informative References 1727 [I-D.wang-lime-yang-pm] 1728 Wang, Z., Wu, Q., Kumar, D., and T. Taylor, "Generic YANG 1729 Data Model for Operations, Administration, and Maintenance 1730 (OAM) Performance Management", draft-wang-lime-yang-pm-01 1731 (work in progress), November 2015. 1733 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1734 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1735 DOI 10.17487/RFC4379, February 2006, 1736 . 1738 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1739 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1740 Acronym in the IETF", BCP 161, RFC 6291, 1741 DOI 10.17487/RFC6291, June 2011, 1742 . 1744 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1745 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1746 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1747 . 1749 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 1750 Administration, and Maintenance Framework for MPLS-Based 1751 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 1752 September 2011, . 1754 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 1755 3rd, "Transparent Interconnection of Lots of Links (TRILL) 1756 Operations, Administration, and Maintenance (OAM) 1757 Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, 1758 . 1760 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1761 Weingarten, "An Overview of Operations, Administration, 1762 and Maintenance (OAM) Tools", RFC 7276, 1763 DOI 10.17487/RFC7276, June 2014, 1764 . 1766 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 1767 September 1981. 1769 [TRILLOAMYANG] 1770 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1771 and W. Hao, "YANG Data Model for TRILL Operations, 1772 Administration, and Maintenance (OAM) (Work in progress)", 1773 May 2015. 1775 Appendix A. Contributing Authors Infomation 1777 Huub van Helvoort 1778 Hai Gaoming BV 1779 Netherlands 1781 Email: huubatwork@gmail.com 1783 Roland Schott 1784 Deutsche Telekom 1785 Deutsche-Telekom-Allee 7 1786 Darmstadt 64295 1787 Germany 1789 EMail: Roland.Schott@telekom.de 1791 Qin Wu 1792 Huawei 1793 101 Software Avenue, Yuhua District 1794 Nanjing, Jiangsu 210012 1795 China 1797 Email: bill.wu@huawei.com 1799 Deepak Kumar 1800 CISCO Systems 1801 510 McCarthy Blvd 1802 Milpitas, CA 95035 1803 USA 1805 Email: dekumar@cisco.com 1807 Yuji Tochio 1808 Fujitsu 1809 Japan 1811 Email: tochio@jp.fujitsu.com 1813 Guangying Zheng 1814 Huawei 1815 101 Software Avenue, Yuhua District 1816 Nanjing, Jiangsu 210012 1817 China 1819 Email: zhengguangying@huawei.com 1821 Daniel King 1822 Lancaster University 1823 UK 1825 Email: daniel@olddog.co.uk 1827 Zitao Wang 1828 Huawei Technologies,Co.,Ltd 1829 101 Software Avenue, Yuhua District 1830 Nanjing 210012 1831 China 1833 Email: wangzitao@huawei.com 1835 Authors' Addresses 1837 Tom Taylor (editor) 1838 PT Taylor Consulting 1839 Ottawa 1840 Canada 1842 Email: tom.taylor.stds@gmail.com 1844 Yan Zhuang (editor) 1845 Huawei Technologies,Co.,Ltd 1846 101 Software Avenue, Yuhua District 1847 Nanjing 210012 1848 China 1850 Email: zhuangyan.zhuang@huawei.com