idnits 2.17.1 draft-zhou-ippm-ioam-yang-01.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 221 has weird spacing: '...e-index pro...' == Line 224 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 (April 8, 2018) is 2210 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 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-05) exists of draft-brockners-proof-of-transit-04 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-02 == 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-05 Summary: 1 error (**), 0 flaws (~~), 8 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: October 10, 2018 F. Brockners 6 S. Raghavan 7 Cisco Systems 8 April 8, 2018 10 A YANG Data Model for In-Situ OAM 11 draft-zhou-ippm-ioam-yang-01 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 October 10, 2018. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 74 7.2. Informative References . . . . . . . . . . . . . . . . . 17 75 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 +--rw ioam 123 +--rw ioam-profiles 124 +--rw enabled? boolean 125 +--rw ioam-profile* [profile-name] 126 +--rw profile-name string 127 +--rw filter 128 | +--rw filter-type? ioam-filter-type 129 | +--rw acl-name? -> /acl:acls/acl/name 130 +--rw protocol-type? ioam-protocol-type 131 +--rw incremental-tracing-profile {incremental-trace}? 132 | ... 133 +--rw preallocated-tracing-profile {preallocated-trace}? 134 | ... 135 +--rw pot-profile {proof-of-transit}? 136 | ... 137 +--rw e2e-profile {edge-to-edge}? 138 ... 140 The "enabled" is an administrative configuration. When it is set to 141 true, IOAM configuration is enabled for the system. Meanwhile, the 142 IOAM data-plane functionality is enabled. 144 The "filter" is used to identify a flow, where the IOAM profile can 145 apply. There may be multiple filter types. ACL is the default one. 147 The IOAM data can be encapsulated into multiple protocols, e.g., IPv6 148 [RFC8200], Geneve [I-D.ietf-nvo3-geneve],VxLAN-GPE 149 [I-D.ietf-nvo3-vxlan-gpe]. The "protocol-type" is used to indicate 150 where the IOAM is applied. For example, if the "protocol-type" is 151 IPv6, the IOAM ingress node will encapsulate the associated flow with 152 the IPv6-IOAM [I-D.brockners-inband-oam-transport] format. 154 IOAM data includes three usage options with four encapsulation types, 155 i.e., incremental tracing data, preallocated tracing data, prove of 156 transit data and end to end data. In practice, multiple IOAM data 157 types can be encapsulated into the same IOAM header. The "ioam- 158 profile" contains a set of sub-profiles, each of which relates to one 159 encapsulation type. The configured object may not support all the 160 sub-profiles. The supported sub-profiles are indicated by 4 defined 161 features, i.e., "incremental-trace", "preallocated-trace", "proof-of- 162 transit", "edge-to-edge". 164 2.2. Preallocated Tracing Profile 166 The IOAM tracing data is expected to be collected at every node that 167 a packet traverses to ensure visibility into the entire path a packet 168 takes within an IOAM domain. The preallocated tracing option will 169 create pre-allocated space for each node to populate its information 170 . The "preallocated-tracing-profile" contains the detailed 171 information for the preallocated tracing data. The information 172 includes: 174 o enabled: indicates whether the preallocated tracing profile is 175 enabled. 177 o node-action: indicates the operation (e.g., encapsulate IOAM 178 header, transit the IOAM data, or decapsulate IOAM header) applied 179 to the dedicated flow. 181 o trace-type: indicates the per-hop data to be captured by the IOAM 182 enabled nodes and included in the node data list. 184 o Loopback mode is used to send a copy of a packet back towards the 185 source. 187 +--rw preallocated-tracing-profile {preallocated-trace}? 188 +--rw enabled? boolean 189 +--rw node-action? ioam-node-action 190 +--rw trace-type? ioam-trace-types 191 +--rw enable-loopback-mode? boolean 193 2.3. Incremental Tracing Profile 195 The incremental tracing option contains a variable node data fields 196 where each node allocates and pushes its node data immediately 197 following the option header. The "incremental-tracing-profile" 198 contains the detailed information for the incremental tracing data. 199 The detailed information is the same as the Preallocated Tracing 200 Profile, but with one more variable, "max-length", which restricts 201 the length of the IOAM header. 203 +--rw incremental-tracing-profile {incremental-trace}? 204 +--rw enabled? boolean 205 +--rw node-action? ioam-node-action 206 +--rw trace-type? ioam-trace-types 207 +--rw enable-loopback-mode? boolean 208 +--rw max-length? uint32 210 2.4. Proof of Transit Profile 212 The IOAM Proof of Transit data is to support the path or service 213 function chain verification use cases. The "pot-profile" contains 214 the detailed information for the prove of transit data. The detailed 215 information are described in [I-D.brockners-proof-of-transit]. 217 +--rw pot-profile {proof-of-transit}? 218 +--rw enabled? boolean 219 +--rw active-profile-index? pot:profile-index-range 220 +--rw pot-profile-list* [pot-profile-index] 221 +--rw pot-profile-index profile-index-range 222 +--rw prime-number uint64 223 +--rw secret-share uint64 224 +--rw public-polynomial uint64 225 +--rw lpc uint64 226 +--rw validator? boolean 227 +--rw validator-key? uint64 228 +--rw bitmask? uint64 230 2.5. Edge to Edge Profile 232 The IOAM edge to edge option is to carry data that is added by the 233 IOAM encapsulating node and interpreted by IOAM decapsulating node. 235 The "e2e-profile" contains the detailed information for the edge to 236 edge data. The detailed information includes: 238 o enabled: indicates whether the edge to edge profile is enabled. 240 o node-action is the same semantic as in Section 2.2. 242 o e2e-type indicates data to be carried from the ingress IOAM node 243 to the egress IOAM node. 245 +--rw e2e-profile {edge-to-edge}? 246 +--rw enabled? boolean 247 +--rw node-action? ioam-node-action 248 +--rw e2e-type? ioam-e2e-types 250 3. IOAM YANG Module 252 file "ietf-ioam@2018-04-08.yang" 253 module ietf-ioam { 254 yang-version 1.1; 255 namespace "urn:ietf:params:xml:ns:yang:ietf-ioam"; 256 prefix "ioam"; 258 import ietf-pot-profile { 259 prefix "pot"; 260 } 262 import ietf-access-control-list { 263 prefix "acl"; 264 } 266 organization 267 "IETF IPPM (IP Performance Metrics) Working Group"; 269 contact 270 "WG Web: 271 WG List: 272 Editor: zhoutianran@huawei.com"; 274 description 275 "This YANG module specifies a vendor-independent data 276 model for the in Situ OAM (iOAM)."; 278 revision 2018-04-08 { 279 description "Initial revision."; 280 reference "draft-zhou-ippm-ioam-yang"; 281 } 283 /* 284 * FEATURES 285 */ 287 feature incremental-trace 288 { 289 description 290 "This feature indicated that the incremental tracing mode is 291 supported"; 292 } 294 feature preallocated-trace 295 { 296 description 297 "This feature indicated that the preallocated tracing mode is 298 supported"; 299 } 301 feature proof-of-transit 302 { 303 description 304 "This feature indicated that the proof of transit mode is 305 supported"; 306 } 308 feature edge-to-edge 309 { 310 description 311 "This feature indicated that the edge to edge mode is 312 supported"; 313 } 315 /* 316 * IDENTITIES 317 */ 318 identity base-filter { 319 description 320 "Base identity to represent a filter. A filter is used to 321 specify the flow to apply the iOAM profile. "; 322 } 324 identity acl-filter { 325 base base-filter; 326 description 327 "Apply ACL rule to specify the flow."; 328 } 330 identity base-protocol { 331 description 332 "Base identity to represent the carrier protocol. It's used to 333 indicate what layer and protocol the iOAM data is embedded."; 334 } 336 identity ipv6-protocol { 337 base base-protocol; 338 description 339 "The described iOAM data is embedded in ipv6 protocol."; 340 } 342 identity base-node-action { 343 description 344 "Base identity to represent the node actions. It's used to 345 indicate what action the node will take."; 346 } 348 identity encapsulate { 349 base base-node-action; 350 description 351 "indicate the node is to encapsulate the iOAM packet"; 352 } 354 identity transit { 355 base base-node-action; 356 description 357 "indicate the node is to transit the iOAM packet"; 358 } 360 identity decapsulate { 361 base base-node-action; 362 description 363 "indicate the node is to decapsulate the iOAM packet"; 364 } 366 /* 367 * TYPE DEFINITIONS 368 */ 370 typedef ioam-filter-type { 371 type identityref { 372 base base-filter; 373 } 374 description 375 "Specifies a known type of filter."; 376 } 378 typedef ioam-protocol-type { 379 type identityref { 380 base base-protocol; 381 } 382 description 383 "Specifies a known type of carrier protocol for the iOAM data."; 384 } 386 typedef ioam-node-action { 387 type identityref { 388 base base-node-action; 389 } 390 description 391 "Specifies a known type of node action."; 392 } 394 typedef ioam-trace-types { 395 type bits { 396 bit ioam-hop-lim-node-id { 397 position 0; 398 description 399 "When set indicates presence of Hop_Lim and node_id in the 400 node data."; 401 } 402 bit ioam-if-id { 403 position 1; 404 description 405 "When set indicates presence of ingress_if_id and 406 egress_if_id in the node data."; 407 } 408 bit ioam-timestamp-seconds { 409 position 2; 410 description 411 "When set indicates presence of time stamp seconds in the 412 node data."; 413 } 414 bit ioam-timestamp-nanoseconds { 415 position 3; 416 description 417 "When set indicates presence of time stamp nanoseconds in 418 the node data."; 419 } 420 bit ioam-transit-delay { 421 position 4; 422 description 423 "When set indicates presence of transit delay in the node 424 data."; 425 } 426 bit ioam-app-data { 427 position 5; 428 description 429 "When set indicates presence of app_data in the node data."; 430 } 431 bit ioam-queue-depth { 432 position 6; 433 description 434 "When set indicates presence of queue depth in the node 435 data."; 436 } 437 bit ioam-opaque-state-snapshot { 438 position 7; 439 description 440 "When set indicates presence of variable length Opaque 441 State Snapshot field."; 442 } 443 bit ioam-hop-lim-node-id-wide { 444 position 8; 445 description 446 "When set indicates presence of Hop_Lim and node_id wide 447 in the node data."; 448 } 449 bit ioam-if-id-wide { 450 position 9; 451 description 452 "When set indicates presence of ingress_if_id and 453 egress_if_id wide in the node data."; 454 } 455 bit app-data-wide { 456 position 10; 457 description 458 "When set indicates presence of app_data wide in the node 459 data."; 460 } 461 } 462 description 463 "A 16-bit identifier which specifies which data types are used 464 in this node data list."; 465 } 467 typedef ioam-pot-types { 468 type bits { 469 bit ioam-bytes-16 { 470 position 0; 471 description 472 "POT data is a 16 Octet field"; 473 } 474 } 475 description 476 "7-bit identifier of a particular POT variant that dictates 477 the POT data that is included."; 478 } 480 typedef ioam-e2e-types { 481 type bits { 482 bit ioam-seq-num { 483 position 0; 484 description 485 "A 64-bit sequence number added to a specific tube which is 486 used to identify packet loss and reordering for that 487 tube."; 488 } 489 } 490 description 491 "8-bit identifier of a particular in situ OAM E2E variant."; 492 } 494 /* 495 * GROUP DEFINITIONS 496 */ 498 grouping ioam-filter { 499 description "A grouping for iOAM filter definition"; 501 leaf filter-type { 502 type ioam-filter-type; 503 description "filter type"; 504 } 506 leaf acl-name { 507 when "../filter-type = 'acl-filter'"; 508 type leafref { 509 path "/acl:acls/acl:acl/acl:name"; 510 } 511 description "Access Control List name."; 512 } 513 } 515 grouping ioam-incremental-tracing-profile { 516 description 517 "A grouping for incremental tracing profile."; 519 leaf node-action { 520 type ioam-node-action; 521 description "node action"; 522 } 523 leaf trace-type { 524 when "../node-action = 'encapsulate'"; 525 type ioam-trace-types; 526 description 527 "The trace type is only defined at the encapsulation node."; 528 } 530 leaf enable-loopback-mode { 531 when "../node-action = 'encapsulate'"; 532 type boolean; 533 default false; 534 description 535 "Loopback mode is used to send a copy of a packet back towards 536 the source. The loopback mode is only defined at the 537 encapsulation node."; 538 } 540 leaf max-length { 541 when "../node-action = 'encapsulate'"; 542 type uint32; 543 description 544 "This field specifies the maximum length of the node data list 545 in octets. The max-length is only defined at the 546 encapsulation node. And it's only used for the incremental 547 tracing mode."; 548 } 549 } 551 grouping ioam-preallocated-tracing-profile { 552 description 553 "A grouping for incremental tracing profile."; 555 leaf node-action { 556 type ioam-node-action; 557 description "node action"; 558 } 560 leaf trace-type { 561 when "../node-action = 'encapsulate'"; 562 type ioam-trace-types; 563 description 564 "The trace type is only defined at the encapsulation node."; 565 } 567 leaf enable-loopback-mode { 568 when "../node-action = 'encapsulate'"; 569 type boolean; 570 default false; 571 description 572 "Loopback mode is used to send a copy of a packet back towards 573 the source. The loopback mode is only defined at the 574 encapsulation node."; 575 } 576 } 578 grouping ioam-e2e-profile { 579 description 580 "A grouping for tracing profile."; 582 leaf node-action { 583 type ioam-node-action; 584 description 585 "indicate how the node act for this profile"; 586 } 588 leaf e2e-type { 589 when "../node-action = 'encapsulate'"; 590 type ioam-e2e-types; 591 description 592 "The e2e type is only defined at the encapsulation node."; 593 } 594 } 596 grouping ioam-admin-config { 597 description 598 "IOAM top-level administrative configuration."; 600 leaf enabled { 601 type boolean; 602 default false; 603 description 604 "When true, IOAM configuration is enabled for the system. 605 Meanwhile, the IOAM data-plane functionality is enabled."; 606 } 607 } 609 /* 610 * DATA NODES 611 */ 613 container ioam { 614 description "iOAM top level container"; 616 container ioam-profiles { 617 description 618 "Contains a list of iOAM profiles."; 620 uses ioam-admin-config; 622 list ioam-profile { 623 key "profile-name"; 624 ordered-by user; 625 description 626 "A list of iOAM profiles that configured on the node."; 628 leaf profile-name { 629 type string; 630 description 631 "Unique identifier for each iOAM profile"; 632 } 634 container filter { 635 uses ioam-filter; 636 description 637 "The filter which is used to indicate the flow to apply 638 iOAM."; 639 } 641 leaf protocol-type { 642 type ioam-protocol-type; 643 description 644 "This item is used to indicate the carrier protocol where 645 the iOAM is applied."; 646 } 648 container incremental-tracing-profile { 649 if-feature incremental-trace; 650 description 651 "describe the profile for incremental tracing option"; 653 leaf enabled { 654 type boolean; 655 default false; 656 description 657 "When true, apply incremental tracing option to the 658 specified flow identified by the filter."; 659 } 661 uses ioam-incremental-tracing-profile; 662 } 664 container preallocated-tracing-profile { 665 if-feature preallocated-trace; 666 description 667 "describe the profile for preallocated tracing option"; 669 leaf enabled { 670 type boolean; 671 default false; 672 description 673 "When true, apply preallocated tracing option to the 674 specified flow identified by the following filter."; 675 } 677 uses ioam-preallocated-tracing-profile; 678 } 680 container pot-profile { 681 if-feature proof-of-transit; 682 description 683 "describe the profile for pot option"; 685 leaf enabled { 686 type boolean; 687 default false; 688 description 689 "When true, apply Proof of Transit option to the 690 specified flow identified by the following filter."; 691 } 693 leaf active-profile-index { 694 type pot:profile-index-range; 695 description 696 "Proof of transit profile index that is currently 697 active. Will be set in the first hop of the path 698 or chain. Other nodes will not use this field."; 699 } 701 uses pot:pot-profile; 702 } 704 container e2e-profile { 705 if-feature edge-to-edge; 706 description 707 "describe the profile for e2e option"; 709 leaf enabled { 710 type boolean; 711 default false; 712 description 713 "When true, apply End to end option to the 714 specified flow identified by the following filter."; 715 } 716 uses ioam-e2e-profile; 717 } 718 } 719 } 720 } 721 } 722 724 4. IANA Considerations 726 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 727 actual RFC number (and remove this note). 729 This document requests IANA to register the following URI in the 730 "IETF XML Registry" [RFC3688]: 732 URI: urn:ietf:params:xml:ns:yang:ietf-ioam 733 Registrant Contact: The IESG. 734 XML: N/A; the requested URI is an XML namespace. 736 This document requests IANA to register the following YANG module in 737 the "YANG Module Names" registry [RFC7950]. 739 name: ietf-ioam 740 namespace: urn:ietf:params:xml:ns:yang:ietf-ioam 741 prefix: nat 742 reference: RFC XXXX 744 5. Security Considerations 746 The YANG module defined in this memo is designed to be accessed via 747 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 748 secure transport layer and the support of SSH is mandatory to 749 implement secure transport[RFC6242]. The NETCONF access control 750 model [RFC6536] provides means to restrict access by some users to a 751 pre-configured subset of all available NETCONF protocol operations 752 and data. All data nodes defined in the YANG module which can be 753 created, modified and deleted (i.e., config true, which is the 754 default). These data nodes are considered sensitive. Write 755 operations (e.g., edit-config) applied to these data nodes without 756 proper protection can negatively affect network operations. 758 6. Acknowledgements 760 For their valuable comments, discussions, and feedback, we wish to 761 acknowledge Greg Mirsky and Reshad Rahman. 763 7. References 765 7.1. Normative References 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, 769 DOI 10.17487/RFC2119, March 1997, 770 . 772 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 773 DOI 10.17487/RFC3688, January 2004, 774 . 776 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 777 and A. Bierman, Ed., "Network Configuration Protocol 778 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 779 . 781 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 782 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 783 . 785 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 786 Protocol (NETCONF) Access Control Model", RFC 6536, 787 DOI 10.17487/RFC6536, March 2012, 788 . 790 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 791 RFC 7950, DOI 10.17487/RFC7950, August 2016, 792 . 794 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 795 (IPv6) Specification", STD 86, RFC 8200, 796 DOI 10.17487/RFC8200, July 2017, 797 . 799 7.2. Informative References 801 [I-D.brockners-inband-oam-transport] 802 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 803 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 804 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 805 situ OAM Data", draft-brockners-inband-oam-transport-05 806 (work in progress), July 2017. 808 [I-D.brockners-proof-of-transit] 809 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 810 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 811 of Transit", draft-brockners-proof-of-transit-04 (work in 812 progress), October 2017. 814 [I-D.ietf-ippm-ioam-data] 815 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 816 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 817 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 818 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 819 data-02 (work in progress), March 2018. 821 [I-D.ietf-nvo3-geneve] 822 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 823 Network Virtualization Encapsulation", draft-ietf- 824 nvo3-geneve-06 (work in progress), March 2018. 826 [I-D.ietf-nvo3-vxlan-gpe] 827 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 828 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work 829 in progress), October 2017. 831 Appendix A. Examples 833 TBD 835 Authors' Addresses 837 Tianran Zhou 838 Huawei 839 156 Beiqing Rd. 840 Beijing 100095 841 China 843 Phone: 15810236238 844 Email: zhoutianran@huawei.com 846 Jim Guichard 847 Huawei 848 USA 850 Email: james.n.guichard@huawei.com 851 Frank Brockners 852 Cisco Systems 853 Hansaallee 249, 3rd Floor 854 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 855 Germany 857 Email: fbrockne@cisco.com 859 Srihari Raghavan 860 Cisco Systems 861 Tril Infopark Sez, Ramanujan IT City 862 Neville Block, 2nd floor, Old Mahabalipuram Road 863 Chennai, Tamil Nadu 600113 864 India 866 Email: srihari@cisco.com