idnits 2.17.1 draft-wang-yang-bfd-oam-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 295 has weird spacing: '...nterval uin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 27, 2015) is 3072 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: 'GENYANGOAM' is mentioned on line 328, but not defined == Unused Reference: 'I-D.tissa-lime-yang-oam-model' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC7331' is defined on line 640, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Wang 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: May 30, 2016 D. Kumar 6 Cisco 7 Q. Wu 8 Huawei 9 November 27, 2015 11 LIME base model extension for BFD Support 12 draft-wang-yang-bfd-oam-06 14 Abstract 16 This document discusses how LIME base model is applied to BFD and 17 present an example of YANG Data model for BFD support. The YANG 18 Model presented in this document extends the technology independent 19 YANG model for OAM with BFD technology specifics. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 30, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 57 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Interaction between BFD OAM YANG model and LIME base model . 4 59 4. Generic YANG Model extension for BFD . . . . . . . . . . . . 5 60 4.1. MD Level configuration extension . . . . . . . . . . . . 5 61 4.1.1. Technology Type Extension . . . . . . . . . . . . . . 5 62 4.1.2. Sub Technology Type Extension . . . . . . . . . . . . 5 63 4.2. MA configuration extension . . . . . . . . . . . . . . . 6 64 4.2.1. Connectivity-Context Extension . . . . . . . . . . . 6 65 4.3. MEP configuration extension . . . . . . . . . . . . . . . 6 66 4.3.1. Session Configuration Extension . . . . . . . . . . . 7 67 4.3.2. Interface configuration extension . . . . . . . . . . 7 68 4.3.3. New Notification definition . . . . . . . . . . . . . 8 69 5. Model structure of LIME model extension for BFD . . . . . . . 8 70 6. OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 [draft-ietf-bfd-yang] defines a YANG data model that can be used to 79 configure and manage Bidirectional Forwarding Detection (BFD). This 80 document discusses how LIME base model is applied to BFD and present 81 an example of YANG Data model for BFD support. The YANG Model 82 example presented in this document extends the Generic YANG model for 83 OAM defined in [I-D.ietf-lime-yang-oam- model]. The YANG model 84 example uses the grouping defined in the BFD model [draft-ietf-bfd- 85 yang]. The groupings contain the basic BFD session parameters for 86 applications to use. 88 2. Conventions and Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 The following terms are defined in [RFC6241] and are not redefined 95 here: 97 o client 99 o configuration data 101 o server 103 o state data 105 The following terms are defined in [RFC6020] and are not redefined 106 here: 108 o augment 110 o data model 112 o data node 114 The terminology for describing YANG data models is found in 115 [RFC6020]. 117 2.1. Tree Diagrams 119 A simplified graphical representation of the data model is used in 120 this document. The meaning of the symbols in these diagrams is as 121 follows: 123 Each node is printed as: 125 127 is one of: 128 + for current 129 x for deprecated 130 o for obsolete 132 is one of: 134 rw for configuration data 135 ro for non-configuration data 136 -x for rpcs 137 -n for notifications 139 is the name of the node 141 If the node is augmented into the tree from another module, its name 142 is printed as :. 144 is one of: 146 ? for an optional leaf or choice 147 ! for a presence container 148 * for a leaf-list or list 149 [] for a list's keys 151 is the name of the type for leafs and leaf-lists 153 3. Interaction between BFD OAM YANG model and LIME base model 155 Both BFD model and LIME model can be developed as generic model. 156 LIME model can be extended for BFD to provide consistent 157 configuration, representaion and reporting. Therefore LIME model 158 extension for BFD can be viewed as a BFD application. The consistent 159 configuration and representation can be met by extending LIME 160 configuration structure while the consistent reporting and 161 representation can be met by extending LIME RPC structure or 162 Notification Structure. Generic YANG model for OAM defined in [I- 163 D.ietf-lime-yang-oam-model] can also be used as the basis for all the 164 other OAM YANG models. This allows users to span across OAM tools of 165 different technologies through a uniform API. The following 166 Figure depicts the relationship of BFD OAM YANG model to the Layer 167 Independent OAM YANG Model. 169 +-+-+-+-+-+ 170 | Layer | 171 |independent 172 |OAM YANG | 173 +-+-+-+-+-+ 174 | 175 O 176 | 177 +--------------------------------------------------+ 178 | | | | 179 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 180 | TRILL | | NVO3 | | BFD |. .| foo | 181 |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | 182 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 183 | | | | 184 | | | | 185 | | | | 186 +----------------------------------------------------+ 187 | Uniform API | 188 +----------------------------------------------------+ 190 Relationship of BFD OAM YANG model to technology independent OAM YANG 191 model 193 4. Generic YANG Model extension for BFD 195 4.1. MD Level configuration extension 197 MD level configuration parameters are management information which 198 can be inherited in the BFD model and set by LIME base model as 199 default values. For example domain name can be set to area-ID in the 200 BFD case. In addition, at the Maintenance Domain level, domain data 201 node at root level can be augmented with technology type and sub- 202 technology type. 204 4.1.1. Technology Type Extension 206 No BFD technology type has been defined in the LIME base model. 207 Therefore a technology type extension is required in the BFD OAM 208 model. The technology type "bfd" is defined as an identity that 209 augments the base "technology-types" defined in the LIME base model: 211 4.1.2. Sub Technology Type Extension 213 In BFD, since different encapsulation types such as IP/UDP 214 Encapsulation, PW-ACH encapsulation can be employed. 216 In lime-bfd-extension yang data model, we define an identity: 217 "technology-sub-type" to further identify the encapsulation types 218 within the BFD. And based on it, we also define four identity 219 encapsulation types: 221 o technology-sub-type-sh-udp: technology sub-type is single hop with 222 IP/UDP encapsulation; 224 o technology-sub-type-mh-udp: technology sub-type is multiple hop 225 with IP/UDP encasulation; 227 o technology-sub-type-sh-ach: technology sub-type is single hop with 228 PW-ACH encapsulation; 230 o technology-sub-type-mh-ach: technology sub-type is multiple hop 231 with PW-ACH encapsulation; 233 In MD level, we define a sub-technology leaf with an identityref type 234 which base on the technology-sub-type: 236 augment "/goam:domains/goam:domain/" { 237 leaf sub-technology{ 238 type identityref { 239 base technology-sub-type; 240 } 241 } 242 } 244 4.2. MA configuration extension 246 MA level configuration parameters (e.g., MA Name)are management 247 information which can be inherited in the BFD model and set by LIME 248 base model as default values. One example of MA Name is Tunnel Name 249 or LAG Name. In addition, at the Maintenance Association(MA) level, 250 MA data node at the second level can be augmented with connectivity- 251 context extension. 253 4.2.1. Connectivity-Context Extension 255 In BFD context-id is a 32bit local discriminator. The LIME base 256 model defines a placeholder for context-id. This allows other 257 technologies to easily augment that to include technology specific 258 extensions. The snippet below depicts an example of augmenting 259 context-id to include local discriminator. 261 augment "/goam:domains/goam:domain/goam:MAs/goam:MA 262 /goam:connectivity-context" 263 { 264 case connectivity-context-bfd { 265 leaf local-discriminator { 266 type local-discriminator; 267 } 268 } 269 } 271 4.3. MEP configuration extension 273 In BFD, the MEP address is either an IPv4 or IPV6 address. MEP-ID is 274 either a 2 octet unsigned integer value or a variable length label 275 value. In the LIME base model, MEP-ID is defined as a variable 276 length label value and the same definition can be used for BFD with 277 no further modification. In addition, at the Maintenance Association 278 Endpoint(MEP) level, MEP data node at the third level can be 279 augmented with Session extension and interface extension. 281 4.3.1. Session Configuration Extension 283 At the Session level, Session data node at the fouth level can be 284 augmented with 3 interval parameters and 2 TTL parameters. The 285 Session Configuration extension should reuse grouping defined in 286 [draft-ietf-bfd-yang] for session related parameters. In [draft- 287 ietf-bfd-yang], source and destination address in the bfd-session-cfg 288 can be corresponding to Session configuration extension as source MEP 289 and destination MEP. 291 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: 292 +--rw (interval-config-type)? 293 | +--:(tx-rx-intervals) 294 | | +--rw desired-min-tx-interval uint32 295 | | +--rw required-min-rx-interval uint32 296 | +--:(single-interval) 297 | +--rw min-interval uint32 299 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: 300 +--rw tx-ttl? ttl 301 +--rw rx-ttl ttl 303 4.3.2. Interface configuration extension 305 At the Interface level, interface data node at the fifth level can be 306 augmented with the same parameters defined in per-interface 307 configuration of [draft-ietf-bfd-yang]. Interface configuration 308 extension should reuse grouping defined in [draft-ietf-bfd-yang] for 309 interface related parameters. 311 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam: outgoing-interface: 312 +--rw local-multiplier? multiplier 313 +--rw (interval-config-type)? 314 | +--:(tx-rx-intervals) 315 | | +--rw desired-min-tx-interval uint32 316 | | +--rw required-min-rx-interval uint32 317 | +--:(single-interval) 318 | +--rw min-interval uint32 319 +--rw demand-enabled? boolean 320 +--rw enable-authentication? boolean 321 +--rw authentication-parms {bfd-authentication}? 322 | +--rw key-chain-name? string 323 | +--rw algorithm? bfd-auth-algorithm 324 +--rw desired-min-echo-tx-interval? uint32 325 +--rw required-min-echo-rx-interval? uint32 326 4.3.3. New Notification definition 328 [GENYANGOAM] defines a notification model which abstracts defects 329 notification in a technology independent manner.However what BFD is 330 required is state change notification, therefore a new notification 331 definition can be specified to meet BFD requirement. The new 332 notification defintion should reuse groupings defined in [draft-ietf- 333 bfd-yang] for state change related parameters. 335 notifications: 336 +---n state-change-notification 337 +--ro local-discriminator? uint32 338 +--ro remote-discriminator? uint32 339 +--ro new-state? enumeration 340 +--ro state-change-reason? string 341 +--ro time-in-previous-state? string 342 +--ro dest-addr? inet:ip-address 343 +--ro source-addr? inet:ip-address 344 +--ro session-cookie? leafref 345 +--ro technology-sub-type? identityref 346 +--ro interface? leafref 347 +--ro echo-enabled? boolean 349 In this state-change-notification, technology-sub-type is used to 350 identify whether the notification is for single hop or multi-hop or 351 other types. 353 5. Model structure of LIME model extension for BFD 355 The complete data hierarchy related to the OAM YANG model is 356 presented below. 358 module: lime-bfd-extension 359 augment /goam:domains/goam:domain/goam:MAs/goam:MA: 360 +--rw technology-sub-type? identityref 361 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: 362 +--rw on-demand-enable? boolean 363 +--rw local-multiplier? uint8 364 +--rw bfd-tx-rx-interval 365 | +--rw desired-min-tx-interval? uint32 366 | +--rw required-min-rx-interval? uint32 367 +--rw enable-authentication? boolean 368 +--rw bfd-authentication {bfd-authentication}? 369 +--rw key-chain-name? string 370 +--rw algorithm? enumeration 371 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: 372 +--rw tx-ttl? uint8 373 +--rw rx-ttl? uint8 374 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:connectivity-context: 375 +--:(connectivity-context-bfd) 376 +--rw local-discriminator? uint32 377 +--rw remote-discriminator? uint32 378 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:outgoing-interface: 379 +--rw on-demand-enable? boolean 380 +--rw local-multiplier? uint8 381 +--rw bfd-tx-rx-interval 382 | +--rw desired-min-tx-interval? uint32 383 | +--rw required-min-rx-interval? uint32 384 +--rw enable-authentication? boolean 385 +--rw bfd-authentication {bfd-authentication}? 386 | +--rw key-chain-name? string 387 | +--rw algorithm? enumeration 388 +--rw desired-min-echo-tx-interval? uint32 389 +--rw required-min-echo-rx-interval? uint32 390 notifications: 391 +---n state-change-notification 392 +--ro local-discriminator? uint32 393 +--ro remote-discriminator? uint32 394 +--ro new-state? enumeration 395 +--ro state-change-reason? string 396 +--ro time-in-previous-state? string 397 +--ro dest-addr? inet:ip-address 398 +--ro source-addr? inet:ip-address 399 +--ro session-cookie? leafref 400 +--ro technology-sub-type? identityref 401 +--ro interface? leafref 402 +--ro echo-enabled? boolean 404 Data hierarchy of BFD OAM 406 6. OAM YANG Module 408 file "ietf-lime-bfd-extension.yang" 409 module ietf-lime-bfd-extension{ 410 namespace 411 "urn:ietf:params:xml:ns:yang:ietf-lime-bfd-extension"; 412 prefix limebfd; 414 import ietf-gen-oam { 415 prefix goam; 416 } 418 import ietf-bfd { 419 prefix bfd; 420 } 422 import ietf-interfaces { 423 prefix if; 424 } 426 organization 427 "IETF BFD Working Group"; 428 contact 429 "WG List: 430 Editor:"; 432 description 433 "This YANG Model extends the technology independent 434 YANG model for OAM with BFD technology specifics."; 436 revision 2014-08-30 { 437 description 438 "Initial revision."; 439 reference ""; 440 } 442 identity bfd{ 443 base goam:technology-types; 444 description 445 "bfd type"; 446 } 448 identity technology-sub-type { 449 description 450 "certain implementations such as bfd can have different 451 encapsulation types such as ip/udp, pw-ach and so on. 452 Instead of defining separate models for each 453 encapsulation, we define a technology sub-type to 454 further identify different encapsulations. Technology 455 sub-type is associated at the MA level"; 456 } 458 identity technology-sub-type-sh-udp { 459 base technology-sub-type; 460 description 461 "technology sub-type is single 462 hop with IP/UDP encapsulation"; 463 } 465 identity technology-sub-type-mh-udp { 466 base technology-sub-type; 467 description 468 "technology sub-type is multiple 469 hop with IP/UDP encapsulation"; 470 } 472 identity technology-sub-type-sh-ach { 473 base technology-sub-type; 474 description 475 "technology sub-type is single 476 hop with PW-ACH encapsulation"; 477 } 479 identity technology-sub-type-mh-ach { 480 base technology-sub-type; 481 description 482 "technology sub-type is multiple hop 483 with PW-ACH encapsulation"; 484 } 486 grouping tx-rx-ttl{ 487 description 488 "bfd tx ttl"; 490 leaf tx-ttl{ 491 type uint8; 492 description 493 "tx ttl."; 494 } 495 leaf rx-ttl{ 496 type uint8; 497 description 498 "rx ttl."; 499 } 500 } 501 feature bfd-authentication { 502 description "BFD authentication supported"; 503 } 505 augment "/goam:domains/goam:domain/goam:MAs/goam:MA"{ 506 when "goam:technology = 'bfd'" 507 {description 508 "when goam:technology = bfd.";} 509 leaf technology-sub-type { 510 type identityref { 511 base technology-sub-type; 512 } 513 description 514 "technology sub-type such as 515 single hop udp, multiple hop udp, 516 single hop ach, multiple hop ach."; 517 } 518 description 519 "augment the MA with bfd parameters."; 520 } 522 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" 523 +"/goam:MEP/goam:session"{ 524 when "goam:technology = 'bfd'" 525 {description 526 "when goam:technology = bfd.";} 527 leaf admin-down { 528 type boolean; 529 default false; 530 description 531 "Is the BFD session administratively down"; 532 } 534 uses bfd:bfd-grouping-common-cfg-parms; 536 description 537 "augment the session with bfd parameters."; 538 } 540 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" 541 +"/goam:MEP/goam:session"{ 542 when "technology-sub-type = 'technology-sub-type-mh-udp' 543 or 'technology-sub-type-mh-ach'"{ 544 description 545 "when technology sub type = techonlogy sub type mh udp 546 or technology sub type = technology-sub-type-mh-ach."; 547 } 548 uses tx-rx-ttl; 549 description 550 "augment the session with bfd parameters."; 551 } 553 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" 554 +"/goam:MEP/goam:session/goam:connectivity-context"{ 555 when "goam:technology = 'bfd'"{ 556 description 557 "when goam:techolgoy =bfd.";} 558 case connectivity-context-bfd { 559 leaf local-discriminator { 560 type uint32; 561 description 562 "local discriminator"; 563 } 564 leaf remote-discriminator{ 565 type uint32; 567 description 568 "remote-discriminator"; 569 } 570 } 571 description 572 "augment the connectivity-context with 573 bfd parameters."; 574 } 576 augment "/goam:domains/goam:domain/goam:MAs/goam:MA" 577 +"/goam:MEP/goam:session/goam:outgoing-interface"{ 578 when "technology-sub-type = 'technology-sub-type-sh-udp' 579 or 'technology-sub-type-sh-ach'"{ 580 description 581 "when technology-sub-type = 'technology-sub-type-sh-udp' 582 or 'technology-sub-type-sh-ach."; 583 } 584 uses bfd:bfd-grouping-common-cfg-parms; 585 uses bfd:bfd-grouping-echo-cfg-parms; 586 description 587 "augment the outgoing interface with bfd parameters."; 588 } 589 notification state-change-notification 590 { 591 uses bfd:bfd-notification-parms; 592 leaf interface { 593 type if:interface-ref; 594 description "Interface to which this BFD session belongs to"; 595 } 596 leaf echo-enabled { 597 type boolean; 598 description "Was echo enabled for BFD"; 599 } 600 description 601 "state change notification."; 602 } 603 } 605 607 7. Security Considerations 609 TBD. 611 8. IANA Considerations 613 TBD. 615 9. Normative References 617 [I-D.tissa-lime-yang-oam-model] 618 Senevirathne, T., Finn, N., Kumar, D., Salam, S., Wu, Q., 619 and Z. Wang, "Generic YANG Data Model for Operations, 620 Administration, and Maintenance (OAM)", draft-tissa-lime- 621 yang-oam-model-06 (work in progress), August 2015. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", March 1997. 626 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 627 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 628 . 630 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 631 the Network Configuration Protocol (NETCONF)", RFC 6020, 632 DOI 10.17487/RFC6020, October 2010, 633 . 635 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 636 and A. Bierman, Ed., "Network Configuration Protocol 637 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 638 . 640 [RFC7331] Nadeau, T., Ali, Z., and N. Akiya, "Bidirectional 641 Forwarding Detection (BFD) Management Information Base", 642 RFC 7331, DOI 10.17487/RFC7331, August 2014, 643 . 645 Authors' Addresses 647 Zitao Wang 648 Huawei Technologies,Co.,Ltd 649 101 Software Avenue, Yuhua District 650 Nanjing 210012 651 China 653 Email: wangzitao@huawei.com 655 Liang Xia 656 Huawei Technologies,Co.,Ltd 657 101 Software Avenue, Yuhua District 658 Nanjing 210012 659 China 661 Email: frank.xialiang@huawei.com 663 Deepak Kumar 664 Cisco Systems 665 510 McCarthy Blvd Milpitas, 666 CA 95035 667 USA 669 Email: dekumar@cisco.com 671 Qin Wu 672 Huawei 673 101 Software Avenue, Yuhua District 674 Nanjing, Jiangsu 210012 675 China 677 Email: bill.wu@huawei.com