idnits 2.17.1 draft-ietf-ippm-ioam-yang-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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (14 January 2022) is 834 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 (-11) exists of draft-ietf-ippm-ioam-direct-export-07 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-06 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-06 Summary: 3 errors (**), 0 flaws (~~), 5 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: 18 July 2022 Futurewei 6 F. Brockners 7 S. Raghavan 8 Cisco Systems 9 14 January 2022 11 A YANG Data Model for In-Situ OAM 12 draft-ietf-ippm-ioam-yang-02 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 18 July 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 3 56 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Design of the IOAM YANG Data Model . . . . . . . . . . . . . 3 58 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Preallocated Tracing Profile . . . . . . . . . . . . . . 5 60 3.3. Incremental Tracing Profile . . . . . . . . . . . . . . . 6 61 3.4. Direct Export Profile . . . . . . . . . . . . . . . . . . 6 62 3.5. Proof of Transit Profile . . . . . . . . . . . . . . . . 6 63 3.6. Edge to Edge Profile . . . . . . . . . . . . . . . . . . 7 64 4. IOAM YANG Module . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 70 8.2. Informative References . . . . . . . . . . . . . . . . . 24 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 25 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 74 1. Introduction 76 In-situ Operations, Administration, and Maintenance (IOAM) 77 [I-D.ietf-ippm-ioam-data] records OAM information within user packets 78 while the packets traverse a network. The data types and data 79 formats for IOAM data records have been defined in 80 [I-D.ietf-ippm-ioam-data]. The IOAM data can be embedded in many 81 protocol encapsulations such as Network Services Header (NSH) and 82 IPv6. 84 This document defines a data model for IOAM capabilities using the 85 YANG data modeling language [RFC7950]. This YANG model supports five 86 IOAM options, which are Incremental Tracing Option, Pre-allocated 87 Tracing Option, Direct Export 88 Option[I-D.ietf-ippm-ioam-direct-export], Proof of Transit (PoT) 89 Option, and Edge-to-Edge Option. 91 2. Conventions used in this document 93 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 The following terms are defined in [RFC7950] and are used in this 100 specification: 102 * augment 104 * data model 106 * data node 108 The terminology for describing YANG data models is found in 109 [RFC7950]. 111 2.1. Tree Diagrams 113 Tree diagrams used in this document follow the notation defined in 114 [RFC8340]. 116 3. Design of the IOAM YANG Data Model 118 3.1. Overview 120 The IOAM model is organized as list of profiles as shown in the 121 following figure. Each profile associates with one flow and the 122 corresponding IOAM information. 124 The "ioam-info" is a container for all the read only assistant 125 information, so that monitoring systems can interpret the IOAM data. 127 module: ietf-ioam 128 +--rw ioam 129 +--ro ioam-info 130 | +--ro timestamp-type? identityref 131 | +--ro available-interface* [if-name] 132 | +--ro if-name -> if:interfaces/interface/name 133 +--rw ioam-profiles 134 +--rw admin-config 135 | +--rw enabled? boolean 136 +--rw ioam-profile* [profile-name] 137 +--rw profile-name string 138 +--rw filter 139 | +--rw filter-type? ioam-filter-type 140 | +--rw ace-name? -> /acl:acls/acl/aces/ace/name 141 +--rw protocol-type? ioam-protocol-type 142 +--rw incremental-tracing-profile {incremental-trace}? 143 | ... 144 +--rw preallocated-tracing-profile {preallocated-trace}? 145 | ... 146 +--rw direct-export-profile {direct-export}? 147 | ... 148 +--rw pot-profile {proof-of-transit}? 149 | ... 150 +--rw e2e-profile {edge-to-edge}? 151 ... 153 In the "ioam-profiles", the "enabled" is an administrative 154 configuration. When it is set to true, IOAM configuration is enabled 155 for the system. Meanwhile, the IOAM data-plane functionality is 156 enabled. 158 The "filter" is used to identify a flow, where the IOAM profile can 159 apply. There may be multiple filter types. ACL [RFC8519] is a 160 common way to specify a flow. Each IOAM profile can associate with 161 an ACE(Access Control Entry). IOAM actions MUST be driven by the 162 accepted packets, when the matched ACE "forwarding" action is 163 "accept". 165 The IOAM data can be encapsulated into multiple protocols, e.g., IPv6 166 [I-D.ietf-ippm-ioam-ipv6-options] and NSH [I-D.ietf-sfc-ioam-nsh]. 167 The "protocol-type" is used to indicate where the IOAM is applied. 168 For example, if the "protocol-type" is IPv6, the IOAM ingress node 169 will encapsulate the associated flow with the IPv6-IOAM 170 [I-D.ietf-ippm-ioam-ipv6-options] format. 172 IOAM data includes five encapsulation types, i.e., incremental 173 tracing data, preallocated tracing data, direct export data, prove of 174 transit data and end to end data. In practice, multiple IOAM data 175 types can be encapsulated into the same IOAM header. The "ioam- 176 profile" contains a set of sub-profiles, each of which relates to one 177 encapsulation type. The configured object may not support all the 178 sub-profiles. The supported sub-profiles are indicated by 5 defined 179 features, i.e., "incremental-trace", "preallocated-trace", "direct 180 export", "proof-of-transit", "edge-to-edge". 182 3.2. Preallocated Tracing Profile 184 The IOAM tracing data is expected to be collected at every node that 185 a packet traverses to ensure visibility into the entire path a packet 186 takes within an IOAM domain. The preallocated tracing option will 187 create pre-allocated space for each node to populate its information 188 . The "preallocated-tracing-profile" contains the detailed 189 information for the preallocated tracing data. The information 190 includes: 192 * enabled: indicates whether the preallocated tracing profile is 193 enabled. 195 * node-action: indicates the operation (e.g., encapsulate IOAM 196 header, transit the IOAM data, or decapsulate IOAM header) applied 197 to the dedicated flow. 199 * use-namespace: indicate the namespace used for the trace types. 201 * trace-type: indicates the per-hop data to be captured by the IOAM 202 enabled nodes and included in the node data list. 204 * Loopback mode is used to send a copy of a packet back towards the 205 source. 207 * Active mode indicates that a packet is used for active 208 measurement. 210 +--rw preallocated-tracing-profile {preallocated-trace}? 211 +--rw enabled? boolean 212 +--rw node-action? ioam-node-action 213 +--rw trace-types 214 | +--rw use-namespace? ioam-namespace 215 | +--rw trace-type* ioam-trace-type 216 +--rw enable-loopback-mode? boolean 217 +--rw enable-active-mode? boolean 219 3.3. Incremental Tracing Profile 221 The incremental tracing option contains a variable node data fields 222 where each node allocates and pushes its node data immediately 223 following the option header. The "incremental-tracing-profile" 224 contains the detailed information for the incremental tracing data. 225 The detailed information is the same as the Preallocated Tracing 226 Profile, but with one more variable, "max-length", which restricts 227 the length of the IOAM header. 229 +--rw incremental-tracing-profile {incremental-trace}? 230 +--rw enabled? boolean 231 +--rw node-action? ioam-node-action 232 +--rw trace-types 233 | +--rw use-namespace? ioam-namespace 234 | +--rw trace-type* ioam-trace-type 235 +--rw enable-loopback-mode? boolean 236 +--rw enable-active-mode? boolean 237 +--rw max-length? uint32 239 3.4. Direct Export Profile 241 The direct export option is used as a trigger for IOAM nodes to 242 export IOAM data to a receiving entity (or entities). The "direct- 243 export-profile" contains the detailed information for the direct 244 export data. The detailed information is the same as the 245 Preallocated Tracing Profile, but with one more optional variable, 246 "flow-id", which is used to correlate the exported data of the same 247 flow from multiple nodes and from multiple packets. 249 +--rw direct-export-profile {direct-export}? 250 +--rw enabled? boolean 251 +--rw node-action? ioam-node-action 252 +--rw trace-types 253 | +--rw use-namespace? ioam-namespace 254 | +--rw trace-type* ioam-trace-type 255 +--rw enable-loopback-mode? boolean 256 +--rw enable-active-mode? boolean 257 +--rw flow-id? uint32 259 3.5. Proof of Transit Profile 261 The IOAM Proof of Transit data is to support the path or service 262 function chain verification use cases. The "pot-profile" contains 263 the detailed information for the proof of transit data. "pot-type" 264 indicates a particular POT variant that specifies the POT data that 265 is included. There may be several POT types, which have different 266 configuration data. To align with [I-D.ietf-ippm-ioam-data], this 267 document only defines IOAM POT type 0. User need to augment this 268 module for the configuration of a specifc POT type. 270 +--rw pot-profile {proof-of-transit}? 271 +--rw enabled? boolean 272 +--rw pot-type? ioam-pot-type 274 3.6. Edge to Edge Profile 276 The IOAM edge to edge option is to carry data that is added by the 277 IOAM encapsulating node and interpreted by IOAM decapsulating node. 278 The "e2e-profile" contains the detailed information for the edge to 279 edge data. The detailed information includes: 281 * enabled: indicates whether the edge to edge profile is enabled. 283 * node-action is the same semantic as in Section 2.2. 285 * use-namespace: indicate the namespace used for the edge to edge 286 types. 288 * e2e-type indicates data to be carried from the ingress IOAM node 289 to the egress IOAM node. 291 +--rw e2e-profile {edge-to-edge}? 292 +--rw enabled? boolean 293 +--rw node-action? ioam-node-action 294 +--rw e2e-types 295 +--rw use-namespace? ioam-namespace 296 +--rw e2e-type* ioam-e2e-type 298 4. IOAM YANG Module 300 file "ietf-ioam@2021-01-12.yang" 301 module ietf-ioam { 302 yang-version 1.1; 303 namespace "urn:ietf:params:xml:ns:yang:ietf-ioam"; 304 prefix "ioam"; 306 import ietf-access-control-list { 307 prefix "acl"; 308 reference 309 "RFC 8519: YANG Data Model for Network Access Control 310 Lists (ACLs)"; 311 } 313 import ietf-interfaces { 314 prefix "if"; 315 reference 316 "RFC 8343: A YANG Data Model for Interface Management"; 317 } 319 import ietf-lime-time-types { 320 prefix "lime"; 321 reference 322 "RFC RFC 8532: Generic YANG Data Model for the Management of 323 Operations, Administration, and Maintenance (OAM) Protocols 324 That Use Connectionless Communications"; 325 } 327 organization 328 "IETF IPPM (IP Performance Metrics) Working Group"; 330 contact 331 "WG Web: 332 WG List: 333 Editor: zhoutianran@huawei.com 334 Editor: james.n.guichard@futurewei.com 335 Editor: fbrockne@cisco.com 336 Editor: srihari@cisco.com"; 338 description 339 "This YANG module specifies a vendor-independent data 340 model for the In Situ OAM (IOAM). 342 Copyright (c) 2021 IETF Trust and the persons identified as 343 authors of the code. All rights reserved. 345 Redistribution and use in source and binary forms, with or 346 without modification, is permitted pursuant to, and subject 347 to the license terms contained in, the Simplified BSD License 348 set forth in Section 4.c of the IETF Trust's Legal Provisions 349 Relating to IETF Documents 350 (http://trustee.ietf.org/license-info). 352 This version of this YANG module is part of RFC XXXX; see the 353 RFC itself for full legal notices."; 355 revision 2022-01-12 { 356 description "Firstd revision."; 357 reference "draft-ietf-ippm-ioam-yang"; 358 } 360 /* 361 * FEATURES 362 */ 364 feature incremental-trace 365 { 366 description 367 "This feature indicated that the incremental tracing option is 368 supported"; 369 reference "draft-ietf-ippm-ioam-data"; 370 } 372 feature preallocated-trace 373 { 374 description 375 "This feature indicated that the preallocated tracing option is 376 supported"; 377 reference "draft-ietf-ippm-ioam-data"; 378 } 380 feature direct-export 381 { 382 description 383 "This feature indicated that the direct export option is 384 supported"; 385 reference "ietf-ippm-ioam-direct-export"; 386 } 388 feature proof-of-transit 389 { 390 description 391 "This feature indicated that the proof of transit option is 392 supported"; 393 reference "draft-ietf-ippm-ioam-data"; 394 } 396 feature edge-to-edge 397 { 398 description 399 "This feature indicated that the edge to edge option is 400 supported"; 401 reference "draft-ietf-ippm-ioam-data"; 402 } 404 /* 405 * IDENTITIES 406 */ 407 identity base-filter { 408 description 409 "Base identity to represent a filter. A filter is used to 410 specify the flow to apply the IOAM profile. "; 411 } 413 identity acl-filter { 414 base base-filter; 415 description 416 "Apply ACL rules to specify the flow."; 417 } 419 identity base-protocol { 420 description 421 "Base identity to represent the carrier protocol. It's used to 422 indicate what layer and protocol the IOAM data is embedded."; 423 } 425 identity ipv6-protocol { 426 base base-protocol; 427 description 428 "The described IOAM data is embedded in IPv6 protocol."; 429 reference "ietf-ippm-ioam-ipv6-options"; 430 } 432 identity nsh-protocol { 433 base base-protocol; 434 description 435 "The described IOAM data is embedded in NSH."; 436 reference "ietf-sfc-ioam-nsh"; 437 } 439 identity base-node-action { 440 description 441 "Base identity to represent the node actions. It's used to 442 indicate what action the node will take."; 443 } 445 identity action-encapsulate { 446 base base-node-action; 447 description 448 "indicate the node is to encapsulate the IOAM packet"; 449 } 451 identity action-decapsulate { 452 base base-node-action; 453 description 454 "indicate the node is to decapsulate the IOAM packet"; 455 } 457 identity base-trace-type { 458 description 459 "Base identity to represent trace types"; 460 } 462 identity trace-hop-lim-node-id { 463 base base-trace-type; 464 description 465 "indicates presence of Hop_Lim and node_id in the 466 node data."; 467 } 469 identity trace-if-id { 470 base base-trace-type; 471 description 472 "indicates presence of ingress_if_id and egress_if_id in the 473 node data."; 474 } 476 identity trace-timestamp-seconds { 477 base base-trace-type; 478 description 479 "indicates presence of time stamp seconds in the node data."; 480 } 482 identity trace-timestamp-nanoseconds { 483 base base-trace-type; 484 description 485 "indicates presence of time stamp nanoseconds in the node data."; 486 } 488 identity trace-transit-delay { 489 base base-trace-type; 490 description 491 "indicates presence of transit delay in the node data."; 492 } 494 identity trace-namespace-data { 495 base base-trace-type; 496 description 497 "indicates presence of namespace specific data (short format) 498 in the node data."; 499 } 501 identity trace-queue-depth { 502 base base-trace-type; 503 description 504 "indicates presence of queue depth in the node data."; 505 } 506 identity trace-opaque-state-snapshot { 507 base base-trace-type; 508 description 509 "indicates presence of variable length Opaque State Snapshot 510 field."; 511 } 513 identity trace-hop-lim-node-id-wide { 514 base base-trace-type; 515 description 516 "indicates presence of Hop_Lim and node_id wide in the 517 node data."; 518 } 520 identity trace-if-id-wide { 521 base base-trace-type; 522 description 523 "indicates presence of ingress_if_id and egress_if_id wide in 524 the node data."; 525 } 527 identity trace-namespace-data-wide { 528 base base-trace-type; 529 description 530 "indicates presence of namespace specific data in wide format 531 in the node data."; 532 } 534 identity trace-buffer-occupancy { 535 base base-trace-type; 536 description 537 "indicates presence of buffer occupancy in the node data."; 538 } 540 identity trace-checksum-complement { 541 base base-trace-type; 542 description 543 "indicates presence of the Checksum Complement node data."; 544 } 546 identity base-pot-type { 547 description 548 "Base identity to represent Proof of Transit(PoT) types"; 549 } 551 identity pot-type-0 { 552 base base-pot-type; 553 description 554 "POT data is a 16 Octet field to carry data associated to 555 POT procedures."; 556 } 558 identity base-e2e-type { 559 description 560 "Base identity to represent e2e types"; 561 } 563 identity e2e-seq-num-64 { 564 base base-e2e-type; 565 description 566 "indicates presence of a 64-bit sequence number"; 567 } 569 identity e2e-seq-num-32 { 570 base base-e2e-type; 571 description 572 "indicates presence of a 32-bit sequence number"; 573 } 575 identity e2e-timestamp-seconds { 576 base base-e2e-type; 577 description 578 "indicates presence of timestamp seconds for the 579 transmission of the frame"; 580 } 582 identity e2e-timestamp-subseconds { 583 base base-e2e-type; 584 description 585 "indicates presence of timestamp subseconds for the 586 transmission of the frame"; 587 } 589 identity base-namespace { 590 description 591 "Base identity to represent the namespace"; 592 } 594 identity namespace-ietf { 595 base base-namespace; 596 description 597 "namespace that specified in IETF."; 598 } 600 /* 601 * TYPE DEFINITIONS 602 */ 603 typedef ioam-filter-type { 604 type identityref { 605 base base-filter; 606 } 607 description 608 "Specifies a known type of filter."; 609 } 611 typedef ioam-protocol-type { 612 type identityref { 613 base base-protocol; 614 } 615 description 616 "Specifies a known type of carrier protocol for the IOAM data."; 617 } 619 typedef ioam-node-action { 620 type identityref { 621 base base-node-action; 622 } 623 description 624 "Specifies a known type of node action."; 625 } 627 typedef ioam-trace-type { 628 type identityref { 629 base base-trace-type; 630 } 631 description 632 "Specifies a known trace type."; 633 } 635 typedef ioam-pot-type { 636 type identityref { 637 base base-pot-type; 638 } 639 description 640 "Specifies a known pot type."; 641 } 643 typedef ioam-e2e-type { 644 type identityref { 645 base base-e2e-type; 646 } 647 description 648 "Specifies a known e2e type."; 649 } 650 typedef ioam-namespace { 651 type identityref { 652 base base-namespace; 653 } 654 description 655 "Specifies the supported namespace."; 656 } 658 /* 659 * GROUP DEFINITIONS 660 */ 662 grouping ioam-filter { 663 description "A grouping for IOAM filter definition"; 665 leaf filter-type { 666 type ioam-filter-type; 667 description "filter type"; 668 } 670 leaf ace-name { 671 when "../filter-type = 'ioam:acl-filter'"; 672 type leafref { 673 path "/acl:acls/acl:acl/acl:aces/acl:ace/acl:name"; 674 } 675 description "Access Control Entry name."; 676 } 677 } 679 grouping encap-tracing { 680 description 681 "A grouping for the generic configuration for 682 tracing profile."; 684 container trace-types { 685 description 686 "the list of trace types for encapsulate"; 688 leaf use-namespace { 689 type ioam-namespace; 690 description 691 "the namespace used for the encapsulation"; 692 } 694 leaf-list trace-type { 695 type ioam-trace-type; 696 description 697 "The trace type is only defined at the encapsulation node."; 699 } 700 } 702 leaf enable-loopback-mode { 703 type boolean; 704 default false; 705 description 706 "Loopback mode is used to send a copy of a packet back towards 707 the source. The loopback mode is only defined at the 708 encapsulation node."; 709 } 711 leaf enable-active-mode { 712 type boolean; 713 default false; 714 description 715 "Active mode indicates that a packet is used for active 716 measurement. An IOAM decapsulating node that receives a 717 packet with the Active flag set in one of its Trace options 718 must terminate the packet."; 719 } 720 } 722 grouping ioam-incremental-tracing-profile { 723 description 724 "A grouping for incremental tracing profile."; 726 leaf node-action { 727 type ioam-node-action; 728 description "node action"; 729 } 731 uses encap-tracing { 732 when "node-action = 'ioam:action-encapsulate'"; 733 } 735 leaf max-length { 736 when "../node-action = 'ioam:action-encapsulate'"; 737 type uint32; 738 units bytes; 739 description 740 "This field specifies the maximum length of the node data list 741 in octets. The max-length is only defined at the 742 encapsulation node. And it's only used for the incremental 743 tracing mode."; 744 } 745 } 746 grouping ioam-preallocated-tracing-profile { 747 description 748 "A grouping for incremental tracing profile."; 750 leaf node-action { 751 type ioam-node-action; 752 description "node action"; 753 } 755 uses encap-tracing { 756 when "node-action = 'ioam:action-encapsulate'"; 757 } 758 } 760 grouping ioam-direct-export-profile { 761 description 762 "A grouping for direct export profile."; 764 leaf node-action { 765 type ioam-node-action; 766 description "node action"; 767 } 769 uses encap-tracing { 770 when "node-action = 'ioam:action-encapsulate'"; 771 } 773 leaf flow-id { 774 when "../node-action = 'ioam:action-encapsulate'"; 775 type uint32; 776 description 777 "A 32-bit flow identifier. The field is set at the 778 encapsulating node. The Flow ID can be uniformly assigned 779 by a central controller or algorithmically generated by the 780 encapsulating node. The latter approach cannot guarantee 781 the uniqueness of Flow ID, yet the conflict probability is 782 small due to the large Flow ID space.flow-id is used to 783 correlate the exported data of the same flow from multiple 784 nodes and from multiple packets."; 785 } 786 } 788 grouping ioam-e2e-profile { 789 description 790 "A grouping for end to end profile."; 792 leaf node-action { 793 type ioam-node-action; 794 description 795 "indicate how the node act for this profile"; 796 } 798 container e2e-types { 799 when "../node-action = 'ioam:action-encapsulate'"; 800 description 801 "the list of e2e types for encapsulate"; 803 leaf use-namespace { 804 type ioam-namespace; 805 description 806 "the namespace used for the encapsulation"; 807 } 809 leaf-list e2e-type { 810 type ioam-e2e-type; 811 description 812 "The e2e type is only defined at the encapsulation node."; 813 } 814 } 815 } 817 grouping ioam-admin-config { 818 description 819 "IOAM top-level administrative configuration."; 821 leaf enabled { 822 type boolean; 823 default false; 824 description 825 "When true, IOAM configuration is enabled for the system. 826 Meanwhile, the IOAM data-plane functionality is enabled."; 827 } 828 } 830 /* 831 * DATA NODES 832 */ 834 container ioam { 835 description "IOAM top level container"; 837 container ioam-info { 838 config false; 839 description 840 "Describes assistant information such as units or timestamp 841 format. So that monitoring systems can interpret the IOAM 842 data."; 844 leaf timestamp-type { 845 type identityref { 846 base lime:timestamp-type; 847 } 848 description 849 "Type of timestamp, such as Truncated PTP or NTP."; 850 } 852 list available-interface { 853 key "if-name"; 854 ordered-by user; 855 description 856 "A list of available interfaces that support IOAM."; 857 leaf if-name { 858 type leafref { 859 path "/if:interfaces/if:interface/if:name"; 860 } 861 description "Interface name."; 862 } 863 } 864 } 866 container ioam-profiles { 867 description 868 "Contains a list of IOAM profiles."; 870 container admin-config { 871 description 872 "Contains all the administrative configurations related to 873 the IOAM functionalities and all the IOAM profiles."; 875 uses ioam-admin-config; 876 } 878 list ioam-profile { 879 key "profile-name"; 880 ordered-by user; 881 description 882 "A list of IOAM profiles that configured on the node."; 884 leaf profile-name { 885 type string; 886 mandatory true; 887 description 888 "Unique identifier for each IOAM profile"; 890 } 892 container filter { 893 uses ioam-filter; 894 description 895 "The filter which is used to indicate the flow to apply 896 IOAM."; 897 } 899 leaf protocol-type { 900 type ioam-protocol-type; 901 description 902 "This item is used to indicate the carrier protocol where 903 the IOAM is applied."; 904 } 906 container incremental-tracing-profile { 907 if-feature incremental-trace; 908 description 909 "describe the profile for incremental tracing option"; 911 leaf enabled { 912 type boolean; 913 default false; 914 description 915 "When true, apply incremental tracing option to the 916 specified flow identified by the filter."; 917 } 919 uses ioam-incremental-tracing-profile; 920 } 922 container preallocated-tracing-profile { 923 if-feature preallocated-trace; 924 description 925 "describe the profile for preallocated tracing option"; 927 leaf enabled { 928 type boolean; 929 default false; 930 description 931 "When true, apply preallocated tracing option to the 932 specified flow identified by the following filter."; 933 } 935 uses ioam-preallocated-tracing-profile; 936 } 937 container direct-export-profile { 938 if-feature direct-export; 939 description 940 "describe the profile for direct-export option"; 942 leaf enabled { 943 type boolean; 944 default false; 945 description 946 "When true, apply direct-export option to the 947 specified flow identified by the following filter."; 948 } 950 uses ioam-direct-export-profile; 951 } 953 container pot-profile { 954 if-feature proof-of-transit; 955 description 956 "describe the profile for PoT option"; 958 leaf enabled { 959 type boolean; 960 default false; 961 description 962 "When true, apply Proof of Transit option to the 963 specified flow identified by the following filter."; 964 } 966 leaf pot-type { 967 type ioam-pot-type; 968 description 969 "The type of a particular POT variant that specifies 970 the POT data that is included.."; 971 } 972 } 974 container e2e-profile { 975 if-feature edge-to-edge; 976 description 977 "describe the profile for e2e option"; 979 leaf enabled { 980 type boolean; 981 default false; 982 description 983 "When true, apply End to end option to the 984 specified flow identified by the following filter."; 986 } 988 uses ioam-e2e-profile; 989 } 990 } 991 } 992 } 993 } 994 996 5. Security Considerations 998 The YANG module specified in this document defines a schema for data 999 that is designed to be accessed via network management protocols such 1000 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1001 is the secure transport layer, and the mandatory-to-implement secure 1002 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1003 is HTTPS, and the mandatory-to-implement secure transport is TLS 1004 [RFC5246]. 1006 The NETCONF access control model [RFC6536] provides the means to 1007 restrict access for particular NETCONF or RESTCONF users to a 1008 preconfigured subset of all available NETCONF or RESTCONF protocol 1009 operations and content. 1011 There are a number of data nodes defined in this YANG module that are 1012 writable/creatable/deletable (i.e., config true, which is the 1013 default). These data nodes may be considered sensitive or vulnerable 1014 in some network environments. Write operations (e.g., edit-config) 1015 to these data nodes without proper protection can have a negative 1016 effect on network operations. These are the subtrees and data nodes 1017 and their sensitivity/vulnerability: 1019 * /ioam/ioam-profiles/admin-config 1021 The items in the container above include the top level administrative 1022 configurations related to the IOAM functionalities and all the IOAM 1023 profiles. Unexpected changes to these items could lead to the IOAM 1024 function disruption and/ or misbehavior of all the IOAM profiles. 1026 * /ioam/ioam-profiles/ioam-profile 1028 The entries in the list above include the whole IOAM profile 1029 configurations which indirectly create or modify the device 1030 configurations. Unexpected changes to these entries could lead to 1031 the mistake of the IOAM behavior for the corresponding flows. 1033 6. IANA Considerations 1035 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1036 actual RFC number (and remove this note). 1038 IANA is requested to assign a new URI from the IETF XML Registry 1039 [RFC3688]. The following URI is suggested: 1041 URI: urn:ietf:params:xml:ns:yang:ietf-ioam 1042 Registrant Contact: The IESG. 1043 XML: N/A; the requested URI is an XML namespace. 1045 This document also requests a new YANG module name in the YANG Module 1046 Names registry [RFC7950] with the following suggestion: 1048 name: ietf-ioam 1049 namespace: urn:ietf:params:xml:ns:yang:ietf-ioam 1050 prefix: ioam 1051 reference: RFC XXXX 1053 7. Acknowledgements 1055 For their valuable comments, discussions, and feedback, we wish to 1056 acknowledge Greg Mirsky, Reshad Rahman, Tom Petch and Mickey Spiegel. 1058 8. References 1060 8.1. Normative References 1062 [I-D.ietf-ippm-ioam-data] 1063 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 1064 for In-situ OAM", Work in Progress, Internet-Draft, draft- 1065 ietf-ippm-ioam-data-17, 13 December 2021, 1066 . 1069 [I-D.ietf-ippm-ioam-direct-export] 1070 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 1071 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 1072 OAM Direct Exporting", Work in Progress, Internet-Draft, 1073 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 1074 . 1077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1078 Requirement Levels", BCP 14, RFC 2119, 1079 DOI 10.17487/RFC2119, March 1997, 1080 . 1082 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1083 DOI 10.17487/RFC3688, January 2004, 1084 . 1086 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1087 (TLS) Protocol Version 1.2", RFC 5246, 1088 DOI 10.17487/RFC5246, August 2008, 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 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1101 Protocol (NETCONF) Access Control Model", RFC 6536, 1102 DOI 10.17487/RFC6536, March 2012, 1103 . 1105 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1106 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1107 . 1109 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1110 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1111 . 1113 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1114 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1115 May 2017, . 1117 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1118 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1119 . 1121 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1122 "YANG Data Model for Network Access Control Lists (ACLs)", 1123 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1124 . 1126 8.2. Informative References 1128 [I-D.ietf-ippm-ioam-ipv6-options] 1129 Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", 1130 Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- 1131 ipv6-options-06, 31 July 2021, 1132 . 1135 [I-D.ietf-sfc-ioam-nsh] 1136 Brockners, F. and S. Bhandari, "Network Service Header 1137 (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in 1138 Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-06, 31 1139 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 1154 100095 1155 China 1157 Email: zhoutianran@huawei.com 1159 Jim Guichard 1160 Futurewei 1161 United States of America 1163 Email: james.n.guichard@futurewei.com 1165 Frank Brockners 1166 Cisco Systems 1167 Hansaallee 249, 3rd Floor 1168 40549 Duesseldorf 1169 Germany 1171 Email: fbrockne@cisco.com 1172 Srihari Raghavan 1173 Cisco Systems 1174 Tril Infopark Sez, Ramanujan IT City 1175 Neville Block, 2nd floor, Old Mahabalipuram Road 1176 Chennai 600113 1177 Tamil Nadu 1178 India 1180 Email: srihari@cisco.com