idnits 2.17.1 draft-ietf-rtgwg-ni-model-05.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 416 has weird spacing: '...address yang:...' -- The document date (December 4, 2017) is 2328 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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-08 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-07 == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-02 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-09 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-04 -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 2 errors (**), 0 flaws (~~), 8 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: June 7, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 December 4, 2017 14 YANG Network Instances 15 draft-ietf-rtgwg-ni-model-05 17 Abstract 19 This document defines a network instance module. This module can be 20 used to manage the virtual resource partitioning that may be present 21 on a network device. Examples of common industry terms for virtual 22 resource partitioning are Virtual Routing and Forwarding (VRF) 23 instances 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 https://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 June 7, 2018. 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 (https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Status of Work and Open Issues . . . . . . . . . . . . . 3 62 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6 65 3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7 66 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8 67 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9 68 3.3. Network Instance Management . . . . . . . . . . . . . . . 11 69 3.4. Network Instance Instantiation . . . . . . . . . . . . . 13 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 15 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 75 7.2. Informative References . . . . . . . . . . . . . . . . . 22 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 77 Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23 78 B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23 79 B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 82 1. Introduction 84 This document defines the second of two new modules that are defined 85 to support the configuration and operation of network-devices that 86 allow for the partitioning of resources from both, or either, 87 management and networking perspectives. Both leverage the YANG 88 functionality enabled by YANG Schema Mount 89 [I-D.ietf-netmod-schema-mount]. 91 The first form of resource partitioning provides a logical 92 partitioning of a network device where each partition is separately 93 managed as essentially an independent network element which is 94 'hosted' by the base network device. These hosted network elements 95 are referred to as logical network elements, or LNEs, and are 96 supported by the logical-network-element module defined in 98 [I-D.ietf-rtgwg-lne-model]. That module is used to identify LNEs and 99 associate resources from the network-device with each LNE. LNEs 100 themselves are represented in YANG as independent network devices; 101 each accessed independently. Examples of vendor terminology for an 102 LNE include logical system or logical router, and virtual switch, 103 chassis, or fabric. 105 The second form, which is defined in this document, provides support 106 for what is commonly referred to as Virtual Routing and Forwarding 107 (VRF) instances as well as Virtual Switch Instances (VSI), see 108 [RFC4026] and [RFC4664]. In this form of resource partitioning, 109 multiple control plane and forwarding/bridging instances are provided 110 by and managed via a single (physical or logical) network device. 111 This form of resource partitioning is referred to as a Network 112 Instance and is supported by the network-instance module defined 113 below. Configuration and operation of each network-instance is 114 always via the network device and the network-instance module. 116 One notable difference between the LNE model and the NI model is that 117 the NI model provides a framework for VRF and VSI management. This 118 document envisions the separate definition of VRF and VSI, i.e., L3 119 and L2 VPN, technology specific models. An example of such can be 120 found in the emerging L3VPN model defined in 121 [I-D.ietf-bess-l3vpn-yang] and the examples discussed below. 123 1.1. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 Readers are expected to be familiar with terms and concepts of YANG 130 [RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount]. 132 This document uses the graphical representation of data models 133 defined in [I-D.ietf-netmod-yang-tree-diagrams]. 135 1.2. Status of Work and Open Issues 137 The top open issues are: 139 1. Schema mount currently doesn't allow parent-reference filtering 140 on the instance of the mount point, but rather just the schema. 141 This means it is not possible to filter based on actual data, 142 e.g., bind-network-instance-name="green". In the schema mount 143 definition, the text and examples should be updated to cover this 144 case. 146 2. Overview 148 In this document, we consider network devices that support protocols 149 and functions defined within the IETF Routing Area, e.g, routers, 150 firewalls, and hosts. Such devices may be physical or virtual, e.g., 151 a classic router with custom hardware or one residing within a 152 server-based virtual machine implementing a virtual network function 153 (VNF). Each device may sub-divide their resources into logical 154 network elements (LNEs) each of which provides a managed logical 155 device. Examples of vendor terminology for an LNE include logical 156 system or logical router, and virtual switch, chassis, or fabric. 157 Each LNE may also support virtual routing and forwarding (VRF) and 158 virtual switching instance (VSI) functions, which are referred to 159 below as a network instances (NIs). This breakdown is represented in 160 Figure 1. 162 ,''''''''''''''''''''''''''''''''''''''''''''''`. 163 | Network Device (Physical or Virtual) | 164 | ..................... ..................... | 165 | : Logical Network : : Logical Network : | 166 | : Element : : Element : | 167 | :+-----+-----+-----+: :+-----+-----+-----+: | 168 | :| Net | Net | Net |: :| Net | Net | Net |: | 169 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 170 | :+-----+-----+-----+: :+-----+-----+-----+: | 171 | : | | | | | | : : | | | | | | : | 172 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 173 | | | | | | | | | | | | | | 174 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 175 | | | | | | | | | | | | 176 Interfaces Interfaces 178 Figure 1: Module Element Relationships 180 A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the 181 model for NIs is covered in this document in Section 3. 183 The current interface management model [RFC7223] is impacted by the 184 definition of LNEs and NIs. This document and 185 [I-D.ietf-rtgwg-lne-model] define augmentations to the interface 186 module to support LNEs and NIs. 188 The network instance model supports the configuration of VRFs and 189 VSIs. Each instance is supported by information that relates to the 190 device, for example the route target used when advertising VRF routes 191 via the mechanisms defined in [RFC4364], and information that relates 192 to the internal operation of the NI, for example for routing 193 protocols [RFC8022] and OSPF [I-D.ietf-ospf-yang]. This document 194 defines the network-instance module that provides a basis for the 195 management of both types of information. 197 NI information that relates to the device, including the assignment 198 of interfaces to NIs, is defined as part of this document. The 199 defined module also provides a placeholder for the definition of NI- 200 technology specific information both at the device level and for NI 201 internal operation. Information related to NI internal operation is 202 supported via schema mount [I-D.ietf-netmod-schema-mount] and 203 mounting appropriate modules under the mount point. Well known mount 204 points are defined for L3VPN, L2VPN, and L2+L3VPN NI types. 206 3. Network Instances 208 The network instance container is used to represent virtual routing 209 and forwarding instances (VRFs) and virtual switching instances 210 (VSIs). VRFs and VSIs are commonly used to isolate routing and 211 switching domains, for example to create virtual private networks, 212 each with their own active protocols and routing/switching policies. 213 The model supports both core/provider and virtual instances. Core/ 214 provider instance information is accessible at the top level of the 215 server, while virtual instance information is accessible under the 216 root schema mount points. 218 The NI model can be represented using the tree format defined in 219 [I-D.ietf-netmod-yang-tree-diagrams] as: 221 module: ietf-network-instance 222 +--rw network-instances 223 +--rw network-instance* [name] 224 +--rw name string 225 +--rw enabled? boolean 226 +--rw description? string 227 +--rw (ni-type)? 228 +--rw (root-type) 229 +--:(vrf-root) 230 | +--mp vrf-root 231 +--:(vsi-root) 232 | +--mp vsi-root 233 +--:(vv-root) 234 +--mp vv-root 235 augment /if:interfaces/if:interface: 236 +--rw bind-ni-name? -> /network-instances/network-instance/name 237 augment /if:interfaces/if:interface/ip:ipv4: 238 +--rw bind-ni-name? -> /network-instances/network-instance/name 239 augment /if:interfaces/if:interface/ip:ipv6: 240 +--rw bind-ni-name? -> /network-instances/network-instance/name 242 notifications: 243 +---n bind-ni-name-failed 244 +--ro name -> /if:interfaces/interface/name 245 +--ro interface 246 | +--ro bind-ni-name? 247 | -> /if:interfaces/interface/ni:bind-ni-name 248 +--ro ipv4 249 | +--ro bind-ni-name? 250 | -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name 251 +--ro ipv6 252 | +--ro bind-ni-name? 253 | -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name 254 +--ro error-info? string 256 A network instance is identified by a 'name' string. This string is 257 used both as an index within the network-instance module and to 258 associate resources with a network instance as shown above in the 259 interface augmentation. The ni-type and root-type choice statements 260 are used to support different types of L2 and L3 VPN technologies. 261 The bind-ni-name-failed notification is used in certain failure 262 cases. 264 3.1. NI Types and Mount Points 266 The network-instance module is structured to facilitate the 267 definition of information models for specific types of VRFs and VSIs 268 using augmentations. For example, the information needed to support 269 VPLS, VxLAN and EVPN based L2VPNs are likely to be quite different. 270 Example models under development that could be restructured to take 271 advantage on NIs include, for L3VPNs [I-D.ietf-bess-l3vpn-yang] and 272 for L2VPNs [I-D.ietf-bess-l2vpn-yang]. 274 Documents defining new YANG models for the support of specific types 275 of network instances should augment the network instance module. The 276 basic structure that should be used for such augmentations include a 277 case statement, with containers for configuration and state data and 278 finally, when needed, a type specific mount point. Generally ni 279 types, are expected to not need to define type specific mount points, 280 but rather reuse one of the well known mount point, as defined in the 281 next section. The following is an example type specific 282 augmentation: 284 augment "/ni:network-instances/ni:network-instance/ni:ni-type" { 285 case l3vpn { 286 container l3vpn { 287 ... 288 } 289 container l3vpn-state { 290 ... 291 } 292 } 293 } 295 3.1.1. Well Known Mount Points 297 YANG Schema Mount, [I-D.ietf-netmod-schema-mount], identifies mount 298 points by name within a module. This definition allows for the 299 definition of mount points whose schema can be shared across ni- 300 types. As discussed above, ni-types largely differ in the 301 configuration information needed in the core/top level instance to 302 support the NI, rather than in the information represented within an 303 NI. This allows the use of shared mount points across certain NI 304 types. 306 The expectation is that there are actually very few different schema 307 that need to be defined to support NIs on an implementation. In 308 particular, it is expected that the following three forms of NI 309 schema are needed, and each can be defined with a well known mount 310 point that can be reused by future modules defining ni-types. 312 The three well known mount points are: 314 vrf-root 315 vrf-root is intended for use with L3VPN type ni-types. 317 vsi-root 318 vsi-root is intended for use with L2VPN type ni-types. 320 vv-root 321 vv-root is intended for use with ni-types that simultaneously 322 support L2VPN bridging and L3VPN routing capabilities. 324 Future model definitions should use the above mount points whenever 325 possible. When a well known mount point isn't appropriate, a model 326 may define a type specific mount point via augmentation. 328 3.1.2. NI Type Example 330 The following is an example of an L3VPN VRF using a hypothetical 331 augmentation to the networking instance schema defined in 332 [I-D.ietf-bess-l3vpn-yang]. More detailed examples can be found in 333 Appendix B. 335 module: ietf-network-instance 336 +--rw network-instances 337 +--rw network-instance* [name] 338 +--rw name string 339 +--rw enabled? boolean 340 +--rw description? string 341 +--rw (ni-type)? 342 | +--:(l3vpn) 343 | +--rw l3vpn:l3vpn 344 | | ... // config data 345 | +--ro l3vpn:l3vpn-state 346 | | ... // state data 347 +--rw (root-type) 348 +--:(vrf-root) 349 +--mp vrf-root 350 +--ro rt:routing-state/ 351 | +--ro router-id? yang:dotted-quad 352 | +--ro control-plane-protocols 353 | +--ro control-plane-protocol* [type name] 354 | +--ro ospf:ospf/ 355 | +--ro instance* [af] 356 +--rw rt:routing/ 357 | +--rw router-id? yang:dotted-quad 358 | +--rw control-plane-protocols 359 | +--rw control-plane-protocol* [type name] 360 | +--rw ospf:ospf/ 361 | +--rw instance* [af] 362 | +--rw areas 363 | +--rw area* [area-id] 364 | +--rw interfaces 365 | +--rw interface* [name] 366 | +--rw name if:interface-ref 367 | +--rw cost? uint16 368 +--ro if:interfaces@ 369 | ... 370 +--ro if:interfaces-state@ 371 | ... 373 This shows YANG Routing Management [RFC8022] and YANG OSPF 374 [I-D.ietf-ospf-yang] as mounted modules. The mounted modules can 375 reference interface information via a parent-reference to the 376 containers defined in [RFC7223]. 378 3.2. NIs and Interfaces 380 Interfaces are a crucial part of any network device's configuration 381 and operational state. They generally include a combination of raw 382 physical interfaces, link-layer interfaces, addressing configuration, 383 and logical interfaces that may not be tied to any physical 384 interface. Several system services, and layer 2 and layer 3 385 protocols may also associate configuration or operational state data 386 with different types of interfaces (these relationships are not shown 387 for simplicity). The interface management model is defined by 388 [RFC7223]. 390 As shown below, the network-instance module augments the existing 391 interface management model by adding a name which is used on 392 interface or sub-interface types to identify an associated network 393 instance. Similarly, this name is also added for IPv4 and IPv6 394 types, as defined in [RFC7277]. 396 The following is an example of envisioned usage. The interfaces 397 container includes a number of commonly used components as examples: 399 module: ietf-interfaces 400 +--rw interfaces 401 | +--rw interface* [name] 402 | +--rw name string 403 | +--rw ip:ipv4! 404 | | +--rw ip:enabled? boolean 405 | | +--rw ip:forwarding? boolean 406 | | +--rw ip:mtu? uint16 407 | | +--rw ip:address* [ip] 408 | | | +--rw ip:ip inet:ipv4-address-no-zone 409 | | | +--rw (ip:subnet) 410 | | | +--:(ip:prefix-length) 411 | | | | +--rw ip:prefix-length? uint8 412 | | | +--:(ip:netmask) 413 | | | +--rw ip:netmask? yang:dotted-quad 414 | | +--rw ip:neighbor* [ip] 415 | | | +--rw ip:ip inet:ipv4-address-no-zone 416 | | | +--rw ip:link-layer-address yang:phys-address 417 | | +--rw ni:bind-network-instance-name? string 418 | +--rw ni:bind-network-instance-name? string 420 The [RFC7223] defined interface model is structured to include all 421 interfaces in a flat list, without regard to virtual instances (e.g., 422 VRFs) supported on the device. The bind-network-instance-name leaf 423 provides the association between an interface and its associated NI 424 (e.g., VRF or VSI). Note that as currently defined, to assign an 425 interface to both an LNE and NI, the interface would first be 426 assigned to the LNE using the mechanisms defined in 427 [I-D.ietf-rtgwg-lne-model] and then within that LNE's interface 428 module, the LNE's representation of that interface would be assigned 429 to an NI. 431 3.3. Network Instance Management 433 Modules that may be used to represent network instance information 434 will be available under the ni-type specific 'root' mount point. The 435 use-schema mechanism defined as part of the Schema Mount module 436 [I-D.ietf-netmod-schema-mount] MUST be used with the module defined 437 in this document to identify accessible modules. A future version of 438 this document could relax this requirement. Mounted modules in the 439 non-inline case SHOULD be defined with access, via the appropriate 440 schema mount parent-references [I-D.ietf-netmod-schema-mount], to 441 device resources such as interfaces. An implementation MAY choose to 442 restrict parent referenced information to information related to a 443 specific instance, e.g., only allowing references to interfaces that 444 have a "bind-network-instance-name" which is identical to the 445 instance's "name". 447 All modules that represent control-plane and data-plane information 448 may be present at the 'root' mount point, and be accessible via paths 449 modified per [I-D.ietf-netmod-schema-mount]. The list of available 450 modules is expected to be implementation dependent, as is the method 451 used by an implementation to support NIs. 453 For example, the following could be used to define the data 454 organization of the example NI shown in Section 3.1.2: 456 "ietf-yang-schema-mount:schema-mounts": { 457 "mount-point": [ 458 { 459 "module": "ietf-network-instance", 460 "label": "vrf-root", 461 "use-schema": [ 462 { 463 "name": "ni-schema", 464 "parent-reference": [ 465 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 466 ] 467 } 468 ] 469 } 470 ], 471 "schema": [ 472 { 473 "name": "ni-schema", 474 "module": [ 475 { 476 "name": "ietf-routing", 477 "revision": "2016-11-04", 478 "namespace": 479 "urn:ietf:params:xml:ns:yang:ietf-routing", 480 "conformance-type": "implement" 481 }, 482 { 483 "name": "ietf-ospf", 484 "revision": "2017-03-12", 485 "namespace": 486 "urn:ietf:params:xml:ns:yang:ietf-ospf", 487 "conformance-type": "implement" 488 } 489 ] 490 } 491 ] 492 } 494 Module data identified under "schema" will be instantiated under the 495 mount point identified under "mount-point". These modules will be 496 able to reference information for nodes belonging to top-level 497 modules that are identified under "parent-reference". Parent 498 referenced information is available to clients via their top level 499 paths only, and not under the associated mount point. 501 To allow a client to understand the previously mentioned instance 502 restrictions on parent referenced information, an implementation MAY 503 represent such restrictions in the "parent-reference" leaf-list. For 504 example: 506 "namespace": [ 507 { 508 "prefix": "if", 509 "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" 510 }, 511 { 512 "prefix": "ni", 513 "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" 514 } 515 ], 516 "mount-point": [ 517 { 518 "parent-reference": [ 519 "/if:interfaces/if:interface 520 [ni:bind-network-instance-name = current()/../ni:name]", 521 "/if:interfaces-state/if:interface 522 [if:name = /if:interfaces/if:interface 523 [ni:bind-ni-name = current()/../ni:name]/if:name]", 524 "/if:interfaces/if:interface/ip:ipv4 525 [ni:bind-network-instance-name = current()/../ni:name]", 526 "/if:interfaces-state/if:interface/ip:ipv4 527 [if:name = /if:interfaces/if:interface/ip:ipv4 528 [ni:bind-ni-name = current()/../ni:name]/if:name]", 529 "/if:interfaces/if:interface/ip:ipv6 530 [ni:bind-network-instance-name = current()/../ni:name]", 531 "/if:interfaces-state/if:interface/ip:ipv6 532 [if:name = /if:interfaces/if:interface/ip:ipv4 533 [ni:bind-ni-name = current()/../ni:name]/if:name]", 534 ] 535 } 536 ], 538 3.4. Network Instance Instantiation 540 Network instances may be controlled by clients using existing list 541 operations. When a list entry is created, a new instance is 542 instantiated. The models mounted under an NI root are expected to be 543 dependent on the server implementation. When a list entry is 544 deleted, an existing network instance is destroyed. For more 545 information, see [RFC7950] Section 7.8.6. 547 Once instantiated, host network device resources can be associated 548 with the new NI. As previously mentioned, this document augments 549 ietf-interfaces with the bind-ni-name leaf to support such 550 associations for interfaces. When a bind-ni-name is set to a valid 551 NI name, an implementation MUST take whatever steps are internally 552 necessary to assign the interface to the NI or provide an error 553 message (defined below) with an indication of why the assignment 554 failed. It is possible for the assignment to fail while processing 555 the set operation, or after asynchronous processing. Error 556 notification in the latter case is supported via a notification. 558 4. Security Considerations 560 There are two different sets of security considerations to consider 561 in the context of this document. One set is security related to 562 information contained within mounted modules. The security 563 considerations for mounted modules are not substantively changed 564 based on the information being accessible within the context of an 565 NI. For example, when considering the modules defined in [RFC8022], 566 the security considerations identified in that document are equally 567 applicable, whether those modules are accessed at a server's root or 568 under an NI instance's root node. 570 The second area for consideration is information contained in the NI 571 module itself. NI information represents network configuration and 572 route distribution policy information. As such, the security of this 573 information is important, but it is fundamentally no different than 574 any other interface or routing configuration information that has 575 already been covered in [RFC7223] and [RFC8022]. 577 The vulnerable "config true" parameters and subtrees are the 578 following: 580 /network-instances/network-instance: This list specifies the network 581 instances and the related control plane protocols configured on a 582 device. 584 /if:interfaces/if:interface/*/bind-network-instance-name: This leaf 585 indicates the NI instance to which an interface is assigned. 587 Unauthorized access to any of these lists can adversely affect the 588 routing subsystem of both the local device and the network. This may 589 lead to network malfunctions, delivery of packets to inappropriate 590 destinations and other problems. 592 5. IANA Considerations 594 This document registers a URI in the IETF XML registry [RFC3688]. 595 Following the format in RFC 3688, the following registration is 596 requested to be made. 598 URI: urn:ietf:params:xml:ns:yang:ietf-network-instance 600 Registrant Contact: The IESG. 602 XML: N/A, the requested URI is an XML namespace. 604 This document registers a YANG module in the YANG Module Names 605 registry [RFC6020]. 607 name: ietf-network-instance 608 namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance 609 prefix: ni 610 reference: RFC XXXX 612 6. Network Instance Model 614 The structure of the model defined in this document is described by 615 the YANG module below. 617 file "ietf-network-instance@2017-12-04.yang" 618 module ietf-network-instance { 619 yang-version 1.1; 620 namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 621 prefix ni; 623 // import some basic types 625 import ietf-interfaces { 626 prefix if; 627 reference "RFC 7223: A YANG Data Model for Interface 628 Management"; 629 } 630 import ietf-ip { 631 prefix ip; 632 reference "RFC 7277: A YANG Data Model for IP Management"; 633 } 634 import ietf-yang-schema-mount { 635 prefix yangmnt; 636 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 637 // RFC Ed.: Please replace this draft name with the 638 // corresponding RFC number 639 } 641 organization 642 "IETF Routing Area (rtgwg) Working Group"; 643 contact 644 "WG Web: 645 WG List: 646 Author: Lou Berger 647 648 Author: Christan Hopps 649 650 Author: Acee Lindem 651 652 Author: Dean Bogdanovic 653 "; 654 description 655 "This module is used to support multiple network instances 656 within a single physical or virtual device. Network 657 instances are commonly known as VRFs (virtual routing 658 and forwarding) and VSIs (virtual switching instances). 660 Copyright (c) 2017 IETF Trust and the persons 661 identified as authors of the code. All rights reserved. 663 Redistribution and use in source and binary forms, with or 664 without modification, is permitted pursuant to, and subject 665 to the license terms contained in, the Simplified BSD License 666 set forth in Section 4.c of the IETF Trust's Legal Provisions 667 Relating to IETF Documents 668 (http://trustee.ietf.org/license-info). 670 This version of this YANG module is part of RFC XXXX; see 671 the RFC itself for full legal notices."; 673 // RFC Ed.: replace XXXX with actual RFC number and remove 674 // this note 675 // RFC Ed.: please update TBD 677 revision 2017-12-04 { 678 description 679 "Initial revision."; 680 reference "RFC TBD"; 681 } 683 // top level device definition statements 685 container network-instances { 686 description 687 "Network instances each of which consists of a 688 VRFs (virtual routing and forwarding) and/or 689 VSIs (virtual switching instances)."; 690 reference "RFC 8022 - A YANG Data Model for Routing 691 Management"; 692 list network-instance { 693 key "name"; 694 description 695 "List of network-instances."; 696 leaf name { 697 type string; 698 mandatory true; 699 description 700 "device scoped identifier for the network 701 instance."; 702 } 703 leaf enabled { 704 type boolean; 705 default "true"; 706 description 707 "Flag indicating whether or not the network 708 instance is enabled."; 709 } 710 leaf description { 711 type string; 712 description 713 "Description of the network instance 714 and its intended purpose."; 715 } 716 choice ni-type { 717 description 718 "This node serves as an anchor point for different types 719 of network instances. Each 'case' is expected to 720 differ in terms of the information needed in the 721 parent/core to support the NI, and may differ in their 722 mounted schema definition. When the mounted schema is 723 not expected to be the same for a specific type of NI 724 a mount point should be defined."; 725 } 726 choice root-type { 727 mandatory true; 728 description 729 "Well known mount points."; 730 container vrf-root { 731 description 732 "Container for mount point."; 733 yangmnt:mount-point "vrf-root" { 734 description 735 "Root for L3VPN type models. This will typically 736 not be an inline type mount point."; 737 } 738 } 739 container vsi-root { 740 description 741 "Container for mount point."; 743 yangmnt:mount-point "vsi-root" { 744 description 745 "Root for L2VPN type models. This will typically 746 not be an inline type mount point."; 747 } 748 } 749 container vv-root { 750 description 751 "Container for mount point."; 752 yangmnt:mount-point "vv-root" { 753 description 754 "Root models that support both L2VPN type bridging 755 and L3VPN type routing. This will typically 756 not be an inline type mount point."; 757 } 758 } 759 } 760 } 761 } 763 // augment statements 765 augment "/if:interfaces/if:interface" { 766 description 767 "Add a node for the identification of the network 768 instance associated with the information configured 769 on a interface. 771 Note that a standard error will be returned if the 772 identified leafref isn't present. If an interfaces cannot 773 be assigned for any other reason, the operation SHALL fail 774 with an error-tag of 'operation-failed' and an 775 error-app-tag of 'ni-assignment-failed'. A meaningful 776 error-info that indicates the source of the assignment 777 failure SHOULD also be provided."; 778 leaf bind-ni-name { 779 type leafref { 780 path "/network-instances/network-instance/name"; 781 } 782 description 783 "Network Instance to which an interface is bound."; 784 } 785 } 786 augment "/if:interfaces/if:interface/ip:ipv4" { 787 description 788 "Add a node for the identification of the network 789 instance associated with the information configured 790 on an IPv4 interface. 792 Note that a standard error will be returned if the 793 identified leafref isn't present. If an interfaces cannot 794 be assigned for any other reason, the operation SHALL fail 795 with an error-tag of 'operation-failed' and an 796 error-app-tag of 'ni-assignment-failed'. A meaningful 797 error-info that indicates the source of the assignment 798 failure SHOULD also be provided."; 799 leaf bind-ni-name { 800 type leafref { 801 path "/network-instances/network-instance/name"; 802 } 803 description 804 "Network Instance to which IPv4 interface is bound."; 805 } 806 } 807 augment "/if:interfaces/if:interface/ip:ipv6" { 808 description 809 "Add a node for the identification of the network 810 instance associated with the information configured 811 on an IPv6 interface. 813 Note that a standard error will be returned if the 814 identified leafref isn't present. If an interfaces cannot 815 be assigned for any other reason, the operation SHALL fail 816 with an error-tag of 'operation-failed' and an 817 error-app-tag of 'ni-assignment-failed'. A meaningful 818 error-info that indicates the source of the assignment 819 failure SHOULD also be provided."; 820 leaf bind-ni-name { 821 type leafref { 822 path "/network-instances/network-instance/name"; 823 } 824 description 825 "Network Instance to which IPv6 interface is bound."; 826 } 827 } 829 // notification statements 831 notification bind-ni-name-failed { 832 description 833 "Indicates an error in the association of an interface to an 834 NI. Only generated after success is initially returned when 835 bind-ni-name is set. 837 Note: some errors may need to be reported for multiple 838 associations, e.g., a single error may need to be reported 839 for an IPv4 and an IPv6 bind-ni-name. 841 At least one container with a bind-ni-name leaf MUST be 842 included in this notification."; 843 leaf name { 844 type leafref { 845 path "/if:interfaces/if:interface/if:name"; 846 } 847 mandatory true; 848 description 849 "Contains the interface name associated with the 850 failure."; 851 } 852 container interface { 853 description 854 "Generic interface type."; 855 leaf bind-ni-name { 856 type leafref { 857 path "/if:interfaces/if:interface/ni:bind-ni-name"; 858 } 859 description 860 "Contains the bind-ni-name associated with the 861 failure."; 862 } 863 } 864 container ipv4 { 865 description 866 "IPv4 interface type."; 867 leaf bind-ni-name { 868 type leafref { 869 path "/if:interfaces/if:interface" 870 + "/ip:ipv4/ni:bind-ni-name"; 871 } 872 description 873 "Contains the bind-ni-name associated with the 874 failure."; 875 } 876 } 877 container ipv6 { 878 description 879 "IPv6 interface type."; 880 leaf bind-ni-name { 881 type leafref { 882 path "/if:interfaces/if:interface" 883 + "/ip:ipv6/ni:bind-ni-name"; 884 } 885 description 886 "Contains the bind-ni-name associated with the 887 failure."; 888 } 890 } 891 leaf error-info { 892 type string; 893 description 894 "Optionally, indicates the source of the assignment 895 failure."; 896 } 897 } 898 } 899 901 7. References 903 7.1. Normative References 905 [I-D.ietf-netmod-schema-mount] 906 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 907 ietf-netmod-schema-mount-08 (work in progress), October 908 2017. 910 [I-D.ietf-netmod-yang-tree-diagrams] 911 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 912 ietf-netmod-yang-tree-diagrams-02 (work in progress), 913 October 2017. 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, 917 DOI 10.17487/RFC2119, March 1997, 918 . 920 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 921 DOI 10.17487/RFC3688, January 2004, 922 . 924 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 925 the Network Configuration Protocol (NETCONF)", RFC 6020, 926 DOI 10.17487/RFC6020, October 2010, 927 . 929 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 930 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 931 . 933 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 934 RFC 7277, DOI 10.17487/RFC7277, June 2014, 935 . 937 7.2. Informative References 939 [I-D.ietf-bess-l2vpn-yang] 940 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 941 and K. Tiruveedhula, "YANG Data Model for MPLS-based 942 L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress), 943 October 2017. 945 [I-D.ietf-bess-l3vpn-yang] 946 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 947 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 948 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-02 (work 949 in progress), October 2017. 951 [I-D.ietf-ospf-yang] 952 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 953 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 954 yang-09 (work in progress), October 2017. 956 [I-D.ietf-rtgwg-device-model] 957 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 958 "Network Device YANG Logical Organization", draft-ietf- 959 rtgwg-device-model-02 (work in progress), March 2017. 961 [I-D.ietf-rtgwg-lne-model] 962 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 963 Liu, "YANG Logical Network Elements", draft-ietf-rtgwg- 964 lne-model-04 (work in progress), September 2017. 966 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 967 Private Network (VPN) Terminology", RFC 4026, 968 DOI 10.17487/RFC4026, March 2005, 969 . 971 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 972 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 973 2006, . 975 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 976 2 Virtual Private Networks (L2VPNs)", RFC 4664, 977 DOI 10.17487/RFC4664, September 2006, 978 . 980 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 981 RFC 7950, DOI 10.17487/RFC7950, August 2016, 982 . 984 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 985 Management", RFC 8022, DOI 10.17487/RFC8022, November 986 2016, . 988 Appendix A. Acknowledgments 990 The Routing Area Yang Architecture design team members included Acee 991 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 992 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 993 comments were also received by Martin Bjorklund and John Scudder. 995 This document was motivated by, and derived from, 996 [I-D.ietf-rtgwg-device-model]. 998 The RFC text was produced using Marshall Rose's xml2rfc tool. 1000 Appendix B. Example NI usage 1002 The following subsections provide example uses of NIs. 1004 B.1. Configuration Data 1006 The following shows an example where two customer specific network 1007 instances are configured: 1009 { 1010 "ietf-network-instance:network-instances": { 1011 "network-instance": [ 1012 { 1013 "name": "vrf-red", 1014 "vrf-root": { 1015 "ietf-routing:routing": { 1016 "router-id": "192.0.2.1", 1017 "control-plane-protocols": { 1018 "control-plane-protocol": [ 1019 { 1020 "type": "ietf-routing:ospf", 1021 "name": "1", 1022 "ietf-ospf:ospf": { 1023 "instance": [ 1024 { 1025 "af": "ipv4", 1026 "areas": { 1027 "area": [ 1028 { 1029 "area-id": "203.0.113.1", 1030 "interfaces": { 1031 "interface": [ 1032 { 1033 "name": "eth1", 1034 "cost": 10 1035 } 1036 ] 1037 } 1038 } 1039 ] 1040 } 1041 } 1042 ] 1043 } 1044 } 1045 ] 1046 } 1047 } 1048 } 1049 }, 1050 { 1051 "name": "vrf-blue", 1052 "vrf-root": { 1053 "ietf-routing:routing": { 1054 "router-id": "192.0.2.2", 1055 "control-plane-protocols": { 1056 "control-plane-protocol": [ 1057 { 1058 "type": "ietf-routing:ospf", 1059 "name": "1", 1060 "ietf-ospf:ospf": { 1061 "instance": [ 1062 { 1063 "af": "ipv4", 1064 "areas": { 1065 "area": [ 1066 { 1067 "area-id": "203.0.113.1", 1068 "interfaces": { 1069 "interface": [ 1070 { 1071 "name": "eth2", 1072 "cost": 10 1073 } 1074 ] 1075 } 1076 } 1077 ] 1078 } 1079 } 1081 ] 1082 } 1083 } 1084 ] 1085 } 1086 } 1087 } 1088 } 1089 ] 1090 }, 1092 "ietf-interfaces:interfaces": { 1093 "interfaces": { 1094 "interface": [ 1095 { 1096 "name": "eth0", 1097 "ip:ipv4": { 1098 "address": [ 1099 { 1100 "ip": "192.0.2.10", 1101 "prefix-length": 24, 1102 } 1103 ] 1104 } 1105 }, 1106 { 1107 "name": "eth1", 1108 "ip:ipv4": { 1109 "address": [ 1110 { 1111 "ip": "192.0.2.11", 1112 "prefix-length": 24, 1113 } 1114 ] 1115 }, 1116 "ni:bind-network-instance-name": "vrf-red" 1117 }, 1118 { 1119 "name": "eth2", 1120 "ip:ipv4": { 1121 "address": [ 1122 { 1123 "ip": "192.0.2.11", 1124 "prefix-length": 24, 1125 } 1126 ] 1127 }, 1128 "ni:bind-network-instance-name": "vrf-blue" 1130 } 1131 ] 1132 } 1133 }, 1135 "ietf-system:system": { 1136 "authentication": { 1137 "user": [ 1138 { 1139 "name": "john", 1140 "password": "$0$password" 1141 } 1142 ] 1143 } 1144 } 1145 } 1147 B.2. State Data 1149 The following shows state data for the example above. 1151 { 1152 "ietf-network-instance:network-instances": { 1153 "network-instance": [ 1154 { 1155 "name": "vrf-red", 1156 "vrf-root": { 1157 "ietf-routing:routing-state": { 1158 "router-id": "192.0.2.1", 1159 "control-plane-protocols": { 1160 "control-plane-protocol": [ 1161 { 1162 "type": "ietf-routing:ospf", 1163 "name": "1", 1164 "ietf-ospf:ospf": { 1165 "instance": [ 1166 { 1167 "af": "ipv4", 1168 "areas": { 1169 "area": [ 1170 { 1171 "area-id": "203.0.113.1", 1172 "interfaces": { 1173 "interface": [ 1174 { 1175 "name": "eth1", 1176 "cost": 10 1177 } 1179 ] 1180 } 1181 } 1182 ] 1183 } 1184 } 1185 ] 1186 } 1187 } 1188 ] 1189 } 1190 } 1191 } 1192 }, 1193 { 1194 "name": "vrf-blue", 1195 "vrf-root": { 1196 "ietf-routing:routing-state": { 1197 "router-id": "192.0.2.2", 1198 "control-plane-protocols": { 1199 "control-plane-protocol": [ 1200 { 1201 "type": "ietf-routing:ospf", 1202 "name": "1", 1203 "ietf-ospf:ospf": { 1204 "instance": [ 1205 { 1206 "af": "ipv4", 1207 "areas": { 1208 "area": [ 1209 { 1210 "area-id": "203.0.113.1", 1211 "interfaces": { 1212 "interface": [ 1213 { 1214 "name": "eth2", 1215 "cost": 10 1216 } 1217 ] 1218 } 1219 } 1220 ] 1221 } 1222 } 1223 ] 1224 } 1225 } 1226 ] 1228 } 1229 } 1230 } 1231 } 1232 ] 1233 }, 1235 "ietf-interfaces:interfaces-state": { 1236 "interfaces": { 1237 "interface": [ 1238 { 1239 "name": "eth0", 1240 "type": "iana-if-type:ethernetCsmacd", 1241 "oper-status": "up", 1242 "phys-address": "00:01:02:A1:B1:C0", 1243 "statistics": { 1244 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1245 }, 1246 "ip:ipv4": { 1247 "address": [ 1248 { 1249 "ip": "192.0.2.10", 1250 "prefix-length": 24, 1251 } 1252 ] 1253 } 1254 }, 1255 { 1256 "name": "eth1", 1257 "type": "iana-if-type:ethernetCsmacd", 1258 "oper-status": "up", 1259 "phys-address": "00:01:02:A1:B1:C1", 1260 "statistics": { 1261 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1262 }, 1263 "ip:ipv4": { 1264 "address": [ 1265 { 1266 "ip": "192.0.2.11", 1267 "prefix-length": 24, 1268 } 1269 ] 1270 } 1271 }, 1272 { 1273 "name": "eth2", 1274 "type": "iana-if-type:ethernetCsmacd", 1275 "oper-status": "up", 1276 "phys-address": "00:01:02:A1:B1:C2", 1277 "statistics": { 1278 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1279 }, 1280 "ip:ipv4": { 1281 "address": [ 1282 { 1283 "ip": "192.0.2.11", 1284 "prefix-length": 24, 1285 } 1286 ] 1287 } 1288 } 1289 ] 1290 } 1291 }, 1293 "ietf-system:system-state": { 1294 "platform": { 1295 "os-name": "NetworkOS" 1296 } 1297 } 1299 "ietf-yang-library:modules-state": { 1300 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1301 "module": [ 1302 { 1303 "name": "iana-if-type", 1304 "revision": "2014-05-08", 1305 "namespace": 1306 "urn:ietf:params:xml:ns:yang:iana-if-type", 1307 "conformance-type": "import" 1308 }, 1309 { 1310 "name": "ietf-inet-types", 1311 "revision": "2013-07-15", 1312 "namespace": 1313 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1314 "conformance-type": "import" 1315 }, 1316 { 1317 "name": "ietf-interfaces", 1318 "revision": "2014-05-08", 1319 "feature": [ 1320 "arbitrary-names", 1321 "pre-provisioning" 1322 ], 1323 "namespace": 1325 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1326 "conformance-type": "implement" 1327 }, 1328 { 1329 "name": "ietf-ip", 1330 "revision": "2014-06-16", 1331 "namespace": 1332 "urn:ietf:params:xml:ns:yang:ietf-ip", 1333 "conformance-type": "implement" 1334 }, 1335 { 1336 "name": "ietf-network-instance", 1337 "revision": "2017-03-13", 1338 "feature": [ 1339 "bind-network-instance-name" 1340 ], 1341 "namespace": 1342 "urn:ietf:params:xml:ns:yang:ietf-network-instance", 1343 "conformance-type": "implement" 1344 }, 1345 { 1346 "name": "ietf-ospf", 1347 "revision": "2017-03-12", 1348 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 1349 "conformance-type": "implement" 1350 }, 1351 { 1352 "name": "ietf-routing", 1353 "revision": "2016-11-04", 1354 "namespace": 1355 "urn:ietf:params:xml:ns:yang:ietf-routing", 1356 "conformance-type": "implement" 1357 }, 1358 { 1359 "name": "ietf-system", 1360 "revision": "2014-08-06", 1361 "namespace": 1362 "urn:ietf:params:xml:ns:yang:ietf-system", 1363 "conformance-type": "implement" 1364 }, 1365 { 1366 "name": "ietf-yang-library", 1367 "revision": "2016-06-21", 1368 "namespace": 1369 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1370 "conformance-type": "implement" 1371 }, 1372 { 1373 "name": "ietf-yang-schema-mount", 1374 "revision": "2017-05-16", 1375 "namespace": 1376 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1377 "conformance-type": "implement" 1378 }, 1379 { 1380 "name": "ietf-yang-types", 1381 "revision": "2013-07-15", 1382 "namespace": 1383 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1384 "conformance-type": "import" 1385 } 1386 ] 1387 }, 1389 "ietf-yang-schema-mount:schema-mounts": { 1390 "mount-point": [ 1391 { 1392 "module": "ietf-network-instance", 1393 "label": "vrf-root", 1394 "use-schema": [ 1395 { 1396 "name": "ni-schema", 1397 "parent-reference": [ 1398 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 1399 ] 1400 } 1401 ] 1402 } 1403 ], 1404 "schema": [ 1405 { 1406 "name": "ni-schema", 1407 "module": [ 1408 { 1409 "name": "ietf-routing", 1410 "revision": "2016-11-04", 1411 "namespace": 1412 "urn:ietf:params:xml:ns:yang:ietf-routing", 1413 "conformance-type": "implement" 1414 }, 1415 { 1416 "name": "ietf-ospf", 1417 "revision": "2017-03-12", 1418 "namespace": 1419 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1420 "conformance-type": "implement" 1422 } 1423 ] 1424 } 1425 ] 1426 } 1427 } 1429 Authors' Addresses 1431 Lou Berger 1432 LabN Consulting, L.L.C. 1434 Email: lberger@labn.net 1436 Christan Hopps 1437 Deutsche Telekom 1439 Email: chopps@chopps.org 1441 Acee Lindem 1442 Cisco Systems 1443 301 Midenhall Way 1444 Cary, NC 27513 1445 USA 1447 Email: acee@cisco.com 1449 Dean Bogdanovic 1451 Email: ivandean@gmail.com 1453 Xufeng Liu 1454 Jabil 1456 Email: Xufeng_Liu@jabil.com