idnits 2.17.00 (12 Aug 2021) /tmp/idnits21818/draft-wilton-netmod-interface-properties-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document 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 874: '...r implementation MAY map this leaf to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 1776 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7224' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 313, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Wilton, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track July 3, 2017 5 Expires: January 4, 2018 7 Interface Properties for YANG Data Models 8 draft-wilton-netmod-interface-properties-00 10 Abstract 12 This document specifies a better way to restrict interface YANG 13 schema nodes to only those types of interfaces that the nodes are 14 applicable to. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 4, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Problem Definition . . . . . . . . . . . . . . . . . . . . . 3 53 4. Interface Property Identities . . . . . . . . . . . . . . . . 4 54 5. Potential issues and considerations: . . . . . . . . . . . . 4 55 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 10.2. Informative References . . . . . . . . . . . . . . . . . 7 62 Appendix A. Examples of possible updates to iana-if-types.yang . 7 63 Appendix B. Example of interface properties usage in ietf- 64 interfaces-common.yang . . . . . . . . . . . . . . . 10 65 Appendix C. Example of interface properties usage in ietf- 66 interfaces-ethernet-like.yang . . . . . . . . . . . 15 67 Appendix D. Example of interface properties usage in ietf- 68 interfaces.yang . . . . . . . . . . . . . . . . . . 17 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 71 1. Introduction 73 This document introduces the concept of generic interface property 74 identities in YANG [RFC7950] data models to solve the problem of how 75 to restrict interface configuration and state schema nodes to the 76 appropriate types of interfaces. E.g., it is desirable to restrict 77 MAC address configuration and state schema nodes to only those types 78 of interfaces that use Ethernet framing, and hence for which MAC 79 address configuration may be applicable. This document defines a set 80 of common interface property YANG identities (e.g., Ethernet-like), 81 and proposes that the iana-interface-type identities in iana-if- 82 type.yang are updated to also derive from the interface property 83 identities (a backwards compatible change). Interface based YANG 84 schema nodes can then be made conditional on the interface property 85 identities rather than being conditional on a hardcoded set of IANA 86 interface types. This approach also allows newly defined interface 87 types to reuse published standard interface YANG schema nodes just by 88 deriving from the appropriate interface property identities, and 89 without requiring new revisions of those published standard YANG 90 modules each time a new IANA interface type is defined. 92 2. Terminology 94 This document defines the following terms: 96 o interface property identity: A YANG identity that defines a 97 particular generic interface related property that generally 98 relates to multiple interface type identities defined in iana- 99 interface-type.yang. An example of such a property is 100 'Ethernet-like'. 102 3. Problem Definition 104 The YANG language offers the "when" statement that can be used to 105 make nodes conditional on some particular X-Path expression. 107 In the case, of interface related configuration, the when statement 108 can be used to explicitly list all the iana-interface-type identities 109 that an interface's 'type' leaf may take. 111 However, the current solution is not ideal for several reasons: 113 o Explicitly listing the interface types is somewhat unwieldy, 114 particularly in the case that a schema node may apply to many 115 interfaces. When faced with this scenario, YANG model authors 116 sometimes decide that it is better to keep the model simple and 117 just allow the schema node to be used regardless of interface 118 type. 120 o Explicly listing the inteface types has the further problem that 121 the model cannot easily be extended to handle new interface types. 122 If a new interface type is introduced then to reuse the same 123 interface related schema nodes requires that all of the applicable 124 model when statements must be updated to reference the new IANA 125 interface type identity. 127 o The current solution does not really work for bespoke vendor 128 specific interface types. Even though the proprietrary interface 129 types may be defined in the IANA interface type identity list, it 130 is unlikely that it would be acceptable to update a standards 131 based YANG model to reference a proprietrary interface type. 132 Requiring bespoke interfaces to use separate similar configuration 133 and state nodes makes the models less generic and more tedious to 134 use by clients. 136 4. Interface Property Identities 138 This draft introduces "Interface Property Identities". These are a 139 set of YANG identities that describe properties that could be 140 associated with multiple different types of interface. 142 The existing IANA interface type identities are then selectively 143 updated to also derive from one or more of these interface property 144 identities. The YANG module upgrade rules in [RFC7950] allow for the 145 interface type identities to derive from additional identities in a 146 fully backwards compatible way. 148 YANG modules that define interface specific nodes can then use the 149 YANG 1.1 derived-from() macro in the 'when' statement xpath 150 expression to indicate that the node applies to all interfaces that 151 inherit from the specified interface property. 153 As new IANA interface types are defined they can derive from the 154 interface property identities and hence acquire the interface 155 specific YANG nodes that have been defined in existing YANG modules 156 without requiring any changes beyond the device updating to use the 157 latest iana-if-types YANG file. 159 Similarly, vendor specific interface types can also inherit from the 160 interface property identities and also acquire access to the 161 appropriate interface configuration nodes. 163 As required, new interface property identities can also be defined, 164 again in a backwards compatible way. 166 5. Potential issues and considerations: 168 o Would IANA be willing to manage the new interface property types? 170 o iana-interface-types.yang would need to be YANG 1.1. Would this 171 be an issue? 173 o Need to define a suitable set of base interface properties. 175 o Need to then apply the set of base interface properties to 176 appropriate interface types. Coordination between vendors may be 177 required to get a reasonable base coverage. 179 6. YANG Modules 181 file "iana-if-property-type@2017-06-27.yang" 183 module iana-if-property-type { 184 namespace "urn:ietf:params:xml:ns:yang:iana-if-property-type"; 185 prefix ianaifp; 187 organization "IANA"; 188 contact ""; 189 description 190 "This YANG module defines YANG identities for IANA-registered 191 interface property types. 193 This YANG module is maintained by IANA. 195 The latest revision of this YANG module can be obtained from 196 the IANA web site. 198 Requests for new values should be made to IANA via 199 email (iana&iana.org). 201 Copyright (c) 2017 IETF Trust and the persons identified as 202 authors of the code. All rights reserved. 204 Redistribution and use in source and binary forms, with or 205 without modification, is permitted pursuant to, and subject 206 to the license terms contained in, the Simplified BSD License 207 set forth in Section 4.c of the IETF Trust's Legal Provisions 208 Relating to IETF Documents 209 (http://trustee.ietf.org/license-info). 211 The initial version of this YANG module is part of XXX; 212 see the RFC itself for full legal notices."; 213 reference 214 "IANA 'interface property definitions' registry."; 216 revision 2017-06-27 { 217 description 218 "Initial revision"; 219 reference 220 "RFC XXX: IANA Interface Property Type YANG Module"; 221 } 223 identity iana-if-property-type { 224 description 225 "Base identity from which specific interface property types are 226 derived."; 227 } 229 identity physical { 230 base iana-if-property-type; 231 description 232 "This property represents an interface that has a physical 233 hardware representation, or is modelled as such."; 234 } 236 identity virtual { 237 base iana-if-property-type; 238 description 239 "This property represents an interface that has no external 240 physical hardware representation, and is used to represent 241 interfaces that are created via configuration."; 242 } 244 identity sub-interface { 245 base iana-if-property-type; 246 description 247 "This property represents an interface that is a child 248 interface that is parented to another interface."; 249 } 251 identity point-to-point { 252 base iana-if-property-type; 253 description 254 "This property represents an interface that is always 255 point-to-point, i.e. the interface can only ever be connected 256 to a single other interface, and hence broadcast and multicast 257 packet statistics do not make sense."; 258 } 260 identity multicast { 261 base iana-if-property-type; 262 description 263 "This property represents an interface that could have multiple 264 end points, e.g. like an Ethernet interface. Such an 265 interface could have separate broadcast and multicast packet 266 counters."; 267 } 269 identity ethernet-like { 270 base iana-if-property-type; 271 description 272 "This property represents an interface that is similar in 273 behaviour to an Ethernet interface, and uses Ethernet 274 framing."; 275 } 276 } 278 280 7. IANA Considerations 282 This draft proposes that IANA also manage a new registry of 283 "interface properties" alongside the existing "interface type" 284 registry, and to 286 extend the "interface type" registry to also derive from interface 287 properties identities. 289 8. Security Considerations 291 This document discusses an approach how to structure interface 292 related YANG schema. It has no security impact on the Internet. 294 9. Acknowledgments 296 This document arose from discussions with Martin Bjorklund, Ladislav 297 Lhotka, and Vladimir Vassilev on the Netmod WG alias. 299 10. References 301 10.1. Normative References 303 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 304 RFC 7224, DOI 10.17487/RFC7224, May 2014, 305 . 307 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 308 RFC 7950, DOI 10.17487/RFC7950, August 2016, 309 . 311 10.2. Informative References 313 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 314 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 315 . 317 Appendix A. Examples of possible updates to iana-if-types.yang 319 The example-iana-if-type.yang module illustrates the type of updates 320 that would be made to iana-if-types.yang to make use of interface 321 properties. 323 file "example-iana-if-type@2017-06-27.yang" 325 module example-iana-if-type { 326 yang-version "1.1"; 327 namespace "urn:ietf:params:xml:ns:yang:example-iana-if-type"; 328 prefix ianaift; 330 import ietf-interfaces { 331 prefix if; 332 } 334 import iana-if-property-type { 335 prefix ianaifp; 336 } 338 // Full description, etc elided for clarity. 339 organization "IANA"; 340 contact ""; 341 description 342 "This example module illustrates how iana-if-type.yang could 343 be extended to use interface properties."; 344 reference 345 "IANA 'ifType definitions' registry. 346 "; 348 revision 2017-06-27 { 349 description 350 "Initial example of how IANA if type could be extended"; 351 reference 352 "Taken from draft-rwilton-netmod-interface-properties-00"; 353 } 355 // Previous revision statements elided for clarity. 357 identity iana-interface-type { 358 base if:interface-type; 359 description 360 "This identity is used as a base for all interface types 361 defined in the 'ifType definitions' registry."; 362 } 364 // Most identies elided for clarity, some are retained to 365 // illustrate how the interface properties are defined. 366 identity other { 367 base iana-interface-type; 368 description 369 "None of the following"; 370 } 372 identity ethernetCsmacd { 373 base iana-interface-type; 374 base ianaifp:physical; 375 base ianaifp:multicast; 376 base ianaifp:ethernet-like; 377 description 378 "For all Ethernet-like interfaces, regardless of speed, 379 as per RFC 3635."; 380 reference 381 "RFC 3635 - Definitions of Managed Objects for the 382 Ethernet-like Interface Types"; 383 } 385 identity ieee8023adLag { 386 base iana-interface-type; 387 base ianaifp:virtual; 388 base ianaifp:multicast; 389 base ianaifp:ethernet-like; 390 description 391 "IEEE 802.3ad Link Aggregate."; 392 } 394 identity atm { 395 base iana-interface-type; 396 base ianaifp:physical; 397 base ianaifp:multicast; 398 description 399 "ATM cells."; 400 } 402 identity atmSubInterface { 403 base iana-interface-type; 404 base ianaifp:virtual; 405 base ianaifp:sub-interface; 406 base ianaifp:multicast; 407 description 408 "ATM Sub Interface."; 409 } 411 identity l2vlan { 412 base iana-interface-type; 413 base ianaifp:virtual; 414 base ianaifp:sub-interface; 415 base ianaifp:multicast; 416 description 417 "Layer 2 Virtual LAN using 802.1Q."; 418 } 420 identity pos { 421 base iana-interface-type; 422 base ianaifp:point-to-point; 423 description 424 "Packet over SONET/SDH Interface."; 425 } 427 identity irb { 428 base iana-interface-type; 429 base ianaifp:virtual; 430 base ianaifp:multicast; 431 base ianaifp:ethernet-like; 433 description 434 "Integrated Routing and Bridging interface, also known as an 435 SVI or BVI interface. 437 Note, not currently defined in if-type.yang"; 438 } 439 } 441 443 Appendix B. Example of interface properties usage in ietf-interfaces- 444 common.yang 446 The ietf-interfaces-common module defines various interface 447 configuration nodes that are applicable to different types of 448 interfaces and hence would benefit from interface properties. 450 file "example-ietf-interfaces-common@2017-06-27.yang" 452 module example-ietf-interfaces-common { 453 yang-version 1.1; 455 namespace 456 "urn:ietf:params:xml:ns:yang:example-ietf-interfaces-common"; 458 prefix if-cmn; 460 import ietf-interfaces { 461 prefix if; 462 } 464 import iana-if-type { 465 prefix ianaift; 466 } 468 import iana-if-property-type { 469 prefix ianaifp; 470 } 471 organization 472 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 474 contact 475 "WG Web: 476 WG List: 478 WG Chair: Lou Berger 479 481 WG Chair: Kent Watsen 482 484 Editor: Robert Wilton 485 "; 487 description 488 "Example of using when statements with interface properties"; 490 revision 2017-06-27 { 491 description 492 "Examples of using when statements with interface properties"; 494 reference "Internet draft: draft-ietf-netmod-intf-ext-yang-04"; 495 } 497 feature bandwidth { 498 description ""; 499 reference "Section 3.1 Bandwidth"; 500 } 502 feature carrier-delay { 503 description ""; 504 reference "Section 3.2 Carrier Delay"; 505 } 507 feature dampening { 508 description ""; 509 reference "Section 3.3 Dampening"; 510 } 512 feature loopback { 513 description ""; 514 reference "Section 3.5 Loopback"; 515 } 517 feature configurable-l2-mtu { 518 description ""; 519 reference "Section 3.6 MTU"; 520 } 522 feature sub-interfaces { 523 description 524 "This feature indicates that the device supports the 525 instantiation of sub-interfaces. Sub-interfaces are defined 526 as logical child interfaces that allow features and forwarding 527 decisions to be applied to a subset of the traffic processed 528 on the specified parent interface."; 529 reference "Section 3.7 Sub-interface"; 530 } 532 feature forwarding-mode { 533 description ""; 534 reference "Section 3.8 Forwarding Mode"; 535 } 537 /* 538 * Define common identities to help allow interface types to be 539 * assigned properties. 540 */ 542 identity loopback { 543 description "Base identity for interface loopback options"; 544 } 545 identity loopback-internal { 546 base loopback; 547 description ""; 548 } 549 identity loopback-line { 550 base loopback; 551 description ""; 552 } 553 identity loopback-connector { 554 base loopback; 555 description ""; 556 } 558 /* 559 * Augments the IETF interfaces model with a leaf to explicitly 560 * specify the bandwidth available on an interface. 561 */ 562 augment "/if:interfaces/if:interface" { 563 description 564 "Augments the IETF interface model with optional common 565 interface level commands that are not formally covered by any 566 specific standard"; 568 // Various features/nodes elided. 570 /* 571 * Various types of interfaces support a configurable layer 2 572 * encapsulation, any that are supported by YANG should be 573 * listed here. 574 * 575 * Different encapsulations can hook into the common encaps-type 576 * choice statement. 577 */ 578 container encapsulation { 579 when 580 "derived-from-or-self(../if:type, 'ianaifp:ethernet-like') or 581 derived-from-or-self(../if:type, 'ianaifp:sub-interface')" { 583 description 584 "All interface types that can have a configurable L2 585 encapsulation"; 586 /* 587 * TODO - Should we introduce an abstract type to make this 588 * extensible to new interface types, or vendor 589 * specific interface types? 590 */ 591 } 593 description 594 "Holds the OSI layer 2 encapsulation associated with an 595 interface"; 596 choice encaps-type { 597 description "Extensible choice of L2 encapsulations"; 598 } 599 } 601 /* 602 * Various types of interfaces support loopback configuration, 603 * any that are supported by YANG should be listed here. 604 */ 605 leaf loopback { 606 when "derived-from(if:type, 'ianaifp:physical')" { 607 description 608 "Applies to all interfaces that derive from the physical 609 interface property."; 610 } 612 if-feature "loopback"; 613 type identityref { 614 base loopback; 615 } 616 description "Enables traffic loopback."; 617 } 619 /* 620 * Many types of interfaces support a configurable layer 2 MTU. 621 */ 622 leaf l2-mtu { 623 if-feature "configurable-l2-mtu"; 624 type uint16 { 625 range "64 .. 65535"; 626 } 627 description 628 "The maximum size of layer 2 frames that may be transmitted 629 or received on the interface (excluding any FCS overhead). 630 In the case of Ethernet interfaces it also excludes the 631 4-8 byte overhead of any known (i.e. explicitly matched by 632 a child sub-interface) 801.1Q VLAN tags."; 633 } 634 } 636 /* 637 * Add generic support for sub-interfaces. 638 * 639 * This should be extended to cover all interface types that are 640 * child interfaces of other interfaces. 641 */ 642 augment "/if:interfaces/if:interface" { 643 when "derived-from(if:type, 'ianaifp:sub-interface')" { 644 description 645 "Applies to all interfaces that derive from the Ethernet-like 646 interface property."; 647 } 649 if-feature "sub-interfaces"; 651 description 652 "Add a parent interface field to interfaces that model 653 sub-interfaces"; 654 leaf parent-interface { 656 type if:interface-ref; 658 mandatory true; 659 description 660 "This is the reference to the parent interface of this 661 sub-interface."; 662 } 663 } 664 } 666 668 Appendix C. Example of interface properties usage in ietf-interfaces- 669 ethernet-like.yang 671 The ietf-interfaces-ethernet-like module defines various interface 672 configuration nodes that are applicable to any interfaces that have 673 "Ethernet-like" semantics, and hence would benefit from interface 674 properties. 676 file "example-ietf-interfaces-ethernet- 677 like@2017-06-27.yang" 679 module example-ietf-interfaces-ethernet-like { 680 yang-version 1.1; 682 namespace 683 "urn:ietf:params:xml:ns:yang:" + 684 "example-ietf-interfaces-ethernet-like"; 686 prefix ethlike; 688 import ietf-interfaces { 689 prefix if; 690 } 692 import ietf-yang-types { 693 prefix yang; 694 } 696 import iana-if-property-type { 697 prefix ianaifp; 698 } 700 organization 701 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 703 contact 704 "WG Web: 705 WG List: 707 WG Chair: Lou Berger 708 710 WG Chair: Kent Watsen 711 713 Editor: Robert Wilton 714 "; 716 description 717 "Example for when statements using interface properties."; 719 revision 2017-06-27 { 720 description 721 "Examples of using when statements with interface properties"; 723 reference "Internet draft: draft-ietf-netmod-intf-ext-yang-04"; 724 } 726 /* 727 * Configuration parameters for Ethernet-like interfaces. 728 */ 729 augment "/if:interfaces/if:interface" { 730 when "derived-from(if:type, 'ianaifp:ethernet-like')" { 731 description 732 "Applies to all interfaces that derive from the Ethernet-like 733 interface property."; 734 } 735 description 736 "Augment the interface model with configuration parameters for 737 all Ethernet-like interfaces"; 739 container ethernet-like { 740 description "Contains configuration parameters for interfaces 741 that use Ethernet framing and expose an Ethernet 742 MAC layer."; 743 leaf mac-address { 744 type yang:mac-address; 745 description 746 "The configured MAC address of the interface."; 747 } 748 } 749 } 751 /* 752 * Operational state for Ethernet-like interfaces. 753 */ 754 augment "/if:interfaces-state/if:interface" { 755 when "derived-from(if:type, 'ianaifp:ethernet-like')" { 756 description 757 "Applies to all interfaces that derive from the Ethernet-like 758 interface property."; 759 } 760 description 761 "Augments the interface model with operational state parameters 762 for all Ethernet-like interfaces."; 763 container ethernet-like { 764 description 765 "Contains operational state parameters for interfaces that use 766 Ethernet framing and expose an Ethernet MAC layer."; 767 leaf mac-address { 768 type yang:mac-address; 769 description 770 "The operational MAC address of the interface, if 771 applicable"; 772 } 774 leaf bia-mac-address { 775 type yang:mac-address; 776 description 777 "The 'burnt-in' MAC address. I.e the default MAC address 778 assigned to the interface if none is explicitly 779 configured."; 780 } 782 container statistics { 783 description 784 "Packet statistics that apply to all Ethernet-like 785 interfaces"; 786 leaf in-drop-unknown-dest-mac-pkts { 787 type yang:counter64; 788 units frames; 789 description ""; 790 } 791 } 792 } 793 } 794 } 796 798 Appendix D. Example of interface properties usage in ietf- 799 interfaces.yang 801 Here is an example of how the ietf-interfaces.yang module could have 802 used interface properties to restrict multicast packet statistics to 803 only those interfaces that support it. 805 file "example-ietf-interfaces@2017-06-27.yang" 806 module example-ietf-interfaces { 807 yang-version 1.1; 809 namespace "urn:ietf:params:xml:ns:yang:example-ietf-interfaces"; 811 prefix if; 812 import ietf-yang-types { 813 prefix yang; 814 } 816 import "iana-if-property-type" { 817 prefix ianaifp; 818 } 820 organization 821 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 822 contact ""; 823 description 824 "Example of when statements for refining interface statistics"; 826 revision 2017-06-27 { 827 description 828 "Example of how some interface statistics could make use of 829 interface properties"; 830 reference 831 "RFC 7223: A YANG Data Model for Interface Management"; 832 } 833 /* 834 * Typedefs 835 */ 836 // interface-ref typedef elided. 837 typedef interface-state-ref { 838 type leafref { 839 path "/if:interfaces-state/if:interface/if:name"; 840 } 841 description 842 "This type is used by data models that need to reference 843 the operationally present interfaces."; 844 } 845 /* 846 * Identities 847 */ 848 identity interface-type { 849 description 850 "Base identity from which specific interface types are 851 derived."; 852 } 853 // Features elided. 854 // Configuration tree elided. 856 /* 857 * Operational state data nodes 858 */ 859 container interfaces-state { 860 config false; 861 description 862 "Data nodes for the operational state of interfaces."; 863 list interface { 864 key "name"; 865 description 866 "The list of interfaces on the device. 867 System-controlled interfaces created by the system are 868 always present in this list, whether they are configured or 869 not."; 870 leaf name { 871 type string; 872 description 873 "The name of the interface. 874 A server implementation MAY map this leaf to the ifName 875 MIB object. Such an implementation needs to use some 876 mechanism to handle the differences in size and characters 877 allowed between this leaf and ifName. The definition of 878 such a mechanism is outside the scope of this document."; 879 reference 880 "RFC 2863: The Interfaces Group MIB - ifName"; 881 } 882 leaf type { 883 type identityref { 884 base interface-type; 885 } 886 mandatory true; 887 description 888 "The type of the interface."; 889 reference 890 "RFC 2863: The Interfaces Group MIB - ifType"; 891 } 893 // Various leaves elided. 895 container statistics { 896 description 897 "A collection of interface-related statistics objects."; 898 leaf discontinuity-time { 899 type yang:date-and-time; 900 mandatory true; 901 description ""; 902 } 903 leaf in-octets { 904 type yang:counter64; 905 description ""; 906 reference 907 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 908 } 909 leaf in-unicast-pkts { 910 type yang:counter64; 911 description 912 "The number of packets, delivered by this sub-layer to a 913 higher (sub-)layer, that were not addressed to a 914 multicast or broadcast address at this sub-layer. 915 Discontinuities in the value of this counter can occur 916 at re-initialization of the management system, and at 917 other times as indicated by the value of 918 'discontinuity-time'."; 919 reference 920 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 921 } 922 leaf in-broadcast-pkts { 923 when "derived-from(if:type, 'ianaifp:multicast')" { 924 description 925 "Applies to interfaces that inherit the multicast 926 interface property."; 927 } 929 type yang:counter64; 930 description 931 "The number of packets, delivered by this sub-layer to a 932 higher (sub-)layer, that were addressed to a broadcast 933 address at this sub-layer. 934 Discontinuities in the value of this counter can occur 935 at re-initialization of the management system, and at 936 other times as indicated by the value of 937 'discontinuity-time'."; 938 reference 939 "RFC 2863: The Interfaces Group MIB - 940 ifHCInBroadcastPkts"; 941 } 942 leaf in-multicast-pkts { 943 when "derived-from(if:type, 'ianaifp:multicast')" { 944 description 945 "Applies to interfaces that inherit the multicast 946 interface property."; 947 } 948 type yang:counter64; 949 description 950 "The number of packets, delivered by this sub-layer to a 951 higher (sub-)layer, that were addressed to a multicast 952 address at this sub-layer. For a MAC-layer protocol, 953 this includes both Group and Functional addresses. 954 Discontinuities in the value of this counter can occur 955 at re-initialization of the management system, and at 956 other times as indicated by the value of 957 'discontinuity-time'."; 958 reference 959 "RFC 2863: The Interfaces Group MIB - 960 ifHCInMulticastPkts"; 961 } 962 // Remaining counters elided. 963 } 964 } 965 } 966 } 968 970 Author's Address 972 Robert Wilton (editor) 973 Cisco Systems 975 Email: rwilton@cisco.com