idnits 2.17.1 draft-ietf-rtgwg-ni-model-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 -- The document date (March 13, 2017) is 2573 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 (-12) exists of draft-ietf-netmod-schema-mount-04 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-01 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-02) exists of draft-ietf-rtgwg-device-model-01 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Berger 3 Internet-Draft LabN Consulting, L.L.C. 4 Intended status: Standards Track C. Hopps 5 Expires: September 14, 2017 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 9 March 13, 2017 11 YANG Network Instances 12 draft-ietf-rtgwg-ni-model-02 14 Abstract 16 This document defines a network instance module. This module along 17 with the logical network element module can be used to manage the 18 logical and virtual resource representations that may be present on a 19 network device. Examples of common industry terms for logical 20 resource representations are Logical Systems or Logical Routers. 21 Examples of common industry terms for virtual resource 22 representations are Virtual Routing and Forwarding (VRF) instances 23 and Virtual Switch Instances (VSIs). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 14, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Status of Work and Open Issues . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Network Instance Policy . . . . . . . . . . . . . . . . . 6 64 3.2. Network Instance Management . . . . . . . . . . . . . . . 7 65 3.3. Network Instance Instantiation . . . . . . . . . . . . . 8 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 7.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 73 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 This document defines the second of two new modules that are defined 79 to support the configuration and operation of network-devices that 80 allow for the partitioning of resources from both, or either, 81 management and networking perspectives. Both make use of the YANG 82 functionality enabled by YANG Schema Mount 83 [I-D.ietf-netmod-schema-mount]. 85 Two forms of resource partitioning are supported: 87 The first form, which is defined in [I-D.ietf-rtgwg-lne-model], 88 provides a logical partitioning of a network device where each 89 partition is separately managed as essentially an independent network 90 element which is 'hosted' by the base network device. These hosted 91 network elements are referred to as logical network elements, or 92 LNEs, and are supported by the logical-network-element module defined 93 in [I-D.ietf-rtgwg-lne-model]. The module is used to identify LNEs 94 and associate resources from the network-device with each LNE. LNEs 95 themselves are represented in YANG as independent network devices; 96 each accessed independently. Optionally, and when supported by the 97 implementation, they may also be accessed from the host system. 98 Examples of vendor terminology for an LNE include logical system or 99 logical router, and virtual switch, chassis, or fabric. 101 The second form, which is defined in this document, provides support 102 what is commonly referred to as Virtual Routing and Forwarding (VRF) 103 instances as well as Virtual Switch Instances (VSI), see [RFC4026]. 104 In this form of resource partitioning multiple control plane and 105 forwarding/bridging instances are provided by and managed via a 106 single (physical or logical) network device. This form of resource 107 partitioning is referred to as Network Instances and are supported by 108 the network-instance module defined below. Configuration and 109 operation of each network-instance is always via the network device 110 and the network-instance module. 112 This document was motivated by, and derived from, 113 [I-D.ietf-rtgwg-device-model]. 115 1.1. Status of Work and Open Issues 117 The top open issues are: 119 1. This document will need to match the evolution and 120 standardization of [I-D.openconfig-netmod-opstate] or 121 [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 123 2. Overview 125 In this document, we consider network devices that support protocols 126 and functions defined within the IETF Routing Area, e.g, routers, 127 firewalls and hosts. Such devices may be physical or virtual, e.g., 128 a classic router with custom hardware or one residing within a 129 server-based virtual machine implementing a virtual network function 130 (VNF). Each device may sub-divide their resources into logical 131 network elements (LNEs) each of which provides a managed logical 132 device. Examples of vendor terminology for an LNE include logical 133 system or logical router, and virtual switch, chassis, or fabric. 134 Each LNE may also support virtual routing and forwarding (VRF) and 135 virtual switching instance (VSI) functions, which are referred to 136 below as a network instances (NIs). This breakdown is represented in 137 Figure 1. 139 ,''''''''''''''''''''''''''''''''''''''''''''''`. 140 | Network Device (Physical or Virtual) | 141 | ..................... ..................... | 142 | : Logical Network : : Logical Network : | 143 | : Element : : Element : | 144 | :+-----+-----+-----+: :+-----+-----+-----+: | 145 | :| Net | Net | Net |: :| Net | Net | Net |: | 146 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 147 | :+-----+-----+-----+: :+-----+-----+-----+: | 148 | : | | | | | | : : | | | | | | : | 149 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 150 | | | | | | | | | | | | | | 151 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 152 | | | | | | | | | | | | 153 Interfaces Interfaces 155 Figure 1: Module Element Relationships 157 A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the 158 model for network instances is covered in Section 3. For more 159 information on how these models may be used within an overall device 160 model structure, see [I-D.ietf-rtgwg-device-model]. 162 The interface management model [RFC7223] is an existing model that is 163 impacted by the definition of LNEs and network instances. This 164 document and [I-D.ietf-rtgwg-lne-model] define augmentations to the 165 interface module to support LNEs and NIs. Similar elements, although 166 perhaps only for LNEs, may also need to be included as part of the 167 definition of the future hardware and QoS modules. 169 Interfaces are a crucial part of any network device's configuration 170 and operational state. They generally include a combination of raw 171 physical interfaces, link-layer interfaces, addressing configuration, 172 and logical interfaces that may not be tied to any physical 173 interface. Several system services, and layer 2 and layer 3 174 protocols may also associate configuration or operational state data 175 with different types of interfaces (these relationships are not shown 176 for simplicity). The interface management model is defined by 177 [RFC7223]. 179 The logical-network-element and network-instance modules augment the 180 existing interface management model in two ways: The first, by the 181 logical-network-element module, adds an identifier which is used on 182 physical interface types to identify an associated LNE. The second, 183 by the network-instance module, adds a name which is used on 184 interface or sub-interface types to identify an associated network 185 instance. Similarly, this name is also added for IPv4 and IPv6 186 types, as defined in [RFC7277]. 188 The interface related augmentations are as follows: 190 module: ietf-logical-network-element 191 augment /if:interfaces/if:interface: 192 +--rw bind-lne-name? string 194 module: ietf-network-instance 195 augment /if:interfaces/if:interface: 196 +--rw bind-network-instance-name? string 197 augment /if:interfaces/if:interface/ip:ipv4: 198 +--rw bind-network-instance-name? string 199 augment /if:interfaces/if:interface/ip:ipv6: 200 +--rw bind-network-instance-name? string 202 The following is an example of envisioned combined usage. The 203 interfaces container includes a number of commonly used components as 204 examples: 206 +--rw if:interfaces 207 | +--rw interface* [name] 208 | +--rw name string 209 | +--rw bind-lne-name? string 210 | +--rw ethernet 211 | | +--rw ni:bind-network-instance-name? string 212 | | +--rw aggregates 213 | | +--rw rstp 214 | | +--rw lldp 215 | | +--rw ptp 216 | +--rw vlans 217 | +--rw tunnels 218 | +--rw ipv4 219 | | +--rw ni:bind-network-instance-name? string 220 | | +--rw arp 221 | | +--rw icmp 222 | | +--rw vrrp 223 | | +--rw dhcp-client 224 | +--rw ipv6 225 | +--rw ni:bind-network-instance-name? string 226 | +--rw vrrp 227 | +--rw icmpv6 228 | +--rw nd 229 | +--rw dhcpv6-client 231 The [RFC7223] defined interface model is structured to include all 232 interfaces in a flat list, without regard to logical or virtual 233 instances (e.g., VRFs) supported on the device. The bind-lne-name 234 and bind-network-instance-name leaves provide the association between 235 an interface and its associated LNE and NI (e.g., VRF or VSI). 237 3. Network Instances 239 The network instance container is used to represent virtual routing 240 and forwarding instances (VRFs) and virtual switching instances 241 (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate 242 routing and switching domains, for example to create virtual private 243 networks, each with their own active protocols and routing/switching 244 policies. The model represents both core/provider and virtual 245 instances. Network instances reuse and build on [RFC8022] and are 246 shown below: 248 module: ietf-network-instance 249 +--rw network-instances 250 +--rw network-instance* [name] 251 +--rw name string 252 +--rw type? identityref 253 +--rw enabled? boolean 254 +--rw description? string 255 +--rw network-instance-policy 256 | ... 257 +--rw root? yang-schema-mount 258 | ... 259 augment /if:interfaces/if:interface: 260 +--rw bind-network-instance-name? string 261 augment /if:interfaces/if:interface/ip:ipv4: 262 +--rw bind-network-instance-name? string 263 augment /if:interfaces/if:interface/ip:ipv6: 264 +--rw bind-network-instance-name? string 266 A network instance is identified by a `name` string. This string is 267 used both as an index within the network-instance module and to 268 associate resources with a network instance as shown above in the 269 interface augmentation. Type is used to indicate the type NI, such 270 as L3-VRF, VPLS, L2-VSI, etc. Network instance policy and root are 271 discussed in greater detail below. 273 3.1. Network Instance Policy 275 Network instance policies are used to control how NI information is 276 represented at the device level, VRF routing policies, and VRF/VSI 277 identifiers. Examples include BGP route targets (RTs) and route 278 distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS 279 neighbors, etc. The structure is expected to be: 281 module: ietf-network-instance 282 +--rw network-instances 283 +--rw network-instance* [name] 284 +--rw network-instance-policy 285 (TBD) 287 3.2. Network Instance Management 289 Modules that may be used to represent network instance specific 290 information will be available under `root`. As with LNEs, actual 291 module availability is expected to be implementation dependent. The 292 use-schema mechanism defined as part of the Schema Mount module 293 [I-D.ietf-netmod-schema-mount] is expected to be the primary method 294 used to identify supported modules. Resource related control and 295 assignment is expected to be managed at the network-device level, not 296 the network instance level, based on the `bind-network-instance-name` 297 augmentation mentioned above. Mounted modules will access such 298 information, as well as any other information contained within a 299 module at the device root, by using the parent-reference mechanism 300 defined in [I-D.ietf-netmod-schema-mount]. 302 As an example, consider the case where a network instance with a 303 `name` of "green" is defined on a network device. In this case the 304 following logical structure might be made available: 306 +--rw yanglib:modules-state [RFC7895] 307 +--rw if:interfaces [RFC7223] 308 | +--rw bind-network-instance-name="green" string 309 +--rw network-instances 310 +--rw network-instance* [name] 311 +--rw name="green" string 312 +--rw type? identityref 313 +--rw enabled=true boolean 314 +--rw description="The Green VRF" string 315 +--rw network-instance-policy 316 | ... (RT=1000:1, RD=1.2.3.4) 317 +--rw root? yang-schema-mount 319 with a corresponding logical structure in the schema-mount module: 321 module: ietf-yang-schema-mount 322 +--ro schema-mounts 323 : 324 +--ro mount-point* [module name] 325 | +--ro module="ietf-network-instance" 326 | +--ro name="root" 327 | +--ro config=true 328 | +--ro (schema-ref)? 329 | +--:(use-schema) 330 | +--ro use-schema* [name] 331 | +--ro name="ni-vrf" 332 : : 333 : 334 +--ro schema* [name] 335 +--ro name="ni-vrf" string 336 +--ro module* [name revision] 337 | +--ro name="mm:network-services" 338 : : 339 | +--ro name="nn:oam-protocols" 340 : : 341 | +--ro name="oo:routing" 342 : : 343 | +--ro name="pp:mpls" 344 : : 345 +--ro mount-point* [network-instance] 346 : 348 All modules that represent control-plane and data-plane information 349 may be present at the `root`, and be accessible via paths modified 350 per [I-D.ietf-netmod-schema-mount]. The list of available modules is 351 expected to be implementation dependent. As is the method used by an 352 implementation to support NIs. 354 3.3. Network Instance Instantiation 356 Network instances may be controlled by clients using existing list 357 operations. When list entries are created, a new instance is 358 instantiated. The models mounted under a NI root is expected to be 359 dependent on the server implementation. When a list entry is 360 deleted, an existing network instance is destroyed. For more 361 information see [RFC7950] Section 7.8.6. 363 4. Security Considerations 365 TBD 367 5. IANA Considerations 369 This document registers a URI in the IETF XML registry [RFC3688]. 370 Following the format in RFC 3688, the following registration is 371 requested to be made. 373 URI: urn:ietf:params:xml:ns:yang:ietf-network-instance 375 Registrant Contact: The IESG. 377 XML: N/A, the requested URI is an XML namespace. 379 This document registers a YANG module in the YANG Module Names 380 registry [RFC6020]. 382 name: ietf-network-instance 383 namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance 384 prefix: ni 385 reference: RFC XXXX 387 6. Network Instance Model 389 The structure of the model defined in this document is described by 390 the YANG module below. 392 file "ietf-network-instance@2017-03-13.yang" 393 module ietf-network-instance { 395 yang-version 1.1; 397 // namespace 398 namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 400 prefix ni; 402 // import some basic types 403 import ietf-interfaces { 404 prefix if; 405 } 407 import ietf-ip { 408 prefix ip; 409 } 411 import ietf-yang-schema-mount { 412 prefix yangmnt; 413 } 415 // meta 416 organization "IETF Routing Area Working Group (rtgwg)"; 418 contact 419 "Routing Area Working Group - "; 421 description 422 "This module is used to support multiple network instances 423 within a single physical or virtual device. Network 424 instances are commonly know as VRFs (virtual routing 425 and forwarding) and VSIs (virtual switching instances)."; 427 revision "2017-03-13" { 428 description 429 "Initial revision."; 430 reference "RFC TBD"; 431 } 433 // extension statements 435 feature bind-network-instance-name { 436 description 437 "Network Instance to which an interface instance is bound"; 438 } 440 // identity statements 442 identity network-instance-type { 443 description 444 "Base identity from which identities describing 445 network instance types are derived."; 446 } 448 identity ipv4-interface-protocol-type { 449 description 450 "Base identity for derivation of IPv4 interface 451 protocols"; 452 } 454 identity ipv6-interface-protocol-type { 455 description 456 "Base identity for derivation of IPv6 interface 457 protocols"; 458 } 460 // typedef statements 462 // grouping statements 463 grouping interface-ip-common { 464 description 465 "interface-specific configuration for IP interfaces, IPv4 and 466 IPv6"; 468 } 470 grouping ipv4-interface-protocols { 471 container ipv4-interface-protocols { 472 list ipv4-interface-protocol { 473 key "type"; 474 leaf type { 475 type identityref { 476 base ipv4-interface-protocol-type; 477 } 478 mandatory true; 479 description 480 "ARP, ICMP, VRRP, DHCP Client, etc."; 481 } 482 description 483 "List of IPv4 protocols configured 484 on an interface"; 485 } 486 description 487 "Container for list of IPv4 protocols configured 488 on an interface"; 489 } 490 description 491 "Grouping for IPv4 protocols configured on an interface"; 492 } 494 grouping ipv6-interface-protocols { 495 description 496 "Grouping for IPv6 protocols configured on 497 an interface."; 498 container ipv6-interface-protocols { 499 description 500 "Container for list of IPv6 protocols configured 501 on an interface."; 502 list ipv6-interface-protocol { 503 key "type"; 504 description 505 "List of IPv6 protocols configured 506 on an interface"; 507 leaf type { 508 type identityref { 509 base ipv6-interface-protocol-type; 510 } 511 mandatory true; 512 description 513 "ND, ICMPv6, VRRP, DHCPv6 Client, etc."; 514 } 515 } 516 } 517 } 519 grouping network-instance-policy { 520 description 521 "Network instance policies such as route 522 distinguisher, route targets, VPLS ID and neighbor, 523 Ethernet ID, etc. "; 524 reference 525 "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) 526 RFC 6074 - Provisioning, Auto-Discovery, and Signaling 527 in Layer 2 Virtual Private Networks (L2VPNs) 528 RFC 7432 - BGP MPLS-Based Ethernet VPN"; 529 container network-instance-policy { 530 description 531 "Network Instance Policy -- details TBD, 532 perhaps based on BESS model"; 533 } 534 } 536 // top level device definition statements 537 container network-instances { 538 description "Network instances each of which have 539 an independent IP/IPv6 addressing space 540 and protocol instantiations. For layer 3, 541 this consistent with the routing-instance 542 definition in ietf-routing"; 543 reference 544 "RFC 8022 - A YANG Data Model for Routing Management"; 545 list network-instance { 546 key name; 547 description "List of network-instances"; 548 leaf name { 549 type string; 550 description "device scoped 551 identifier for the network 552 instance"; 553 } 554 leaf type { 555 type identityref { 556 base network-instance-type; 557 } 558 description 559 "The network instance type -- details TBD 560 Likely types include core, L3-VRF, VPLS, 561 L2-cross-connect, L2-VSI, etc."; 562 } 563 leaf enabled { 564 type boolean; 565 default "true"; 566 description 567 "Flag indicating whether or not the network 568 instance is enabled."; 569 } 570 leaf description { 571 type string; 572 description 573 "Description of the network instance 574 and its intended purpose"; 575 } 577 uses network-instance-policy; 579 yangmnt:mount-point root { 580 description 581 "Root for models supported per 582 network instance. This will 583 typically not be an inline type 584 mount point."; 585 } 586 } 587 } 589 // augment statements 591 augment "/if:interfaces/if:interface" { 592 description 593 "Add a node for the identification of the logical network 594 instance (which is within the interface's identified logical 595 network element) associated with the IP information 596 configured on an interface"; 598 leaf bind-network-instance-name { 599 type string; 600 description 601 "Network Instance to which an interface is bound"; 602 } 603 } 605 augment "/if:interfaces/if:interface/ip:ipv4" { 606 description 607 "Add a node for the identification of the logical 608 network instance (which is within the interface's 609 identified physical or virtual device) associated with 610 the IP information configured on an interface"; 612 leaf bind-network-instance-name { 613 type string; 614 description 615 "Network Instance to which IPv4 interface is bound"; 617 } 618 } 620 augment "/if:interfaces/if:interface/ip:ipv6" { 621 description 622 "Add a node for the identification of the logical 623 network instance (which is within the interface's 624 identified physical or virtual device) associated with 625 the IP information configured on an interface"; 627 leaf bind-network-instance-name { 628 type string; 629 description 630 "Network Instance to which IPv6 interface is bound"; 632 } 633 } 635 // rpc statements 637 // notification statements 639 } 640 642 7. References 644 7.1. Normative References 646 [I-D.ietf-netmod-schema-mount] 647 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 648 ietf-netmod-schema-mount-04 (work in progress), March 649 2017. 651 [I-D.ietf-rtgwg-lne-model] 652 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 653 "YANG Logical Network Elements", draft-ietf-rtgwg-lne- 654 model-01 (work in progress), October 2016. 656 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 657 DOI 10.17487/RFC3688, January 2004, 658 . 660 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 661 the Network Configuration Protocol (NETCONF)", RFC 6020, 662 DOI 10.17487/RFC6020, October 2010, 663 . 665 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 666 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 667 . 669 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 670 RFC 7277, DOI 10.17487/RFC7277, June 2014, 671 . 673 7.2. Informative References 675 [I-D.ietf-netmod-opstate-reqs] 676 Watsen, K. and T. Nadeau, "Terminology and Requirements 677 for Enhanced Handling of Operational State", draft-ietf- 678 netmod-opstate-reqs-04 (work in progress), January 2016. 680 [I-D.ietf-rtgwg-device-model] 681 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 682 "Network Device YANG Organizational Models", draft-ietf- 683 rtgwg-device-model-01 (work in progress), October 2016. 685 [I-D.openconfig-netmod-opstate] 686 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 687 of Operational State Data in YANG", draft-openconfig- 688 netmod-opstate-01 (work in progress), July 2015. 690 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 691 Private Network (VPN) Terminology", RFC 4026, 692 DOI 10.17487/RFC4026, March 2005, 693 . 695 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 696 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 697 . 699 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 700 RFC 7950, DOI 10.17487/RFC7950, August 2016, 701 . 703 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 704 Management", RFC 8022, DOI 10.17487/RFC8022, November 705 2016, . 707 Appendix A. Acknowledgments 709 The Routing Area Yang Architecture design team members included Acee 710 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 711 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 713 The RFC text was produced using Marshall Rose's xml2rfc tool. 715 Appendix B. Contributors 717 Contributors' Addresses 719 TBD 721 Authors' Addresses 723 Lou Berger 724 LabN Consulting, L.L.C. 726 Email: lberger@labn.net 728 Christan Hopps 729 Deutsche Telekom 731 Email: chopps@chopps.org 733 Acee Lindem 734 Cisco Systems 735 301 Midenhall Way 736 Cary, NC 27513 737 USA 739 Email: acee@cisco.com 741 Dean Bogdanovic 743 Email: ivandean@gmail.com