idnits 2.17.1 draft-ietf-rtgwg-ni-model-00.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 (June 23, 2016) is 2862 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-01 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-00 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-21 == Outdated reference: A later version (-05) exists of draft-rtgyangdt-rtgwg-device-model-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: December 25, 2016 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 9 June 23, 2016 11 Network Instance Model 12 draft-ietf-rtgwg-ni-model-00 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 December 25, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 8 68 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 7.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 73 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 emerging 82 YANG functionality supported by YANG Schema Mount 83 [I-D.ietf-netmod-schema-mount]. This document is expected to use 84 whatever Schema Mount solution is agreed upon by the Netmod Working 85 Group. 87 Two forms of resource partitioning are supported: 89 The first form, which is defined in [LNE-MODEL], provides a logical 90 partitioning of a network device where each partition is separately 91 managed as essentially an independent network element which is 92 'hosted' by the base network device. These hosted network elements 93 are referred to as logical network elements, or LNEs, and are 94 supported by the logical-network-element module defined in 95 [LNE-MODEL]. The module is used to identify LNEs and associate 96 resources from the network-device with each LNE. LNEs themselves are 97 represented in YANG as independent network devices; each accessed 98 independently. Optionally, and when supported by the implementation, 99 they may also be accessed from the host system. Examples of vendor 100 terminology for an LNE include logical system or logical router, and 101 virtual switch, chassis, or fabric. 103 The second form, which is defined in this document, provides support 104 what is commonly referred to as Virtual Routing and Forwarding (VRF) 105 instances as well as Virtual Switch Instances (VSI), see [RFC4026]. 106 In this form of resource partitioning multiple control plane and 107 forwarding/bridging instances are provided by and managed via a 108 single (physical or logical) network device. This form of resource 109 partitioning is referred to as Network Instances and are supported by 110 the network-instance module defined below. Configuration and 111 operation of each network-instance is always via the network device 112 and the network-instance module. 114 This document was motivated by, and derived from, [RTG-DEVICE-MODEL]. 116 1.1. Status of Work and Open Issues 118 The top open issues are: 120 1. This document will need to match the evolution and 121 standardization of [I-D.openconfig-netmod-opstate] or 122 [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 124 2. Overview 126 In this document, we consider network devices that support protocols 127 and functions defined within the IETF Routing Area, e.g, routers, 128 firewalls and hosts. Such devices may be physical or virtual, e.g., 129 a classic router with custom hardware or one residing within a 130 server-based virtual machine implementing a virtual network function 131 (VNF). Each device may sub-divide their resources into logical 132 network elements (LNEs) each of which provides a managed logical 133 device. Examples of vendor terminology for an LNE include logical 134 system or logical router, and virtual switch, chassis, or fabric. 135 Each LNE may also support virtual routing and forwarding (VRF) and 136 virtual switching instance (VSI) functions, which are referred to 137 below as a network instances (NIs). This breakdown is represented in 138 Figure 1. 140 ,''''''''''''''''''''''''''''''''''''''''''''''`. 141 | Network Device (Physical or Virtual) | 142 | ..................... ..................... | 143 | : Logical Network : : Logical Network : | 144 | : Element : : Element : | 145 | :+-----+-----+-----+: :+-----+-----+-----+: | 146 | :| Net | Net | Net |: :| Net | Net | Net |: | 147 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 148 | :+-----+-----+-----+: :+-----+-----+-----+: | 149 | : | | | | | | : : | | | | | | : | 150 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 151 | | | | | | | | | | | | | | 152 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 153 | | | | | | | | | | | | 154 Interfaces Interfaces 156 Figure 1: Module Element Relationships 158 A model for LNEs is described in [LNE-MODEL] and the model for 159 network instances is covered in Section 3. For more information on 160 how these models may be used within an overall device model 161 structure, see [RTG-DEVICE-MODEL]. 163 The interface management model [RFC7223] is an existing model that is 164 impacted by the definition of LNEs and network instances. This 165 document and [LNE-MODEL] define augmentations to the interface module 166 to support LNEs and NIs. Similar elements, although perhaps only for 167 LNEs, may also need to be included as part of the definition of the 168 future hardware and QoS modules. 170 Interfaces are a crucial part of any network device's configuration 171 and operational state. They generally include a combination of raw 172 physical interfaces, link-layer interfaces, addressing configuration, 173 and logical interfaces that may not be tied to any physical 174 interface. Several system services, and layer 2 and layer 3 175 protocols may also associate configuration or operational state data 176 with different types of interfaces (these relationships are not shown 177 for simplicity). The interface management model is defined by 178 [RFC7223]. 180 The logical-network-element and network-instance modules augment the 181 existing interface management model in two ways: The first, by the 182 logical-network-element module, adds an identifier which is used on 183 physical interface types to identify an associated LNE. The second, 184 by the network-instance module, adds a name which is used on 185 interface or sub-interface types to identify an associated network 186 instance. Similarly, this name is also added for IPv4 and IPv6 187 types, as defined in [RFC7277]. 189 The interface related augmentations are as follows: 191 module: ietf-logical-network-element 192 augment /if:interfaces/if:interface: 193 +--rw bind-lne-name? string 195 module: ietf-network-instance 196 augment /if:interfaces/if:interface: 197 +--rw bind-network-instance-name? string 198 augment /if:interfaces/if:interface/ip:ipv4: 199 +--rw bind-network-instance-name? string 200 augment /if:interfaces/if:interface/ip:ipv6: 201 +--rw bind-network-instance-name? string 203 The following is an example of envisioned combined usage. The 204 interfaces container includes a number of commonly used components as 205 examples: 207 +--rw if:interfaces 208 | +--rw interface* [name] 209 | +--rw name string 210 | +--rw bind-lne-name? string 211 | +--rw ethernet 212 | | +--rw ni:bind-network-instance-name? string 213 | | +--rw aggregates 214 | | +--rw rstp 215 | | +--rw lldp 216 | | +--rw ptp 217 | +--rw vlans 218 | +--rw tunnels 219 | +--rw ipv4 220 | | +--rw ni:bind-network-instance-name? string 221 | | +--rw arp 222 | | +--rw icmp 223 | | +--rw vrrp 224 | | +--rw dhcp-client 225 | +--rw ipv6 226 | +--rw ni:bind-network-instance-name? string 227 | +--rw vrrp 228 | +--rw icmpv6 229 | +--rw nd 230 | +--rw dhcpv6-client 232 The [RFC7223] defined interface model is structured to include all 233 interfaces in a flat list, without regard to logical or virtual 234 instances (e.g., VRFs) supported on the device. The bind-lne-name 235 and bind-network-instance-name leaves provide the association between 236 an interface and its associated LNE and NI (e.g., VRF or VSI). 238 3. Network Instances 240 The network instance container is used to represent virtual routing 241 and forwarding instances (VRFs) and virtual switching instances 242 (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate 243 routing and switching domains, for example to create virtual private 244 networks, each with their own active protocols and routing/switching 245 policies. The model represents both core/provider and virtual 246 instances. Network instances reuse and build on 247 [I-D.ietf-netmod-routing-cfg] and are shown below: 249 module: ietf-network-instance 250 +--rw network-instances 251 +--rw network-instance* [name] 252 +--rw name string 253 +--rw type? identityref 254 +--rw enabled? boolean 255 +--rw description? string 256 +--rw network-instance-policy 257 | ... 258 +--rw root? schema-mount 259 | ... 260 augment /if:interfaces/if:interface: 261 +--rw bind-network-instance-name? string 262 augment /if:interfaces/if:interface/ip:ipv4: 263 +--rw bind-network-instance-name? string 264 augment /if:interfaces/if:interface/ip:ipv6: 265 +--rw bind-network-instance-name? string 267 A network instance is identified by a `name` string. This string is 268 used both as an index within the network-instance module and to 269 associate resources with a network instance as shown above in the 270 interface augmentation. Type is used to indicate the type NI, such 271 as L3-VRF, VPLS, L2-VSI, etc. Network instance policy and root are 272 discussed in greater detail below. 274 3.1. Network Instance Policy 276 Network instance policies are used to control how NI information is 277 represented at the device level, VRF routing policies, and VRF/VSI 278 identifiers. Examples include BGP route targets (RTs) and route 279 distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS 280 neighbors, etc. The structure is expected to be: 282 module: ietf-network-instance 283 +--rw network-instances 284 +--rw network-instance* [name] 285 +--rw network-instance-policy 286 (TBD) 288 3.2. Network Instance Management 290 Modules that may be used to represent network instance specific 291 information will be available under `root`. As with LNEs, actual 292 module availability is expected to be implementation dependent. The 293 yang library module [I-D.ietf-netconf-yang-library] is expected to be 294 the primary method used to identify supported modules. Resource 295 related control and assignment is expected to be managed at the 296 network-device level, not the network instance level, based on the 297 `bind-network-instance-name` augmentation mentioned above. 299 As an example, consider the case where a network instance with a 300 `name` of "green" is defined on a network device. In this case the 301 following structure might be made available: 303 +--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] 304 +--rw if:interfaces [RFC7223] 305 | +--rw bind-network-instance-name="green" string 306 +--rw network-instances 307 +--rw network-instance* [name] 308 +--rw name="green" string 309 +--rw type? identityref 310 +--rw enabled=true boolean 311 +--rw description="The Green VRF" string 312 +--rw network-instance-policy 313 | ... (RT=1000:1, RD=1.2.3.4) 314 +--rw root? schema-mount 315 +--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] 316 +--rw if:intefaces [RFC7223] 317 +--rw mm:network-services 318 +--rw nn:oam-protocols 319 +--rw oo:routing 320 +--rw pp:mpls 322 All modules that represent control-plane and data-plane information 323 may be present at the `root`, and be accessible via paths modified 324 per [I-D.ietf-netmod-schema-mount]. The list of available modules is 325 expected to be implementation dependent. As is the method used by an 326 implementation to support NIs. 328 3.3. Network Instance Instantiation 330 TBD -- need to resolve if instantiation is based on new list entry 331 creation per the pending Schema Mount solution definition. 333 4. Security Considerations 335 LNE portion is TBD 337 NI portion is TBD 339 5. IANA Considerations 341 This YANG model currently uses a temporary ad-hoc namespace. If it 342 is placed or redirected for the standards track, an appropriate 343 namespace URI will be registered in the "IETF XML Registry" 344 [RFC3688]. The YANG structure modules will be registered in the 345 "YANG Module Names" registry [RFC6020]. 347 6. Network Instance Model 349 The structure of the model defined in this document is described by 350 the YANG module below. 352 file "ietf-network-instance@2016-06-23.yang" 353 module ietf-network-instance { 355 yang-version "1"; 357 // namespace 358 namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 360 prefix "ni"; 362 // import some basic types 363 import ietf-interfaces { 364 prefix if; 365 } 367 import ietf-ip { 368 prefix ip; 369 } 371 // meta 372 organization "IETF Routing Area Working Group (rtgwg)"; 374 contact 375 "Routing Area Working Group - "; 377 description 378 "This module is used to support multiple network instances 379 within a single physical or virtual device. Network 380 instances are commonly know as VRFs (virtual routing 381 and forwarding) and VSIs (virtual switching instances)."; 383 revision "2016-06-23" { 384 description 385 "Initial revision."; 386 reference "RFC TBD"; 387 } 389 // extension statements 391 feature bind-network-instance-name { 392 description 393 "Network Instance to which an interface instance is bound"; 394 } 396 // identity statements 398 identity network-instance-type { 399 description 400 "Base identity from which identities describing 401 network instance types are derived."; 402 } 404 identity ipv4-interface-protocol-type { 405 description 406 "Base identity for derivation of IPv4 interface 407 protocols"; 408 } 410 identity ipv6-interface-protocol-type { 411 description 412 "Base identity for derivation of IPv6 interface 413 protocols"; 414 } 416 // typedef statements 418 // grouping statements 420 grouping interface-ip-common { 421 description 422 "interface-specific configuration for IP interfaces, IPv4 and 423 IPv6"; 425 } 427 grouping ipv4-interface-protocols { 428 container ipv4-interface-protocols { 429 list ipv4-interface-protocol { 430 key "type"; 431 leaf type { 432 type identityref { 433 base ipv4-interface-protocol-type; 434 } 435 mandatory true; 436 description 437 "ARP, ICMP, VRRP, DHCP Client, etc."; 438 } 439 description 440 "List of IPv4 protocols configured 441 on an interface"; 442 } 443 description 444 "Container for list of IPv4 protocols configured 445 on an interface"; 446 } 447 description 448 "Grouping for IPv4 protocols configured on an interface"; 449 } 451 grouping ipv6-interface-protocols { 452 description 453 "Grouping for IPv6 protocols configured on 454 an interface."; 455 container ipv6-interface-protocols { 456 description 457 "Container for list of IPv6 protocols configured 458 on an interface."; 459 list ipv6-interface-protocol { 460 key "type"; 461 description 462 "List of IPv6 protocols configured 463 on an interface"; 464 leaf type { 465 type identityref { 466 base ipv6-interface-protocol-type; 467 } 468 mandatory true; 469 description 470 "ND, ICMPv6, VRRP, DHCPv6 Client, etc."; 471 } 472 } 474 } 475 } 477 grouping network-instance-policy { 478 description 479 "Network instance policies such as route 480 distinguisher, route targets, VPLS ID and neighbor, 481 Ethernet ID, etc. "; 482 reference 483 "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) 484 RFC 6074 - Provisioning, Auto-Discovery, and Signaling 485 in Layer 2 Virtual Private Networks (L2VPNs) 486 RFC 7432 - BGP MPLS-Based Ethernet VPN"; 487 container network-instance-policy { 488 description "Network Instance Policy -- details TBD"; 489 } 490 } 492 // top level device definition statements 493 container network-instances { 494 description "Network instances each of which have 495 an independent IP/IPv6 addressing space 496 and protocol instantiations. For layer 3, 497 this consistent with the routing-instance 498 definition in ietf-routing"; 499 reference "draft-ietf-netmod-routing-cfg"; 500 list network-instance { 501 key name; 502 description "List of network-instances"; 503 leaf name { 504 type string; 505 description "device scoped 506 identifier for the network 507 instance"; 508 } 509 leaf type { 510 type identityref { 511 base network-instance-type; 512 } 513 description 514 "The network instance type -- details TBD 515 Likely types include core, L3-VRF, VPLS, 516 L2-cross-connect, L2-VSI, etc."; 517 } 518 leaf enabled { 519 type boolean; 520 default "true"; 521 description 522 "Flag indicating whether or not the network 523 instance is enabled."; 524 } 525 leaf description { 526 type string; 527 description 528 "Description of the network instance 529 and its intended purpose"; 530 } 531 uses network-instance-policy; 532 leaf root { 533 type schema-mount; 534 description "Root for models supported per 535 network instance"; 536 } 537 } 538 } 540 // augment statements 542 augment "/if:interfaces/if:interface" { 543 description 544 "Add a node for the identification of the logical network 545 instance (which is within the interface's identified logical 546 network element) associated with the IP information 547 configured on an interface"; 549 leaf bind-network-instance-name { 550 type string; 551 description 552 "Network Instance to which an interface is bound"; 553 } 554 } 556 augment "/if:interfaces/if:interface/ip:ipv4" { 557 description 558 "Add a node for the identification of the logical 559 network instance (which is within the interface's 560 identified physical or virtual device) associated with 561 the IP information configured on an interface"; 563 leaf bind-network-instance-name { 564 type string; 565 description 566 "Network Instance to which IPv4 interface is bound"; 568 } 569 } 570 augment "/if:interfaces/if:interface/ip:ipv6" { 571 description 572 "Add a node for the identification of the logical 573 network instance (which is within the interface's 574 identified physical or virtual device) associated with 575 the IP information configured on an interface"; 577 leaf bind-network-instance-name { 578 type string; 579 description 580 "Network Instance to which IPv6 interface is bound"; 582 } 583 } 585 // rpc statements 587 // notification statements 589 } 590 592 7. References 594 7.1. Normative References 596 [I-D.ietf-netmod-schema-mount] 597 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 598 ietf-netmod-schema-mount-01 (work in progress), April 599 2016. 601 [LNE-MODEL] 602 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 603 "Logical Network Element Model", draft-ietf-rtgwg-lne- 604 model-00.txt (work in progress), June 2016. 606 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 607 DOI 10.17487/RFC3688, January 2004, 608 . 610 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 611 the Network Configuration Protocol (NETCONF)", RFC 6020, 612 DOI 10.17487/RFC6020, October 2010, 613 . 615 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 616 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 617 . 619 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 620 RFC 7277, DOI 10.17487/RFC7277, June 2014, 621 . 623 7.2. Informative References 625 [I-D.ietf-netconf-yang-library] 626 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 627 Library", draft-ietf-netconf-yang-library-06 (work in 628 progress), April 2016. 630 [I-D.ietf-netmod-opstate-reqs] 631 Watsen, K. and T. Nadeau, "Terminology and Requirements 632 for Enhanced Handling of Operational State", draft-ietf- 633 netmod-opstate-reqs-04 (work in progress), January 2016. 635 [I-D.ietf-netmod-routing-cfg] 636 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 637 Management", draft-ietf-netmod-routing-cfg-21 (work in 638 progress), March 2016. 640 [I-D.openconfig-netmod-opstate] 641 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 642 of Operational State Data in YANG", draft-openconfig- 643 netmod-opstate-01 (work in progress), July 2015. 645 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 646 Private Network (VPN) Terminology", RFC 4026, 647 DOI 10.17487/RFC4026, March 2005, 648 . 650 [RTG-DEVICE-MODEL] 651 Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C. 652 Hopps, "Network Device YANG Organizational Models", draft- 653 rtgyangdt-rtgwg-device-model-04.txt (work in progress), 654 May 2016. 656 Appendix A. Acknowledgments 658 The Routing Area Yang Architecture design team members included Acee 659 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 660 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 662 The RFC text was produced using Marshall Rose's xml2rfc tool. 664 Appendix B. Contributors 666 Contributors' Addresses 668 TBD 670 Authors' Addresses 672 Lou Berger 673 LabN Consulting, L.L.C. 675 Email: lberger@labn.net 677 Christan Hopps 678 Deutsche Telekom 680 Email: chopps@chopps.org 682 Acee Lindem 683 Cisco Systems 684 301 Midenhall Way 685 Cary, NC 27513 686 USA 688 Email: acee@cisco.com 690 Dean Bogdanovic 692 Email: ivandean@gmail.com