idnits 2.17.00 (12 Aug 2021) /tmp/idnits64294/draft-ietf-ippm-ioam-yang-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 25, 2022) is 109 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) == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-ipv6-options-06 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-ioam-nsh-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM T. Zhou, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Guichard 5 Expires: July 29, 2022 Futurewei 6 F. Brockners 7 S. Raghavan 8 Cisco Systems 9 January 25, 2022 11 A YANG Data Model for In-Situ OAM 12 draft-ietf-ippm-ioam-yang-03 14 Abstract 16 In-situ Operations, Administration, and Maintenance (IOAM) records 17 operational and telemetry information in user packets while the 18 packets traverse a path between two points in the network. This 19 document defines a YANG module for the IOAM function. 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 https://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 July 29, 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://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 used in this document . . . . . . . . . . . . . . 3 57 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Design of the IOAM YANG Data Model . . . . . . . . . . . . . 3 59 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Preallocated Tracing Profile . . . . . . . . . . . . . . 5 61 3.3. Incremental Tracing Profile . . . . . . . . . . . . . . . 6 62 3.4. Direct Export Profile . . . . . . . . . . . . . . . . . . 6 63 3.5. Proof of Transit Profile . . . . . . . . . . . . . . . . 6 64 3.6. Edge to Edge Profile . . . . . . . . . . . . . . . . . . 7 65 4. IOAM YANG Module . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 71 8.2. Informative References . . . . . . . . . . . . . . . . . 24 72 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 25 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 75 1. Introduction 77 In-situ Operations, Administration, and Maintenance (IOAM) 78 [I-D.ietf-ippm-ioam-data] records OAM information within user packets 79 while the packets traverse a network. The data types and data 80 formats for IOAM data records have been defined in 81 [I-D.ietf-ippm-ioam-data]. The IOAM data can be embedded in many 82 protocol encapsulations such as Network Services Header (NSH) and 83 IPv6. 85 This document defines a data model for IOAM capabilities using the 86 YANG data modeling language [RFC7950]. This YANG model supports five 87 IOAM options, which are: 89 o Incremental Tracing Option [I-D.ietf-ippm-ioam-data] 91 o Pre-allocated Tracing Option [I-D.ietf-ippm-ioam-data] 93 o Direct Export Option [I-D.ietf-ippm-ioam-direct-export] 95 o Proof of Transit (PoT) Option [I-D.ietf-ippm-ioam-data] 96 o Edge-to-Edge Option [I-D.ietf-ippm-ioam-data] 98 2. Conventions used in this document 100 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 The following terms are defined in [RFC7950] and are used in this 107 specification: 109 o augment 111 o data model 113 o data node 115 The terminology for describing YANG data models is found in 116 [RFC7950]. 118 2.1. Tree Diagrams 120 Tree diagrams used in this document follow the notation defined in 121 [RFC8340]. 123 3. Design of the IOAM YANG Data Model 125 3.1. Overview 127 The IOAM model is organized as list of profiles as shown in the 128 following figure. Each profile associates with one flow and the 129 corresponding IOAM information. 131 The "ioam-info" is a container for all the read only assistant 132 information, so that monitoring systems can interpret the IOAM data. 134 module: ietf-ioam 135 +--rw ioam 136 +--ro ioam-info 137 | +--ro timestamp-type? identityref 138 | +--ro available-interface* [if-name] 139 | +--ro if-name -> if:interfaces/interface/name 140 +--rw ioam-profiles 141 +--rw admin-config 142 | +--rw enabled? boolean 143 +--rw ioam-profile* [profile-name] 144 +--rw profile-name string 145 +--rw filter 146 | +--rw filter-type? ioam-filter-type 147 | +--rw ace-name? -> /acl:acls/acl/aces/ace/name 148 +--rw protocol-type? ioam-protocol-type 149 +--rw incremental-tracing-profile {incremental-trace}? 150 | ... 151 +--rw preallocated-tracing-profile {preallocated-trace}? 152 | ... 153 +--rw direct-export-profile {direct-export}? 154 | ... 155 +--rw pot-profile {proof-of-transit}? 156 | ... 157 +--rw e2e-profile {edge-to-edge}? 158 ... 160 In the "ioam-profiles", the "enabled" is an administrative 161 configuration. When it is set to true, IOAM configuration is enabled 162 for the system. Meanwhile, the IOAM data-plane functionality is 163 enabled. 165 The "filter" is used to identify a flow, where the IOAM profile can 166 apply. There may be multiple filter types. ACL [RFC8519] is a 167 common way to specify a flow. Each IOAM profile can associate with 168 an ACE(Access Control Entry). IOAM actions MUST be driven by the 169 accepted packets, when the matched ACE "forwarding" action is 170 "accept". 172 The IOAM data can be encapsulated into multiple protocols, e.g., IPv6 173 [I-D.ietf-ippm-ioam-ipv6-options] and NSH [I-D.ietf-sfc-ioam-nsh]. 174 The "protocol-type" is used to indicate where the IOAM is applied. 175 For example, if the "protocol-type" is IPv6, the IOAM ingress node 176 will encapsulate the associated flow with the IPv6-IOAM 177 [I-D.ietf-ippm-ioam-ipv6-options] format. 179 IOAM data includes five encapsulation types, i.e., incremental 180 tracing data, preallocated tracing data, direct export data, proof of 181 transit data and end to end data. In practice, multiple IOAM data 182 types can be encapsulated into the same IOAM header. The "ioam- 183 profile" contains a set of sub-profiles, each of which relates to one 184 encapsulation type. The configured object may not support all the 185 sub-profiles. The supported sub-profiles are indicated by 5 defined 186 features, i.e., "incremental-trace", "preallocated-trace", "direct 187 export", "proof-of-transit", "edge-to-edge". 189 3.2. Preallocated Tracing Profile 191 The IOAM tracing data is expected to be collected at every node that 192 a packet traverses to ensure visibility into the entire path a packet 193 takes within an IOAM domain. The preallocated tracing option will 194 create pre-allocated space for each node to populate its information 195 . The "preallocated-tracing-profile" contains the detailed 196 information for the preallocated tracing data. The information 197 includes: 199 o enabled: indicates whether the preallocated tracing profile is 200 enabled. 202 o node-action: indicates the operation (e.g., encapsulate IOAM 203 header, transit the IOAM data, or decapsulate IOAM header) applied 204 to the dedicated flow. 206 o use-namespace: indicate the namespace used for the trace types. 208 o trace-type: indicates the per-hop data to be captured by the IOAM 209 enabled nodes and included in the node data list. 211 o Loopback mode is used to send a copy of a packet back towards the 212 source. 214 o Active mode indicates that a packet is used for active 215 measurement. 217 +--rw preallocated-tracing-profile {preallocated-trace}? 218 +--rw enabled? boolean 219 +--rw node-action? ioam-node-action 220 +--rw trace-types 221 | +--rw use-namespace? ioam-namespace 222 | +--rw trace-type* ioam-trace-type 223 +--rw enable-loopback-mode? boolean 224 +--rw enable-active-mode? boolean 226 3.3. Incremental Tracing Profile 228 The incremental tracing option contains a variable node data fields 229 where each node allocates and pushes its node data immediately 230 following the option header. The "incremental-tracing-profile" 231 contains the detailed information for the incremental tracing data. 232 The detailed information is the same as the Preallocated Tracing 233 Profile, but with one more variable, "max-length", which restricts 234 the length of the IOAM header. 236 +--rw incremental-tracing-profile {incremental-trace}? 237 +--rw enabled? boolean 238 +--rw node-action? ioam-node-action 239 +--rw trace-types 240 | +--rw use-namespace? ioam-namespace 241 | +--rw trace-type* ioam-trace-type 242 +--rw enable-loopback-mode? boolean 243 +--rw enable-active-mode? boolean 244 +--rw max-length? uint32 246 3.4. Direct Export Profile 248 The direct export option is used as a trigger for IOAM nodes to 249 export IOAM data to a receiving entity (or entities). The "direct- 250 export-profile" contains the detailed information for the direct 251 export data. The detailed information is the same as the 252 Preallocated Tracing Profile, but with one more optional variable, 253 "flow-id", which is used to correlate the exported data of the same 254 flow from multiple nodes and from multiple packets. 256 +--rw direct-export-profile {direct-export}? 257 +--rw enabled? boolean 258 +--rw node-action? ioam-node-action 259 +--rw trace-types 260 | +--rw use-namespace? ioam-namespace 261 | +--rw trace-type* ioam-trace-type 262 +--rw enable-loopback-mode? boolean 263 +--rw enable-active-mode? boolean 264 +--rw flow-id? uint32 266 3.5. Proof of Transit Profile 268 The IOAM Proof of Transit data is to support the path or service 269 function chain verification use cases. The "pot-profile" contains 270 the detailed information for the proof of transit data. "pot-type" 271 indicates a particular POT variant that specifies the POT data that 272 is included. There may be several POT types, which have different 273 configuration data. To align with [I-D.ietf-ippm-ioam-data], this 274 document only defines IOAM POT type 0. User need to augment this 275 module for the configuration of a specifc POT type. 277 +--rw pot-profile {proof-of-transit}? 278 +--rw enabled? boolean 279 +--rw pot-type? ioam-pot-type 281 3.6. Edge to Edge Profile 283 The IOAM edge to edge option is to carry data that is added by the 284 IOAM encapsulating node and interpreted by IOAM decapsulating node. 285 The "e2e-profile" contains the detailed information for the edge to 286 edge data. The detailed information includes: 288 o enabled: indicates whether the edge to edge profile is enabled. 290 o node-action is the same semantic as in Section 2.2. 292 o use-namespace: indicate the namespace used for the edge to edge 293 types. 295 o e2e-type indicates data to be carried from the ingress IOAM node 296 to the egress IOAM node. 298 +--rw e2e-profile {edge-to-edge}? 299 +--rw enabled? boolean 300 +--rw node-action? ioam-node-action 301 +--rw e2e-types 302 +--rw use-namespace? ioam-namespace 303 +--rw e2e-type* ioam-e2e-type 305 4. IOAM YANG Module 307 file "ietf-ioam@2022-01-25.yang" 308 module ietf-ioam { 309 yang-version 1.1; 310 namespace "urn:ietf:params:xml:ns:yang:ietf-ioam"; 311 prefix "ioam"; 313 import ietf-access-control-list { 314 prefix "acl"; 315 reference 316 "RFC 8519: YANG Data Model for Network Access Control 317 Lists (ACLs)"; 318 } 320 import ietf-interfaces { 321 prefix "if"; 322 reference 323 "RFC 8343: A YANG Data Model for Interface Management"; 324 } 326 import ietf-lime-time-types { 327 prefix "lime"; 328 reference 329 "RFC 8532: Generic YANG Data Model for the Management of 330 Operations, Administration, and Maintenance (OAM) Protocols 331 That Use Connectionless Communications"; 332 } 334 organization 335 "IETF IPPM (IP Performance Metrics) Working Group"; 337 contact 338 "WG Web: 339 WG List: 340 Editor: zhoutianran@huawei.com 341 Editor: james.n.guichard@futurewei.com 342 Editor: fbrockne@cisco.com 343 Editor: srihari@cisco.com"; 345 description 346 "This YANG module specifies a vendor-independent data 347 model for the In Situ OAM (IOAM). 349 Copyright (c) 2021 IETF Trust and the persons identified as 350 authors of the code. All rights reserved. 352 Redistribution and use in source and binary forms, with or 353 without modification, is permitted pursuant to, and subject 354 to the license terms contained in, the Simplified BSD License 355 set forth in Section 4.c of the IETF Trust's Legal Provisions 356 Relating to IETF Documents 357 (http://trustee.ietf.org/license-info). 359 This version of this YANG module is part of RFC XXXX; see the 360 RFC itself for full legal notices."; 362 revision 2022-01-25 { 363 description "First revision."; 364 reference "RFC XXXX: A YANG Data Model for In-Situ OAM"; 365 } 367 /* 368 * FEATURES 369 */ 370 feature incremental-trace 371 { 372 description 373 "This feature indicated that the incremental tracing option is 374 supported"; 375 reference "RFC XXXX: Data Fields for In-situ OAM"; 376 } 378 feature preallocated-trace 379 { 380 description 381 "This feature indicated that the preallocated tracing option is 382 supported"; 383 reference "RFC XXXX: Data Fields for In-situ OAM"; 384 } 386 feature direct-export 387 { 388 description 389 "This feature indicated that the direct export option is 390 supported"; 391 reference "RFC XXXX: In-situ OAM Direct Exporting"; 392 } 394 feature proof-of-transit 395 { 396 description 397 "This feature indicated that the proof of transit option is 398 supported"; 399 reference "RFC XXXX: Data Fields for In-situ OAM"; 400 } 402 feature edge-to-edge 403 { 404 description 405 "This feature indicated that the edge to edge option is 406 supported"; 407 reference "RFC XXXX: Data Fields for In-situ OAM"; 408 } 410 /* 411 * IDENTITIES 412 */ 413 identity filter { 414 description 415 "Base identity to represent a filter. A filter is used to 416 specify the flow to apply the IOAM profile. "; 417 } 418 identity acl-filter { 419 base filter; 420 description 421 "Apply ACL rules to specify the flow."; 422 } 424 identity protocol { 425 description 426 "Base identity to represent the carrier protocol. It's used to 427 indicate what layer and protocol the IOAM data is embedded."; 428 } 430 identity ipv6 { 431 base protocol; 432 description 433 "The described IOAM data is embedded in IPv6 protocol."; 434 reference "RFC XXXX: In-situ OAM IPv6 Options"; 435 } 437 identity nsh { 438 base protocol; 439 description 440 "The described IOAM data is embedded in NSH."; 441 reference 442 "RFC XXXX: Network Service Header (NSH) Encapsulation 443 for In-situ OAM (IOAM) Data"; 444 } 446 identity node-action { 447 description 448 "Base identity to represent the node actions. It's used to 449 indicate what action the node will take."; 450 } 452 identity action-encapsulate { 453 base node-action; 454 description 455 "indicate the node is to encapsulate the IOAM packet"; 456 } 458 identity action-decapsulate { 459 base node-action; 460 description 461 "indicate the node is to decapsulate the IOAM packet"; 462 } 464 identity trace-type { 465 description 466 "Base identity to represent trace types"; 467 } 469 identity trace-hop-lim-node-id { 470 base trace-type; 471 description 472 "indicates presence of Hop_Lim and node_id in the 473 node data."; 474 } 476 identity trace-if-id { 477 base trace-type; 478 description 479 "indicates presence of ingress_if_id and egress_if_id 480 (short format) in the node data."; 481 } 483 identity trace-timestamp-seconds { 484 base trace-type; 485 description 486 "indicates presence of timestamp seconds in the node data."; 487 } 489 identity trace-timestamp-fraction { 490 base trace-type; 491 description 492 "indicates presence of timestamp fraction in the node data."; 493 } 495 identity trace-transit-delay { 496 base trace-type; 497 description 498 "indicates presence of transit delay in the node data."; 499 } 501 identity trace-namespace-data { 502 base trace-type; 503 description 504 "indicates presence of namespace specific data (short format) 505 in the node data."; 506 } 508 identity trace-queue-depth { 509 base trace-type; 510 description 511 "indicates presence of queue depth in the node data."; 512 } 513 identity trace-checksum-complement { 514 base trace-type; 515 description 516 "indicates presence of the Checksum Complement node data."; 517 } 519 identity trace-hop-lim-node-id-wide { 520 base trace-type; 521 description 522 "indicates presence of Hop_Lim and node_id in wide format 523 in the node data."; 524 } 526 identity trace-if-id-wide { 527 base trace-type; 528 description 529 "indicates presence of ingress_if_id and egress_if_id in 530 wide format in the node data."; 531 } 533 identity trace-namespace-data-wide { 534 base trace-type; 535 description 536 "indicates presence of IOAM-Namespace specific data in wide 537 format in the node data."; 538 } 540 identity trace-buffer-occupancy { 541 base trace-type; 542 description 543 "indicates presence of buffer occupancy in the node data."; 544 } 546 identity trace-opaque-state-snapshot { 547 base trace-type; 548 description 549 "indicates presence of variable length Opaque State Snapshot 550 field."; 551 } 553 identity pot-type { 554 description 555 "Base identity to represent Proof of Transit (PoT) types."; 556 } 558 identity pot-type-0 { 559 base pot-type; 560 description 561 "The IOAM POT Type field value is 0. And POT data is a 16 562 Octet field to carry data associated to POT procedures."; 563 } 565 identity e2e-type { 566 description 567 "Base identity to represent e2e types"; 568 } 570 identity e2e-seq-num-64 { 571 base e2e-type; 572 description 573 "indicates presence of a 64-bit sequence number."; 574 } 576 identity e2e-seq-num-32 { 577 base e2e-type; 578 description 579 "indicates presence of a 32-bit sequence number."; 580 } 582 identity e2e-timestamp-seconds { 583 base e2e-type; 584 description 585 "indicates presence of timestamp seconds representing the time 586 at which the packet entered the IOAM-domain"; 587 } 589 identity e2e-timestamp-fraction { 590 base e2e-type; 591 description 592 "indicates presence of timestamp fraction representing the time 593 at which the packet entered the IOAM-domain."; 594 } 596 identity namespace { 597 description 598 "Base identity to represent the Namespace-ID."; 599 } 601 identity default-namespace { 602 base namespace; 603 description 604 "The Namespace-ID value of 0x0000 is defined as the 605 Default-Namespace-ID and must be known to all the nodes 606 implementing IOAM."; 607 } 609 /* 610 * TYPE DEFINITIONS 611 */ 612 typedef ioam-filter-type { 613 type identityref { 614 base filter; 615 } 616 description 617 "Specifies a known type of filter."; 618 } 620 typedef ioam-protocol-type { 621 type identityref { 622 base protocol; 623 } 624 description 625 "Specifies a known type of carrier protocol for the IOAM data."; 626 } 628 typedef ioam-node-action { 629 type identityref { 630 base node-action; 631 } 632 description 633 "Specifies a known type of node action."; 634 } 636 typedef ioam-trace-type { 637 type identityref { 638 base trace-type; 639 } 640 description 641 "Specifies a known trace type."; 642 } 644 typedef ioam-pot-type { 645 type identityref { 646 base pot-type; 647 } 648 description 649 "Specifies a known pot type."; 650 } 652 typedef ioam-e2e-type { 653 type identityref { 654 base e2e-type; 655 } 656 description 657 "Specifies a known e2e type."; 658 } 660 typedef ioam-namespace { 661 type identityref { 662 base namespace; 663 } 664 description 665 "Specifies the supported namespace."; 666 } 668 /* 669 * GROUP DEFINITIONS 670 */ 672 grouping ioam-filter { 673 description "A grouping for IOAM filter definition"; 675 leaf filter-type { 676 type ioam-filter-type; 677 description "filter type"; 678 } 680 leaf ace-name { 681 when "../filter-type = 'ioam:acl-filter'"; 682 type leafref { 683 path "/acl:acls/acl:acl/acl:aces/acl:ace/acl:name"; 684 } 685 description "Access Control Entry name."; 686 } 687 } 689 grouping encap-tracing { 690 description 691 "A grouping for the generic configuration for 692 tracing profile."; 694 container trace-types { 695 description 696 "the list of trace types for encapsulation"; 698 leaf use-namespace { 699 type ioam-namespace; 700 description 701 "the namespace used for encapsulation"; 702 } 704 leaf-list trace-type { 705 type ioam-trace-type; 706 description 707 "The trace type is only defined at the encapsulation node."; 708 } 709 } 711 leaf enable-loopback-mode { 712 type boolean; 713 default false; 714 description 715 "Loopback mode is used to send a copy of a packet back towards 716 the source. The loopback mode is only defined at the 717 encapsulation node."; 718 } 720 leaf enable-active-mode { 721 type boolean; 722 default false; 723 description 724 "Active mode indicates that a packet is used for active 725 measurement. An IOAM decapsulating node that receives a 726 packet with the Active flag set in one of its Trace options 727 must terminate the packet."; 728 } 729 } 731 grouping ioam-incremental-tracing-profile { 732 description 733 "A grouping for incremental tracing profile."; 735 leaf node-action { 736 type ioam-node-action; 737 description "node action"; 738 } 740 uses encap-tracing { 741 when "node-action = 'ioam:action-encapsulate'"; 742 } 744 leaf max-length { 745 when "../node-action = 'ioam:action-encapsulate'"; 746 type uint32; 747 units bytes; 748 description 749 "This field specifies the maximum length of the node data list 750 in octets. The max-length is only defined at the 751 encapsulation node. And it's only used for the incremental 752 tracing mode."; 754 } 755 } 757 grouping ioam-preallocated-tracing-profile { 758 description 759 "A grouping for incremental tracing profile."; 761 leaf node-action { 762 type ioam-node-action; 763 description "node action"; 764 } 766 uses encap-tracing { 767 when "node-action = 'ioam:action-encapsulate'"; 768 } 769 } 771 grouping ioam-direct-export-profile { 772 description 773 "A grouping for direct export profile."; 775 leaf node-action { 776 type ioam-node-action; 777 description "node action"; 778 } 780 uses encap-tracing { 781 when "node-action = 'ioam:action-encapsulate'"; 782 } 784 leaf flow-id { 785 when "../node-action = 'ioam:action-encapsulate'"; 786 type uint32; 787 description 788 "A 32-bit flow identifier. The field is set at the 789 encapsulating node. The Flow ID can be uniformly assigned 790 by a central controller or algorithmically generated by the 791 encapsulating node. The latter approach cannot guarantee 792 the uniqueness of Flow ID, yet the conflict probability is 793 small due to the large Flow ID space.flow-id is used to 794 correlate the exported data of the same flow from multiple 795 nodes and from multiple packets."; 796 } 797 } 799 grouping ioam-e2e-profile { 800 description 801 "A grouping for edge to edge profile."; 803 leaf node-action { 804 type ioam-node-action; 805 description 806 "indicate how the node act for this profile"; 807 } 809 container e2e-types { 810 when "../node-action = 'ioam:action-encapsulate'"; 811 description 812 "the list of e2e types for encapsulation"; 814 leaf use-namespace { 815 type ioam-namespace; 816 description 817 "the namespace used for encapsulation"; 818 } 820 leaf-list e2e-type { 821 type ioam-e2e-type; 822 description 823 "The e2e type is only defined at the encapsulation node."; 824 } 825 } 826 } 828 grouping ioam-admin-config { 829 description 830 "IOAM top-level administrative configuration."; 832 leaf enabled { 833 type boolean; 834 default false; 835 description 836 "When true, IOAM configuration is enabled for the system. 837 Meanwhile, the IOAM data-plane functionality is enabled."; 838 } 839 } 841 /* 842 * DATA NODES 843 */ 845 container ioam { 846 description "IOAM top level container"; 848 container ioam-info { 849 config false; 850 description 851 "Describes assistant information such as units or timestamp 852 format. So that monitoring systems can interpret the IOAM 853 data."; 855 leaf timestamp-type { 856 type identityref { 857 base lime:timestamp-type; 858 } 859 description 860 "Type of timestamp, such as Truncated PTP or NTP."; 861 } 863 list available-interface { 864 key "if-name"; 865 ordered-by user; 866 description 867 "A list of available interfaces that support IOAM."; 868 leaf if-name { 869 type leafref { 870 path "/if:interfaces/if:interface/if:name"; 871 } 872 description "Interface name."; 873 } 874 } 875 } 877 container ioam-profiles { 878 description 879 "Contains a list of IOAM profiles."; 881 container admin-config { 882 description 883 "Contains all the administrative configurations related to 884 the IOAM functionalities and all the IOAM profiles."; 886 uses ioam-admin-config; 887 } 889 list ioam-profile { 890 key "profile-name"; 891 ordered-by user; 892 description 893 "A list of IOAM profiles that configured on the node."; 895 leaf profile-name { 896 type string; 897 mandatory true; 898 description 899 "Unique identifier for each IOAM profile"; 900 } 902 container filter { 903 uses ioam-filter; 904 description 905 "The filter which is used to indicate the flow to apply 906 IOAM."; 907 } 909 leaf protocol-type { 910 type ioam-protocol-type; 911 description 912 "This item is used to indicate the carrier protocol where 913 the IOAM is applied."; 914 } 916 container incremental-tracing-profile { 917 if-feature incremental-trace; 918 description 919 "describe the profile for incremental tracing option"; 921 leaf enabled { 922 type boolean; 923 default false; 924 description 925 "When true, apply incremental tracing option to the 926 specified flow identified by the filter."; 927 } 929 uses ioam-incremental-tracing-profile; 930 } 932 container preallocated-tracing-profile { 933 if-feature preallocated-trace; 934 description 935 "describe the profile for preallocated tracing option"; 937 leaf enabled { 938 type boolean; 939 default false; 940 description 941 "When true, apply preallocated tracing option to the 942 specified flow identified by the following filter."; 943 } 944 uses ioam-preallocated-tracing-profile; 945 } 947 container direct-export-profile { 948 if-feature direct-export; 949 description 950 "describe the profile for direct-export option"; 952 leaf enabled { 953 type boolean; 954 default false; 955 description 956 "When true, apply direct-export option to the 957 specified flow identified by the following filter."; 958 } 960 uses ioam-direct-export-profile; 961 } 963 container pot-profile { 964 if-feature proof-of-transit; 965 description 966 "describe the profile for PoT option"; 968 leaf enabled { 969 type boolean; 970 default false; 971 description 972 "When true, apply Proof of Transit option to the 973 specified flow identified by the following filter."; 974 } 976 leaf pot-type { 977 type ioam-pot-type; 978 description 979 "The type of a particular POT variant that specifies 980 the POT data that is included.."; 981 } 982 } 984 container e2e-profile { 985 if-feature edge-to-edge; 986 description 987 "describe the profile for e2e option"; 989 leaf enabled { 990 type boolean; 991 default false; 992 description 993 "When true, apply edge to edge option to the 994 specified flow identified by the following filter."; 995 } 997 uses ioam-e2e-profile; 998 } 999 } 1000 } 1001 } 1002 } 1003 1005 5. Security Considerations 1007 The YANG module specified in this document defines a schema for data 1008 that is designed to be accessed via network management protocols such 1009 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1010 is the secure transport layer, and the mandatory-to-implement secure 1011 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1012 is HTTPS, and the mandatory-to-implement secure transport is TLS 1013 [RFC8446]. 1015 The Network Configuration Access Control Model (NACM) [RFC8341] 1016 provides the means to restrict access for particular NETCONF or 1017 RESTCONF users to a preconfigured subset of all available NETCONF or 1018 RESTCONF protocol operations and content. 1020 There are a number of data nodes defined in this YANG module that are 1021 writable/creatable/deletable (i.e., config true, which is the 1022 default). These data nodes may be considered sensitive or vulnerable 1023 in some network environments. Write operations (e.g., edit-config) 1024 to these data nodes without proper protection can have a negative 1025 effect on network operations. These are the subtrees and data nodes 1026 and their sensitivity/vulnerability: 1028 o /ioam/ioam-profiles/admin-config 1030 The items in the container above include the top level administrative 1031 configurations related to the IOAM functionalities and all the IOAM 1032 profiles. Unexpected changes to these items could lead to the IOAM 1033 function disruption and/ or misbehavior of all the IOAM profiles. 1035 o /ioam/ioam-profiles/ioam-profile 1037 The entries in the list above include the whole IOAM profile 1038 configurations which indirectly create or modify the device 1039 configurations. Unexpected changes to these entries could lead to 1040 the mistake of the IOAM behavior for the corresponding flows. 1042 6. IANA Considerations 1044 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1045 actual RFC number (and remove this note). 1047 IANA is requested to assign a new URI from the IETF XML Registry 1048 [RFC3688]. The following URI is suggested: 1050 URI: urn:ietf:params:xml:ns:yang:ietf-ioam 1051 Registrant Contact: The IESG. 1052 XML: N/A; the requested URI is an XML namespace. 1054 This document also requests a new YANG module name in the YANG Module 1055 Names registry [RFC7950] with the following suggestion: 1057 name: ietf-ioam 1058 namespace: urn:ietf:params:xml:ns:yang:ietf-ioam 1059 prefix: ioam 1060 reference: RFC XXXX 1062 7. Acknowledgements 1064 For their valuable comments, discussions, and feedback, we wish to 1065 acknowledge Greg Mirsky, Reshad Rahman, Tom Petch and Mickey Spiegel. 1067 8. References 1069 8.1. Normative References 1071 [I-D.ietf-ippm-ioam-data] 1072 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 1073 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 1074 progress), December 2021. 1076 [I-D.ietf-ippm-ioam-direct-export] 1077 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 1078 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 1079 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 1080 export-07 (work in progress), October 2021. 1082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1083 Requirement Levels", BCP 14, RFC 2119, 1084 DOI 10.17487/RFC2119, March 1997, 1085 . 1087 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1088 DOI 10.17487/RFC3688, January 2004, 1089 . 1091 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1092 and A. Bierman, Ed., "Network Configuration Protocol 1093 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1094 . 1096 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1097 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1098 . 1100 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1101 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1102 . 1104 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1105 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1106 . 1108 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1109 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1110 May 2017, . 1112 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1113 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1114 . 1116 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1117 Access Control Model", STD 91, RFC 8341, 1118 DOI 10.17487/RFC8341, March 2018, 1119 . 1121 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1122 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1123 . 1125 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1126 "YANG Data Model for Network Access Control Lists (ACLs)", 1127 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1128 . 1130 8.2. Informative References 1132 [I-D.ietf-ippm-ioam-ipv6-options] 1133 Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", 1134 draft-ietf-ippm-ioam-ipv6-options-06 (work in progress), 1135 July 2021. 1137 [I-D.ietf-sfc-ioam-nsh] 1138 Brockners, F. and S. Bhandari, "Network Service Header 1139 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 1140 ietf-sfc-ioam-nsh-06 (work in progress), July 2021. 1142 Appendix A. Examples 1144 This appendix is non-normative. 1146 tbd 1148 Authors' Addresses 1150 Tianran Zhou 1151 Huawei 1152 156 Beiqing Rd. 1153 Beijing 100095 1154 China 1156 Email: zhoutianran@huawei.com 1158 Jim Guichard 1159 Futurewei 1160 United States of America 1162 Email: james.n.guichard@futurewei.com 1164 Frank Brockners 1165 Cisco Systems 1166 Hansaallee 249, 3rd Floor 1167 Duesseldorf, Nordrhein-Westfalen 40549 1168 Germany 1170 Email: fbrockne@cisco.com 1171 Srihari Raghavan 1172 Cisco Systems 1173 Tril Infopark Sez, Ramanujan IT City 1174 Neville Block, 2nd floor, Old Mahabalipuram Road 1175 Chennai, Tamil Nadu 600113 1176 India 1178 Email: srihari@cisco.com