idnits 2.17.1 draft-ietf-rtgwg-ni-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2736 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-02 == 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-24 == Outdated reference: A later version (-02) exists of draft-ietf-rtgwg-device-model-00 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: May 1, 2017 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 9 October 28, 2016 11 YANG Network Instances 12 draft-ietf-rtgwg-ni-model-01 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 May 1, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 7.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 73 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 This document defines the second of two new modules that are defined 79 to support the configuration and operation of network-devices that 80 allow for the partitioning of resources from both, or either, 81 management and networking perspectives. Both make use of the YANG 82 functionality enabled by YANG Schema Mount 83 [I-D.ietf-netmod-schema-mount]. 85 Two forms of resource partitioning are supported: 87 The first form, which is defined in [I-D.ietf-rtgwg-lne-model], 88 provides a logical partitioning of a network device where each 89 partition is separately managed as essentially an independent network 90 element which is 'hosted' by the base network device. These hosted 91 network elements are referred to as logical network elements, or 92 LNEs, and are supported by the logical-network-element module defined 93 in [I-D.ietf-rtgwg-lne-model]. The module is used to identify LNEs 94 and associate resources from the network-device with each LNE. LNEs 95 themselves are represented in YANG as independent network devices; 96 each accessed independently. Optionally, and when supported by the 97 implementation, they may also be accessed from the host system. 98 Examples of vendor terminology for an LNE include logical system or 99 logical router, and virtual switch, chassis, or fabric. 101 The second form, which is defined in this document, provides support 102 what is commonly referred to as Virtual Routing and Forwarding (VRF) 103 instances as well as Virtual Switch Instances (VSI), see [RFC4026]. 104 In this form of resource partitioning multiple control plane and 105 forwarding/bridging instances are provided by and managed via a 106 single (physical or logical) network device. This form of resource 107 partitioning is referred to as Network Instances and are supported by 108 the network-instance module defined below. Configuration and 109 operation of each network-instance is always via the network device 110 and the network-instance module. 112 This document was motivated by, and derived from, 113 [I-D.ietf-rtgwg-device-model]. 115 1.1. Status of Work and Open Issues 117 The top open issues are: 119 1. This document will need to match the evolution and 120 standardization of [I-D.openconfig-netmod-opstate] or 121 [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 123 2. Overview 125 In this document, we consider network devices that support protocols 126 and functions defined within the IETF Routing Area, e.g, routers, 127 firewalls and hosts. Such devices may be physical or virtual, e.g., 128 a classic router with custom hardware or one residing within a 129 server-based virtual machine implementing a virtual network function 130 (VNF). Each device may sub-divide their resources into logical 131 network elements (LNEs) each of which provides a managed logical 132 device. Examples of vendor terminology for an LNE include logical 133 system or logical router, and virtual switch, chassis, or fabric. 134 Each LNE may also support virtual routing and forwarding (VRF) and 135 virtual switching instance (VSI) functions, which are referred to 136 below as a network instances (NIs). This breakdown is represented in 137 Figure 1. 139 ,''''''''''''''''''''''''''''''''''''''''''''''`. 140 | Network Device (Physical or Virtual) | 141 | ..................... ..................... | 142 | : Logical Network : : Logical Network : | 143 | : Element : : Element : | 144 | :+-----+-----+-----+: :+-----+-----+-----+: | 145 | :| Net | Net | Net |: :| Net | Net | Net |: | 146 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 147 | :+-----+-----+-----+: :+-----+-----+-----+: | 148 | : | | | | | | : : | | | | | | : | 149 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 150 | | | | | | | | | | | | | | 151 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 152 | | | | | | | | | | | | 153 Interfaces Interfaces 155 Figure 1: Module Element Relationships 157 A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the 158 model for network instances is covered in Section 3. For more 159 information on how these models may be used within an overall device 160 model structure, see [I-D.ietf-rtgwg-device-model]. 162 The interface management model [RFC7223] is an existing model that is 163 impacted by the definition of LNEs and network instances. This 164 document and [I-D.ietf-rtgwg-lne-model] define augmentations to the 165 interface module to support LNEs and NIs. Similar elements, although 166 perhaps only for LNEs, may also need to be included as part of the 167 definition of the future hardware and QoS modules. 169 Interfaces are a crucial part of any network device's configuration 170 and operational state. They generally include a combination of raw 171 physical interfaces, link-layer interfaces, addressing configuration, 172 and logical interfaces that may not be tied to any physical 173 interface. Several system services, and layer 2 and layer 3 174 protocols may also associate configuration or operational state data 175 with different types of interfaces (these relationships are not shown 176 for simplicity). The interface management model is defined by 177 [RFC7223]. 179 The logical-network-element and network-instance modules augment the 180 existing interface management model in two ways: The first, by the 181 logical-network-element module, adds an identifier which is used on 182 physical interface types to identify an associated LNE. The second, 183 by the network-instance module, adds a name which is used on 184 interface or sub-interface types to identify an associated network 185 instance. Similarly, this name is also added for IPv4 and IPv6 186 types, as defined in [RFC7277]. 188 The interface related augmentations are as follows: 190 module: ietf-logical-network-element 191 augment /if:interfaces/if:interface: 192 +--rw bind-lne-name? string 194 module: ietf-network-instance 195 augment /if:interfaces/if:interface: 196 +--rw bind-network-instance-name? string 197 augment /if:interfaces/if:interface/ip:ipv4: 198 +--rw bind-network-instance-name? string 199 augment /if:interfaces/if:interface/ip:ipv6: 200 +--rw bind-network-instance-name? string 202 The following is an example of envisioned combined usage. The 203 interfaces container includes a number of commonly used components as 204 examples: 206 +--rw if:interfaces 207 | +--rw interface* [name] 208 | +--rw name string 209 | +--rw bind-lne-name? string 210 | +--rw ethernet 211 | | +--rw ni:bind-network-instance-name? string 212 | | +--rw aggregates 213 | | +--rw rstp 214 | | +--rw lldp 215 | | +--rw ptp 216 | +--rw vlans 217 | +--rw tunnels 218 | +--rw ipv4 219 | | +--rw ni:bind-network-instance-name? string 220 | | +--rw arp 221 | | +--rw icmp 222 | | +--rw vrrp 223 | | +--rw dhcp-client 224 | +--rw ipv6 225 | +--rw ni:bind-network-instance-name? string 226 | +--rw vrrp 227 | +--rw icmpv6 228 | +--rw nd 229 | +--rw dhcpv6-client 231 The [RFC7223] defined interface model is structured to include all 232 interfaces in a flat list, without regard to logical or virtual 233 instances (e.g., VRFs) supported on the device. The bind-lne-name 234 and bind-network-instance-name leaves provide the association between 235 an interface and its associated LNE and NI (e.g., VRF or VSI). 237 3. Network Instances 239 The network instance container is used to represent virtual routing 240 and forwarding instances (VRFs) and virtual switching instances 241 (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate 242 routing and switching domains, for example to create virtual private 243 networks, each with their own active protocols and routing/switching 244 policies. The model represents both core/provider and virtual 245 instances. Network instances reuse and build on 246 [I-D.ietf-netmod-routing-cfg] and are shown below: 248 module: ietf-network-instance 249 +--rw network-instances 250 +--rw network-instance* [name] 251 +--rw name string 252 +--rw type? identityref 253 +--rw enabled? boolean 254 +--rw description? string 255 +--rw network-instance-policy 256 | ... 257 +--rw root? yang-schema-mount 258 | ... 259 augment /if:interfaces/if:interface: 260 +--rw bind-network-instance-name? string 261 augment /if:interfaces/if:interface/ip:ipv4: 262 +--rw bind-network-instance-name? string 263 augment /if:interfaces/if:interface/ip:ipv6: 264 +--rw bind-network-instance-name? string 266 A network instance is identified by a `name` string. This string is 267 used both as an index within the network-instance module and to 268 associate resources with a network instance as shown above in the 269 interface augmentation. Type is used to indicate the type NI, such 270 as L3-VRF, VPLS, L2-VSI, etc. Network instance policy and root are 271 discussed in greater detail below. 273 3.1. Network Instance Policy 275 Network instance policies are used to control how NI information is 276 represented at the device level, VRF routing policies, and VRF/VSI 277 identifiers. Examples include BGP route targets (RTs) and route 278 distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS 279 neighbors, etc. The structure is expected to be: 281 module: ietf-network-instance 282 +--rw network-instances 283 +--rw network-instance* [name] 284 +--rw network-instance-policy 285 (TBD) 287 3.2. Network Instance Management 289 Modules that may be used to represent network instance specific 290 information will be available under `root`. As with LNEs, actual 291 module availability is expected to be implementation dependent. The 292 yang library module [RFC7895] is expected to be the primary method 293 used to identify supported modules. Resource related control and 294 assignment is expected to be managed at the network-device level, not 295 the network instance level, based on the `bind-network-instance-name` 296 augmentation mentioned above. 298 As an example, consider the case where a network instance with a 299 `name` of "green" is defined on a network device. In this case the 300 following structure might be made available: 302 +--rw yanglib:modules-state [RFC7895] 303 +--rw if:interfaces [RFC7223] 304 | +--rw bind-network-instance-name="green" string 305 +--rw network-instances 306 +--rw network-instance* [name] 307 +--rw name="green" string 308 +--rw type? identityref 309 +--rw enabled=true boolean 310 +--rw description="The Green VRF" string 311 +--rw network-instance-policy 312 | ... (RT=1000:1, RD=1.2.3.4) 313 +--rw root? yang-schema-mount 314 +--rw yanglib:modules-state [RFC7895] 315 +--rw if:intefaces [RFC7223] 316 +--rw mm:network-services 317 +--rw nn:oam-protocols 318 +--rw oo:routing 319 +--rw pp:mpls 321 All modules that represent control-plane and data-plane information 322 may be present at the `root`, and be accessible via paths modified 323 per [I-D.ietf-netmod-schema-mount]. The list of available modules is 324 expected to be implementation dependent. As is the method used by an 325 implementation to support NIs. 327 3.3. Network Instance Instantiation 329 Network instances may be controlled by clients using existing list 330 operations. When list entries are created, a new instance is 331 instantiated. The models mounted under a NI root is expected to be 332 dependent on the server implementation. When a list entry is 333 deleted, an existing network instance is destroyed. For more 334 information see [RFC7950] Section 7.8.6. 336 4. Security Considerations 338 TBD 340 5. IANA Considerations 342 This document registers a URI in the IETF XML registry [RFC3688]. 343 Following the format in RFC 3688, the following registration is 344 requested to be made. 346 URI: urn:ietf:params:xml:ns:yang:ietf-network-instance 348 Registrant Contact: The IESG. 350 XML: N/A, the requested URI is an XML namespace. 352 This document registers a YANG module in the YANG Module Names 353 registry [RFC6020]. 355 name: ietf-network-instance 356 namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance 357 prefix: ni 358 reference: RFC XXXX 360 6. Network Instance Model 362 The structure of the model defined in this document is described by 363 the YANG module below. 365 file "ietf-network-instance@2016-10-27.yang" 366 module ietf-network-instance { 368 yang-version 1.1; 370 // namespace 371 namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 373 prefix ni; 374 // import some basic types 375 import ietf-interfaces { 376 prefix if; 377 } 379 import ietf-ip { 380 prefix ip; 381 } 383 import ietf-yang-schema-mount { 384 prefix yangmnt; 385 } 387 // meta 388 organization "IETF Routing Area Working Group (rtgwg)"; 390 contact 391 "Routing Area Working Group - "; 393 description 394 "This module is used to support multiple network instances 395 within a single physical or virtual device. Network 396 instances are commonly know as VRFs (virtual routing 397 and forwarding) and VSIs (virtual switching instances)."; 399 revision "2016-10-27" { 400 description 401 "Initial revision."; 402 reference "RFC TBD"; 403 } 405 // extension statements 407 feature bind-network-instance-name { 408 description 409 "Network Instance to which an interface instance is bound"; 410 } 412 // identity statements 414 identity network-instance-type { 415 description 416 "Base identity from which identities describing 417 network instance types are derived."; 418 } 420 identity ipv4-interface-protocol-type { 421 description 422 "Base identity for derivation of IPv4 interface 423 protocols"; 424 } 426 identity ipv6-interface-protocol-type { 427 description 428 "Base identity for derivation of IPv6 interface 429 protocols"; 430 } 432 // typedef statements 434 // grouping statements 436 grouping interface-ip-common { 437 description 438 "interface-specific configuration for IP interfaces, IPv4 and 439 IPv6"; 441 } 443 grouping ipv4-interface-protocols { 444 container ipv4-interface-protocols { 445 list ipv4-interface-protocol { 446 key "type"; 447 leaf type { 448 type identityref { 449 base ipv4-interface-protocol-type; 450 } 451 mandatory true; 452 description 453 "ARP, ICMP, VRRP, DHCP Client, etc."; 454 } 455 description 456 "List of IPv4 protocols configured 457 on an interface"; 458 } 459 description 460 "Container for list of IPv4 protocols configured 461 on an interface"; 462 } 463 description 464 "Grouping for IPv4 protocols configured on an interface"; 465 } 467 grouping ipv6-interface-protocols { 468 description 469 "Grouping for IPv6 protocols configured on 470 an interface."; 471 container ipv6-interface-protocols { 472 description 473 "Container for list of IPv6 protocols configured 474 on an interface."; 475 list ipv6-interface-protocol { 476 key "type"; 477 description 478 "List of IPv6 protocols configured 479 on an interface"; 480 leaf type { 481 type identityref { 482 base ipv6-interface-protocol-type; 483 } 484 mandatory true; 485 description 486 "ND, ICMPv6, VRRP, DHCPv6 Client, etc."; 487 } 488 } 489 } 490 } 492 grouping network-instance-policy { 493 description 494 "Network instance policies such as route 495 distinguisher, route targets, VPLS ID and neighbor, 496 Ethernet ID, etc. "; 497 reference 498 "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) 499 RFC 6074 - Provisioning, Auto-Discovery, and Signaling 500 in Layer 2 Virtual Private Networks (L2VPNs) 501 RFC 7432 - BGP MPLS-Based Ethernet VPN"; 502 container network-instance-policy { 503 description 504 "Network Instance Policy -- details TBD, 505 perhaps based on BESS model"; 506 } 507 } 509 // top level device definition statements 510 container network-instances { 511 description "Network instances each of which have 512 an independent IP/IPv6 addressing space 513 and protocol instantiations. For layer 3, 514 this consistent with the routing-instance 515 definition in ietf-routing"; 516 reference "draft-ietf-netmod-routing-cfg"; 517 list network-instance { 518 key name; 519 description "List of network-instances"; 520 leaf name { 521 type string; 522 description "device scoped 523 identifier for the network 524 instance"; 525 } 526 leaf type { 527 type identityref { 528 base network-instance-type; 529 } 530 description 531 "The network instance type -- details TBD 532 Likely types include core, L3-VRF, VPLS, 533 L2-cross-connect, L2-VSI, etc."; 534 } 535 leaf enabled { 536 type boolean; 537 default "true"; 538 description 539 "Flag indicating whether or not the network 540 instance is enabled."; 541 } 542 leaf description { 543 type string; 544 description 545 "Description of the network instance 546 and its intended purpose"; 547 } 549 uses network-instance-policy; 551 anydata root { 552 yangmnt:mount-point root; 553 description "Root for models supported per 554 network instance"; 555 } 556 } 557 } 559 // augment statements 561 augment "/if:interfaces/if:interface" { 562 description 563 "Add a node for the identification of the logical network 564 instance (which is within the interface's identified logical 565 network element) associated with the IP information 566 configured on an interface"; 568 leaf bind-network-instance-name { 569 type string; 570 description 571 "Network Instance to which an interface is bound"; 572 } 573 } 575 augment "/if:interfaces/if:interface/ip:ipv4" { 576 description 577 "Add a node for the identification of the logical 578 network instance (which is within the interface's 579 identified physical or virtual device) associated with 580 the IP information configured on an interface"; 582 leaf bind-network-instance-name { 583 type string; 584 description 585 "Network Instance to which IPv4 interface is bound"; 587 } 588 } 590 augment "/if:interfaces/if:interface/ip:ipv6" { 591 description 592 "Add a node for the identification of the logical 593 network instance (which is within the interface's 594 identified physical or virtual device) associated with 595 the IP information configured on an interface"; 597 leaf bind-network-instance-name { 598 type string; 599 description 600 "Network Instance to which IPv6 interface is bound"; 602 } 603 } 605 // rpc statements 607 // notification statements 609 } 610 612 7. References 614 7.1. Normative References 616 [I-D.ietf-netmod-schema-mount] 617 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 618 ietf-netmod-schema-mount-02 (work in progress), July 2016. 620 [I-D.ietf-rtgwg-lne-model] 621 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 622 "Logical Network Element Model", draft-ietf-rtgwg-lne- 623 model-00 (work in progress), June 2016. 625 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 626 DOI 10.17487/RFC3688, January 2004, 627 . 629 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 630 the Network Configuration Protocol (NETCONF)", RFC 6020, 631 DOI 10.17487/RFC6020, October 2010, 632 . 634 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 635 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 636 . 638 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 639 RFC 7277, DOI 10.17487/RFC7277, June 2014, 640 . 642 7.2. Informative References 644 [I-D.ietf-netmod-opstate-reqs] 645 Watsen, K. and T. Nadeau, "Terminology and Requirements 646 for Enhanced Handling of Operational State", draft-ietf- 647 netmod-opstate-reqs-04 (work in progress), January 2016. 649 [I-D.ietf-netmod-routing-cfg] 650 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 651 Management", draft-ietf-netmod-routing-cfg-24 (work in 652 progress), October 2016. 654 [I-D.ietf-rtgwg-device-model] 655 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 656 "Network Device YANG Organizational Models", draft-ietf- 657 rtgwg-device-model-00 (work in progress), August 2016. 659 [I-D.openconfig-netmod-opstate] 660 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 661 of Operational State Data in YANG", draft-openconfig- 662 netmod-opstate-01 (work in progress), July 2015. 664 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 665 Private Network (VPN) Terminology", RFC 4026, 666 DOI 10.17487/RFC4026, March 2005, 667 . 669 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 670 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 671 . 673 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 674 RFC 7950, DOI 10.17487/RFC7950, August 2016, 675 . 677 Appendix A. Acknowledgments 679 The Routing Area Yang Architecture design team members included Acee 680 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 681 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 683 The RFC text was produced using Marshall Rose's xml2rfc tool. 685 Appendix B. Contributors 687 Contributors' Addresses 689 TBD 691 Authors' Addresses 693 Lou Berger 694 LabN Consulting, L.L.C. 696 Email: lberger@labn.net 698 Christan Hopps 699 Deutsche Telekom 701 Email: chopps@chopps.org 703 Acee Lindem 704 Cisco Systems 705 301 Midenhall Way 706 Cary, NC 27513 707 USA 709 Email: acee@cisco.com 711 Dean Bogdanovic 713 Email: ivandean@gmail.com