idnits 2.17.1 draft-rtgyangdt-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 (May 17, 2016) is 2894 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 ** Downref: Normative reference to an Informational RFC: RFC 4026 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-05) exists of draft-rtgyangdt-rtgwg-device-model-04 ** Downref: Normative reference to an Informational draft: draft-rtgyangdt-rtgwg-device-model (ref. 'RTG-DEVICE-MODEL') == Outdated reference: A later version (-06) exists of draft-ietf-netconf-yang-library-05 == Outdated reference: A later version (-04) exists of draft-ietf-netmod-opstate-reqs-03 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-20 Summary: 4 errors (**), 0 flaws (~~), 6 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: November 18, 2016 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 9 May 17, 2016 11 Network Instance Model 12 draft-rtgyangdt-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 November 18, 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-05-01.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 RTG YANG Design Team Collaboration 373 with OpenConfig"; 375 contact 376 "Routing Area YANG Architecture Design Team - 377 "; 379 description 380 "This module is used to support multiple network instances 381 within a single physical or virtual device. Network 382 instances are commonly know as VRFs (virtual routing 383 and forwarding) and VSIs (virtual switching instances)."; 385 revision "2016-05-01" { 386 description 387 "IETF Routing YANG Design Team Meta-Model"; 388 reference "TBD"; 389 } 391 // extension statements 393 feature bind-network-instance-name { 394 description 395 "Network Instance to which an interface instance is bound"; 396 } 398 // identity statements 400 identity network-instance-type { 401 description 402 "Base identity from which identities describing 403 network instance types are derived."; 404 } 406 identity ipv4-interface-protocol-type { 407 description 408 "Base identity for derivation of IPv4 interface 409 protocols"; 410 } 412 identity ipv6-interface-protocol-type { 413 description 414 "Base identity for derivation of IPv6 interface 415 protocols"; 416 } 418 // typedef statements 420 // grouping statements 422 grouping interface-ip-common { 423 description 424 "interface-specific configuration for IP interfaces, IPv4 and 425 IPv6"; 427 } 429 grouping ipv4-interface-protocols { 430 container ipv4-interface-protocols { 431 list ipv4-interface-protocol { 432 key "type"; 433 leaf type { 434 type identityref { 435 base ipv4-interface-protocol-type; 436 } 437 mandatory true; 438 description 439 "ARP, ICMP, VRRP, DHCP Client, etc."; 440 } 441 description 442 "List of IPv4 protocols configured 443 on an interface"; 444 } 445 description 446 "Container for list of IPv4 protocols configured 447 on an interface"; 448 } 449 description 450 "Grouping for IPv4 protocols configured on an interface"; 451 } 453 grouping ipv6-interface-protocols { 454 description 455 "Grouping for IPv6 protocols configured on 456 an interface."; 457 container ipv6-interface-protocols { 458 description 459 "Container for list of IPv6 protocols configured 460 on an interface."; 461 list ipv6-interface-protocol { 462 key "type"; 463 description 464 "List of IPv6 protocols configured 465 on an interface"; 466 leaf type { 467 type identityref { 468 base ipv6-interface-protocol-type; 469 } 470 mandatory true; 471 description 472 "ND, ICMPv6, VRRP, DHCPv6 Client, etc."; 473 } 474 } 475 } 476 } 478 grouping network-instance-policy { 479 description 480 "Network instance policies such as route 481 distinguisher, route targets, VPLS ID and neighbor, 482 Ethernet ID, etc. "; 483 reference 484 "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) 485 RFC 6074 - Provisioning, Auto-Discovery, and Signaling 486 in Layer 2 Virtual Private Networks (L2VPNs) 487 RFC 7432 - BGP MPLS-Based Ethernet VPN"; 488 container network-instance-policy { 489 description "Network Instance Policy -- details TBD"; 490 } 491 } 493 // top level device definition statements 494 container network-instances { 495 description "Network instances each of which have 496 an independent IP/IPv6 addressing space 497 and protocol instantiations. For layer 3, 498 this consistent with the routing-instance 499 definition in ietf-routing"; 500 reference "draft-ietf-netmod-routing-cfg"; 501 list network-instance { 502 key name; 503 description "List of network-instances"; 504 leaf name { 505 type string; 506 description "device scoped 507 identifier for the network 508 instance"; 509 } 510 leaf type { 511 type identityref { 512 base network-instance-type; 513 } 514 description 515 "The network instance type -- details TBD 516 Likely types include core, L3-VRF, VPLS, 517 L2-cross-connect, L2-VSI, etc."; 518 } 519 leaf enabled { 520 type boolean; 521 default "true"; 522 description 523 "Flag indicating whether or not the network 524 instance is enabled."; 525 } 526 leaf description { 527 type string; 528 description 529 "Description of the network instance 530 and its intended purpose"; 531 } 532 uses network-instance-policy; 533 leaf root { 534 type schema-mount; 535 description "Root for models supported per 536 network instance"; 537 } 538 } 539 } 541 // augment statements 543 augment "/if:interfaces/if:interface" { 544 description 545 "Add a node for the identification of the logical network 546 instance (which is within the interface's identified logical 547 network element) associated with the IP information 548 configured on an interface"; 550 leaf bind-network-instance-name { 551 type string; 552 description 553 "Network Instance to which an interface is bound"; 554 } 555 } 557 augment "/if:interfaces/if:interface/ip:ipv4" { 558 description 559 "Add a node for the identification of the logical 560 network instance (which is within the interface's 561 identified physical or virtual device) associated with 562 the IP information configured on an interface"; 564 leaf bind-network-instance-name { 565 type string; 566 description 567 "Network Instance to which IPv4 interface is bound"; 569 } 570 } 572 augment "/if:interfaces/if:interface/ip:ipv6" { 573 description 574 "Add a node for the identification of the logical 575 network instance (which is within the interface's 576 identified physical or virtual device) associated with 577 the IP information configured on an interface"; 579 leaf bind-network-instance-name { 580 type string; 581 description 582 "Network Instance to which IPv6 interface is bound"; 584 } 585 } 587 // rpc statements 589 // notification statements 591 } 592 594 7. References 596 7.1. Normative References 598 [I-D.ietf-netmod-schema-mount] 599 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 600 ietf-netmod-schema-mount-01 (work in progress), April 601 2016. 603 [LNE-MODEL] 604 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 605 "Logical Network Element Model", draft-rtgyangdt-rtgwg- 606 lne-model-00.txt (work in progress), May 2016. 608 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 609 DOI 10.17487/RFC3688, January 2004, 610 . 612 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 613 Private Network (VPN) Terminology", RFC 4026, 614 DOI 10.17487/RFC4026, March 2005, 615 . 617 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 618 the Network Configuration Protocol (NETCONF)", RFC 6020, 619 DOI 10.17487/RFC6020, October 2010, 620 . 622 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 623 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 624 . 626 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 627 RFC 7277, DOI 10.17487/RFC7277, June 2014, 628 . 630 [RTG-DEVICE-MODEL] 631 Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C. 632 Hopps, "Network Device YANG Organizational Models", draft- 633 rtgyangdt-rtgwg-device-model-04.txt (work in progress), 634 May 2016. 636 7.2. Informative References 638 [I-D.ietf-netconf-yang-library] 639 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 640 Library", draft-ietf-netconf-yang-library-05 (work in 641 progress), April 2016. 643 [I-D.ietf-netmod-opstate-reqs] 644 Watsen, K. and T. Nadeau, "Terminology and Requirements 645 for Enhanced Handling of Operational State", draft-ietf- 646 netmod-opstate-reqs-03 (work in progress), January 2016. 648 [I-D.ietf-netmod-routing-cfg] 649 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 650 Management", draft-ietf-netmod-routing-cfg-20 (work in 651 progress), October 2015. 653 [I-D.openconfig-netmod-opstate] 654 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 655 of Operational State Data in YANG", draft-openconfig- 656 netmod-opstate-01 (work in progress), July 2015. 658 Appendix A. Acknowledgments 660 The Routing Area Yang Architecture design team members included Acee 661 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 662 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 664 The RFC text was produced using Marshall Rose's xml2rfc tool. 666 Appendix B. Contributors 668 Contributors' Addresses 670 TBD 672 Authors' Addresses 674 Lou Berger 675 LabN Consulting, L.L.C. 677 Email: lberger@labn.net 679 Christan Hopps 680 Deutsche Telekom 682 Email: chopps@chopps.org 684 Acee Lindem 685 Cisco Systems 686 301 Midenhall Way 687 Cary, NC 27513 688 USA 690 Email: acee@cisco.com 692 Dean Bogdanovic 694 Email: ivandean@gmail.com