idnits 2.17.1 draft-zhou-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 223 has weird spacing: '...e-index ioa...' == Line 226 has weird spacing: '...ynomial uin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 02, 2018) is 2123 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-03 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-06 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 Summary: 2 errors (**), 0 flaws (~~), 7 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 J. Guichard 4 Intended status: Standards Track Huawei 5 Expires: January 3, 2019 F. Brockners 6 S. Raghavan 7 Cisco Systems 8 July 02, 2018 10 A YANG Data Model for In-Situ OAM 11 draft-zhou-ippm-ioam-yang-02 13 Abstract 15 In-situ Operations, Administration, and Maintenance (IOAM) records 16 operational and telemetry information in user packets while the 17 packets traverse a path between two points in the network. This 18 document defines a YANG module for the IOAM function. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 3, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Design of the IOAM YANG Data Model . . . . . . . . . . . . . 3 63 2.1. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Preallocated Tracing Profile . . . . . . . . . . . . . . 4 65 2.3. Incremental Tracing Profile . . . . . . . . . . . . . . . 5 66 2.4. Proof of Transit Profile . . . . . . . . . . . . . . . . 5 67 2.5. Edge to Edge Profile . . . . . . . . . . . . . . . . . . 5 68 3. IOAM YANG Module . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 74 7.2. Informative References . . . . . . . . . . . . . . . . . 18 75 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 In-situ Operations, Administration, and Maintenance (IOAM) 81 [I-D.ietf-ippm-ioam-data] records OAM information within user packets 82 while the packets traverse a network. The data types and data 83 formats for IOAM data records have been defined in 84 [I-D.ietf-ippm-ioam-data]. The IOAM data can be embedded in many 85 protocol encapsulations such as Network Services Header, Segment 86 Routing, and IPv6 [I-D.brockners-inband-oam-transport]. 88 This document defines a data model for IOAM capabilities using the 89 YANG data modeling language [RFC7950]. This YANG model supports all 90 the three categories of IOAM data, which are Tracing Option, Proof of 91 Transit Option, and Edge-to-Edge Option. 93 1.1. Tree Diagrams 95 The meaning of the symbols in these diagrams is as follows: 97 o Brackets "[" and "]" enclose list keys. 99 o Curly braces "{" and "}" contain names of optional features that 100 make the corresponding node conditional. 102 o Abbreviations before data node names: "rw" means configuration 103 (read-write), "ro" state data (read-only). 105 o Symbols after data node names: "?" means an optional node, "!" a 106 container with presence, and "*" denotes a "list" or "leaf-list". 108 o Parentheses enclose choice and case nodes, and case nodes are also 109 marked with a colon (":"). 111 o Ellipsis ("...") stands for contents of subtrees that are not 112 shown. 114 2. Design of the IOAM YANG Data Model 116 2.1. Profiles 118 The IOAM model is organized as list of profiles as shown in the 119 following figure. Each profile associates with one flow and the 120 corresponding IOAM information. 122 module: ietf-ioam 123 +--rw ioam 124 +--rw ioam-profiles 125 +--rw admin-config 126 | +--rw enabled? boolean 127 +--rw ioam-profile* [profile-name] 128 +--rw profile-name string 129 +--rw filter 130 | +--rw filter-type? ioam-filter-type 131 | +--rw acl-name? -> /acl:acls/acl/name 132 +--rw protocol-type? ioam-protocol-type 133 +--rw incremental-tracing-profile {incremental-trace}? 134 | ... 135 +--rw preallocated-tracing-profile {preallocated-trace}? 136 | ... 137 +--rw pot-profile {proof-of-transit}? 138 | ... 139 +--rw e2e-profile {edge-to-edge}? 140 ... 142 The "enabled" is an administrative configuration. When it is set to 143 true, IOAM configuration is enabled for the system. Meanwhile, the 144 IOAM data-plane functionality is enabled. 146 The "filter" is used to identify a flow, where the IOAM profile can 147 apply. There may be multiple filter types. ACL is the default one. 149 The IOAM data can be encapsulated into multiple protocols, e.g., IPv6 150 [RFC8200], Geneve [I-D.ietf-nvo3-geneve],VxLAN-GPE 151 [I-D.ietf-nvo3-vxlan-gpe]. The "protocol-type" is used to indicate 152 where the IOAM is applied. For example, if the "protocol-type" is 153 IPv6, the IOAM ingress node will encapsulate the associated flow with 154 the IPv6-IOAM [I-D.brockners-inband-oam-transport] format. 156 IOAM data includes three usage options with four encapsulation types, 157 i.e., incremental tracing data, preallocated tracing data, prove of 158 transit data and end to end data. In practice, multiple IOAM data 159 types can be encapsulated into the same IOAM header. The "ioam- 160 profile" contains a set of sub-profiles, each of which relates to one 161 encapsulation type. The configured object may not support all the 162 sub-profiles. The supported sub-profiles are indicated by 4 defined 163 features, i.e., "incremental-trace", "preallocated-trace", "proof-of- 164 transit", "edge-to-edge". 166 2.2. Preallocated Tracing Profile 168 The IOAM tracing data is expected to be collected at every node that 169 a packet traverses to ensure visibility into the entire path a packet 170 takes within an IOAM domain. The preallocated tracing option will 171 create pre-allocated space for each node to populate its information 172 . The "preallocated-tracing-profile" contains the detailed 173 information for the preallocated tracing data. The information 174 includes: 176 o enabled: indicates whether the preallocated tracing profile is 177 enabled. 179 o node-action: indicates the operation (e.g., encapsulate IOAM 180 header, transit the IOAM data, or decapsulate IOAM header) applied 181 to the dedicated flow. 183 o trace-type: indicates the per-hop data to be captured by the IOAM 184 enabled nodes and included in the node data list. 186 o Loopback mode is used to send a copy of a packet back towards the 187 source. 189 +--rw preallocated-tracing-profile {preallocated-trace}? 190 +--rw enabled? boolean 191 +--rw node-action? ioam-node-action 192 +--rw trace-type? ioam-trace-types 193 +--rw enable-loopback-mode? boolean 195 2.3. Incremental Tracing Profile 197 The incremental tracing option contains a variable node data fields 198 where each node allocates and pushes its node data immediately 199 following the option header. The "incremental-tracing-profile" 200 contains the detailed information for the incremental tracing data. 201 The detailed information is the same as the Preallocated Tracing 202 Profile, but with one more variable, "max-length", which restricts 203 the length of the IOAM header. 205 +--rw incremental-tracing-profile {incremental-trace}? 206 +--rw enabled? boolean 207 +--rw node-action? ioam-node-action 208 +--rw trace-type? ioam-trace-types 209 +--rw enable-loopback-mode? boolean 210 +--rw max-length? uint32 212 2.4. Proof of Transit Profile 214 The IOAM Proof of Transit data is to support the path or service 215 function chain verification use cases. The "pot-profile" contains 216 the detailed information for the prove of transit data. The detailed 217 information are described in [I-D.brockners-proof-of-transit]. 219 +--rw pot-profile {proof-of-transit}? 220 +--rw enabled? boolean 221 +--rw active-profile-index? ioam-profile-index-range 222 +--rw pot-profile-list* [pot-profile-index] 223 +--rw pot-profile-index ioam-profile-index-range 224 +--rw prime-number uint64 225 +--rw secret-share uint64 226 +--rw public-polynomial uint64 227 +--rw lpc uint64 228 +--rw validator? boolean 229 +--rw validator-key? uint64 230 +--rw bitmask? uint64 232 2.5. Edge to Edge Profile 234 The IOAM edge to edge option is to carry data that is added by the 235 IOAM encapsulating node and interpreted by IOAM decapsulating node. 237 The "e2e-profile" contains the detailed information for the edge to 238 edge data. The detailed information includes: 240 o enabled: indicates whether the edge to edge profile is enabled. 242 o node-action is the same semantic as in Section 2.2. 244 o e2e-type indicates data to be carried from the ingress IOAM node 245 to the egress IOAM node. 247 +--rw e2e-profile {edge-to-edge}? 248 +--rw enabled? boolean 249 +--rw node-action? ioam-node-action 250 +--rw e2e-type? ioam-e2e-types 252 3. IOAM YANG Module 254 file "ietf-ioam@2018-07-02.yang" 255 module ietf-ioam { 256 yang-version 1.1; 257 namespace "urn:ietf:params:xml:ns:yang:ietf-ioam"; 258 prefix "ioam"; 259 import ietf-pot-profile { 260 prefix "pot"; 261 } 263 import ietf-access-control-list { 264 prefix "acl"; 265 } 267 organization 268 "IETF IPPM (IP Performance Metrics) Working Group"; 270 contact 271 "WG Web: 272 WG List: 273 Editor: zhoutianran@huawei.com"; 275 description 276 "This YANG module specifies a vendor-independent data 277 model for the in Situ OAM (iOAM)."; 279 revision 2018-07-02 { 280 description "Initial revision."; 281 reference "draft-zhou-ippm-ioam-yang"; 282 } 284 /* 285 * FEATURES 286 */ 288 feature incremental-trace 289 { 290 description 291 "This feature indicated that the incremental tracing mode is 292 supported"; 293 } 295 feature preallocated-trace 296 { 297 description 298 "This feature indicated that the preallocated tracing mode is 299 supported"; 300 } 302 feature proof-of-transit 303 { 304 description 305 "This feature indicated that the proof of transit mode is 306 supported"; 307 } 309 feature edge-to-edge 310 { 311 description 312 "This feature indicated that the edge to edge mode is 313 supported"; 314 } 316 /* 317 * IDENTITIES 318 */ 319 identity base-filter { 320 description 321 "Base identity to represent a filter. A filter is used to 322 specify the flow to apply the iOAM profile. "; 323 } 325 identity acl-filter { 326 base base-filter; 327 description 328 "Apply ACL rule to specify the flow."; 329 } 331 identity base-protocol { 332 description 333 "Base identity to represent the carrier protocol. It's used to 334 indicate what layer and protocol the iOAM data is embedded."; 335 } 337 identity ipv6-protocol { 338 base base-protocol; 339 description 340 "The described iOAM data is embedded in ipv6 protocol."; 341 } 343 identity base-node-action { 344 description 345 "Base identity to represent the node actions. It's used to 346 indicate what action the node will take."; 347 } 349 identity encapsulate { 350 base base-node-action; 351 description 352 "indicate the node is to encapsulate the iOAM packet"; 353 } 355 identity transit { 356 base base-node-action; 357 description 358 "indicate the node is to transit the iOAM packet"; 359 } 361 identity decapsulate { 362 base base-node-action; 363 description 364 "indicate the node is to decapsulate the iOAM packet"; 365 } 367 /* 368 * TYPE DEFINITIONS 369 */ 371 typedef ioam-filter-type { 372 type identityref { 373 base base-filter; 374 } 375 description 376 "Specifies a known type of filter."; 377 } 379 typedef ioam-protocol-type { 380 type identityref { 381 base base-protocol; 382 } 383 description 384 "Specifies a known type of carrier protocol for the iOAM data."; 385 } 387 typedef ioam-node-action { 388 type identityref { 389 base base-node-action; 390 } 391 description 392 "Specifies a known type of node action."; 393 } 395 typedef ioam-trace-types { 396 type bits { 397 bit ioam-hop-lim-node-id { 398 position 0; 399 description 400 "When set indicates presence of Hop_Lim and node_id in the 401 node data."; 402 } 403 bit ioam-if-id { 404 position 1; 405 description 406 "When set indicates presence of ingress_if_id and 407 egress_if_id in the node data."; 408 } 409 bit ioam-timestamp-seconds { 410 position 2; 411 description 412 "When set indicates presence of time stamp seconds in the 413 node data."; 414 } 415 bit ioam-timestamp-nanoseconds { 416 position 3; 417 description 418 "When set indicates presence of time stamp nanoseconds in 419 the node data."; 420 } 421 bit ioam-transit-delay { 422 position 4; 423 description 424 "When set indicates presence of transit delay in the node 425 data."; 426 } 427 bit ioam-app-data { 428 position 5; 429 description 430 "When set indicates presence of app_data in the node data."; 431 } 432 bit ioam-queue-depth { 433 position 6; 434 description 435 "When set indicates presence of queue depth in the node 436 data."; 437 } 438 bit ioam-opaque-state-snapshot { 439 position 7; 440 description 441 "When set indicates presence of variable length Opaque 442 State Snapshot field."; 443 } 444 bit ioam-hop-lim-node-id-wide { 445 position 8; 446 description 447 "When set indicates presence of Hop_Lim and node_id wide 448 in the node data."; 449 } 450 bit ioam-if-id-wide { 451 position 9; 452 description 453 "When set indicates presence of ingress_if_id and 454 egress_if_id wide in the node data."; 455 } 456 bit app-data-wide { 457 position 10; 458 description 459 "When set indicates presence of app_data wide in the node 460 data."; 461 } 462 } 463 description 464 "A 16-bit identifier which specifies which data types are used 465 in this node data list."; 466 } 468 typedef ioam-pot-types { 469 type bits { 470 bit ioam-bytes-16 { 471 position 0; 472 description 473 "POT data is a 16 Octet field"; 474 } 475 } 476 description 477 "7-bit identifier of a particular POT variant that dictates 478 the POT data that is included."; 479 } 481 typedef ioam-e2e-types { 482 type bits { 483 bit ioam-seq-num { 484 position 0; 485 description 486 "A 64-bit sequence number added to a specific tube which is 487 used to identify packet loss and reordering for that 488 tube."; 489 } 490 } 491 description 492 "8-bit identifier of a particular in situ OAM E2E variant."; 493 } 495 /* 496 * GROUP DEFINITIONS 497 */ 499 grouping ioam-filter { 500 description "A grouping for iOAM filter definition"; 502 leaf filter-type { 503 type ioam-filter-type; 504 description "filter type"; 505 } 507 leaf acl-name { 508 when "../filter-type = 'acl-filter'"; 509 type leafref { 510 path "/acl:acls/acl:acl/acl:name"; 511 } 512 description "Access Control List name."; 513 } 514 } 516 grouping ioam-incremental-tracing-profile { 517 description 518 "A grouping for incremental tracing profile."; 520 leaf node-action { 521 type ioam-node-action; 522 description "node action"; 523 } 524 leaf trace-type { 525 when "../node-action = 'encapsulate'"; 526 type ioam-trace-types; 527 description 528 "The trace type is only defined at the encapsulation node."; 529 } 531 leaf enable-loopback-mode { 532 when "../node-action = 'encapsulate'"; 533 type boolean; 534 default false; 535 description 536 "Loopback mode is used to send a copy of a packet back towards 537 the source. The loopback mode is only defined at the 538 encapsulation node."; 539 } 541 leaf max-length { 542 when "../node-action = 'encapsulate'"; 543 type uint32; 544 description 545 "This field specifies the maximum length of the node data list 546 in octets. The max-length is only defined at the 547 encapsulation node. And it's only used for the incremental 548 tracing mode."; 549 } 550 } 552 grouping ioam-preallocated-tracing-profile { 553 description 554 "A grouping for incremental tracing profile."; 556 leaf node-action { 557 type ioam-node-action; 558 description "node action"; 559 } 561 leaf trace-type { 562 when "../node-action = 'encapsulate'"; 563 type ioam-trace-types; 564 description 565 "The trace type is only defined at the encapsulation node."; 566 } 568 leaf enable-loopback-mode { 569 when "../node-action = 'encapsulate'"; 570 type boolean; 571 default false; 572 description 573 "Loopback mode is used to send a copy of a packet back towards 574 the source. The loopback mode is only defined at the 575 encapsulation node."; 576 } 577 } 579 grouping ioam-e2e-profile { 580 description 581 "A grouping for tracing profile."; 583 leaf node-action { 584 type ioam-node-action; 585 description 586 "indicate how the node act for this profile"; 587 } 589 leaf e2e-type { 590 when "../node-action = 'encapsulate'"; 591 type ioam-e2e-types; 592 description 593 "The e2e type is only defined at the encapsulation node."; 594 } 595 } 597 grouping ioam-admin-config { 598 description 599 "IOAM top-level administrative configuration."; 601 leaf enabled { 602 type boolean; 603 default false; 604 description 605 "When true, IOAM configuration is enabled for the system. 606 Meanwhile, the IOAM data-plane functionality is enabled."; 607 } 608 } 610 /* 611 * DATA NODES 612 */ 614 container ioam { 615 description "iOAM top level container"; 617 container ioam-profiles { 618 description 619 "Contains a list of iOAM profiles."; 621 container admin-config { 622 description 623 "Contains all the administrative configurations related to 624 the IOAM functionalities and all the IOAM profiles."; 626 uses ioam-admin-config; 627 } 629 list ioam-profile { 630 key "profile-name"; 631 ordered-by user; 632 description 633 "A list of iOAM profiles that configured on the node."; 635 leaf profile-name { 636 type string; 637 mandatory true; 638 description 639 "Unique identifier for each iOAM profile"; 640 } 642 container filter { 643 uses ioam-filter; 644 description 645 "The filter which is used to indicate the flow to apply 646 iOAM."; 647 } 649 leaf protocol-type { 650 type ioam-protocol-type; 651 description 652 "This item is used to indicate the carrier protocol where 653 the iOAM is applied."; 654 } 656 container incremental-tracing-profile { 657 if-feature incremental-trace; 658 description 659 "describe the profile for incremental tracing option"; 661 leaf enabled { 662 type boolean; 663 default false; 664 description 665 "When true, apply incremental tracing option to the 666 specified flow identified by the filter."; 667 } 668 uses ioam-incremental-tracing-profile; 669 } 671 container preallocated-tracing-profile { 672 if-feature preallocated-trace; 673 description 674 "describe the profile for preallocated tracing option"; 676 leaf enabled { 677 type boolean; 678 default false; 679 description 680 "When true, apply preallocated tracing option to the 681 specified flow identified by the following filter."; 682 } 684 uses ioam-preallocated-tracing-profile; 685 } 687 container pot-profile { 688 if-feature proof-of-transit; 689 description 690 "describe the profile for pot option"; 692 leaf enabled { 693 type boolean; 694 default false; 695 description 696 "When true, apply Proof of Transit option to the 697 specified flow identified by the following filter."; 698 } 700 leaf active-profile-index { 701 type pot:profile-index-range; 702 description 703 "Proof of transit profile index that is currently 704 active. Will be set in the first hop of the path 705 or chain. Other nodes will not use this field."; 706 } 708 uses pot:pot-profile; 709 } 711 container e2e-profile { 712 if-feature edge-to-edge; 713 description 714 "describe the profile for e2e option"; 716 leaf enabled { 717 type boolean; 718 default false; 719 description 720 "When true, apply End to end option to the 721 specified flow identified by the following filter."; 722 } 724 uses ioam-e2e-profile; 725 } 726 } 727 } 728 } 729 } 730 732 4. Security Considerations 734 The YANG module specified in this document defines a schema for data 735 that is designed to be accessed via network management protocols such 736 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 737 is the secure transport layer, and the mandatory-to-implement secure 738 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 739 is HTTPS, and the mandatory-to-implement secure transport is TLS 740 [RFC5246]. 742 The NETCONF access control model [RFC6536] provides the means to 743 restrict access for particular NETCONF or RESTCONF users to a 744 preconfigured subset of all available NETCONF or RESTCONF protocol 745 operations and content. 747 There are a number of data nodes defined in this YANG module that are 748 writable/creatable/deletable (i.e., config true, which is the 749 default). These data nodes may be considered sensitive or vulnerable 750 in some network environments. Write operations (e.g., edit-config) 751 to these data nodes without proper protection can have a negative 752 effect on network operations. These are the subtrees and data nodes 753 and their sensitivity/vulnerability: 755 o /ioam/ioam-profiles/admin-config 757 The items in the container above include the top level administrative 758 configurations related to the IOAM functionalities and all the IOAM 759 profiles. Unexpected changes to these items could lead to the IOAM 760 function disruption and/ or misbehavior of all the IOAM profiles. 762 o /ioam/ioam-profiles/ioam-profile 763 The entries in the list above include the whole IOAM profile 764 configurations which indirectly create or modify the device 765 configurations. Unexpected changes to these entries could lead to 766 the mistake of the IOAM behavior for the corresponding flows. 768 5. IANA Considerations 770 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 771 actual RFC number (and remove this note). 773 IANA is requested to assign a new URI from the IETF XML Registry 774 [RFC3688]. The following URI is suggested: 776 URI: urn:ietf:params:xml:ns:yang:ietf-ioam 777 Registrant Contact: The IESG. 778 XML: N/A; the requested URI is an XML namespace. 780 This document also requests a new YANG module name in the YANG Module 781 Names registry [RFC7950] with the following suggestion: 783 name: ietf-ioam 784 namespace: urn:ietf:params:xml:ns:yang:ietf-ioam 785 prefix: ioam 786 reference: RFC XXXX 788 6. Acknowledgements 790 For their valuable comments, discussions, and feedback, we wish to 791 acknowledge Greg Mirsky and Reshad Rahman. 793 7. References 795 7.1. Normative References 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, 799 DOI 10.17487/RFC2119, March 1997, 800 . 802 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 803 DOI 10.17487/RFC3688, January 2004, 804 . 806 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 807 (TLS) Protocol Version 1.2", RFC 5246, 808 DOI 10.17487/RFC5246, August 2008, 809 . 811 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 812 and A. Bierman, Ed., "Network Configuration Protocol 813 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 814 . 816 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 817 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 818 . 820 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 821 Protocol (NETCONF) Access Control Model", RFC 6536, 822 DOI 10.17487/RFC6536, March 2012, 823 . 825 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 826 RFC 7950, DOI 10.17487/RFC7950, August 2016, 827 . 829 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 830 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 831 . 833 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 834 (IPv6) Specification", STD 86, RFC 8200, 835 DOI 10.17487/RFC8200, July 2017, 836 . 838 7.2. Informative References 840 [I-D.brockners-inband-oam-transport] 841 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 842 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 843 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 844 situ OAM Data", draft-brockners-inband-oam-transport-05 845 (work in progress), July 2017. 847 [I-D.brockners-proof-of-transit] 848 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 849 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 850 of Transit", draft-brockners-proof-of-transit-05 (work in 851 progress), May 2018. 853 [I-D.ietf-ippm-ioam-data] 854 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 855 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 856 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 857 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 858 data-03 (work in progress), June 2018. 860 [I-D.ietf-nvo3-geneve] 861 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 862 Network Virtualization Encapsulation", draft-ietf- 863 nvo3-geneve-06 (work in progress), March 2018. 865 [I-D.ietf-nvo3-vxlan-gpe] 866 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 867 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 868 in progress), April 2018. 870 Appendix A. Examples 872 TBD 874 Authors' Addresses 876 Tianran Zhou 877 Huawei 878 156 Beiqing Rd. 879 Beijing 100095 880 China 882 Email: zhoutianran@huawei.com 884 Jim Guichard 885 Huawei 886 United States of America 888 Email: james.n.guichard@huawei.com 890 Frank Brockners 891 Cisco Systems 892 Hansaallee 249, 3rd Floor 893 Duesseldorf, Nordrhein-Westfalen 40549 894 Germany 896 Email: fbrockne@cisco.com 897 Srihari Raghavan 898 Cisco Systems 899 Tril Infopark Sez, Ramanujan IT City 900 Neville Block, 2nd floor, Old Mahabalipuram Road 901 Chennai, Tamil Nadu 600113 902 India 904 Email: srihari@cisco.com