idnits 2.17.1 draft-dunbar-nvo3-nva-gap-analysis-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 : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 403: '...ng edge (NVE), the Pull Directory MUST...' RFC 2119 keyword, line 406: '... a Pull Directory server MUST maintain...' RFC 2119 keyword, line 431: '...uery level, they MUST be reported in a...' RFC 2119 keyword, line 434: '... errors, they MUST be reported in s...' RFC 2119 keyword, line 436: '... error response MAY be reported in on...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2013) is 3871 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ESADI' is mentioned on line 313, but not defined == Missing Reference: 'RFCclear' is mentioned on line 482, but not defined == Unused Reference: 'RFC826' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC6439' is defined on line 613, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NV03 working group L. Dunbar 2 Internet Draft D. Eastlake 3 Category: Informational Huawei 5 Expires: April 4 2014 September 20, 2013 7 NV03 NVA Gap Analysis 9 draft-dunbar-nvo3-nva-gap-analysis-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided 46 without warranty as described in the Simplified BSD License. 48 Abstract 50 The intent of the draft is to identify the gaps of existing 51 solutions against NVO3's NVE <-> NVA control plane requirement. 52 Through the gap analysis, the document provides a basis for 53 future works that develop solutions for NVE<->NVA control plane. 55 Table of Contents 57 1. Introduction ................................................ 3 58 2. Terminology ................................................. 3 59 3. Overall Requirement for NVE<->NVA Control Plane ............. 4 60 4. Existing Directory Components ............................... 5 61 4.1. Types of NVA: .......................................... 5 62 4.2. Key components of the information kept in the NVA ...... 6 63 4.3. Mapping Entries Distribution Mechanism ................. 6 64 4.3.1. Push Mode ......................................... 6 65 4.3.2. Pull Mode ......................................... 8 66 4.3.3. Hybrid Mode....................................... 11 67 5. Redundancy ................................................. 12 68 6. Inconsistency Processing.................................... 12 69 7. Gap Summary ................................................ 12 70 7.1. Features necessary to NVO3 but not present in TRILL ... 12 71 7.2. Additional detailed requirement applicable to NVO3's NVA 13 72 8. Security Considerations..................................... 14 73 9. IANA Considerations ........................................ 14 74 10. Acknowledgements .......................................... 14 75 11. References ................................................ 14 76 11.1. Normative References.................................. 14 77 11.2. Informative References................................ 15 78 Authors' Addresses ............................................ 15 80 1. Introduction 82 The intent of the draft is to identify the gaps of existing 83 solutions against NVO3's requirement for Network Virtualization 84 Authority (NVA). Through the gap analysis, the document provides 85 a basis for future works to develop solutions for (NVA). 87 The existing solutions analyzed in draft include the LISP mapping 88 database system and TRILL's directory mechanism. 90 Section 4.5 of [nvo3-problem-statement] describes the back-end 91 Network Virtualization Authority (NVA) that is responsible for 92 distributing the mapping information for entire overlay system. 93 [nvo3-nve-nva-cp-req] defines the requirement for the control 94 plane between NVA and NVE. 96 There are many similarities between LISP, TRILL [RFC6325] and 97 NVO3, e.g. LISP using IP header to achieve overlay, TRILL using 98 TRILL header to achieve overlay, and NV03 using L3 headers plus 99 VNID to achieve overlay. This draft analyzes the TRILL directory 100 mechanisms along with some LISP mapping database system that are 101 applicable to NVO3's NVA<->NVE and summarize the gaps. 103 2. Terminology 105 The following terms are used interchangeably in this document: 107 - The terms "Subnet" and "VLAN" because it is common to 108 map one subnet to one VLAN. 109 - The term ''Directory'' and ''Network Virtualization 110 Authority (NVA)'' 111 - The term ''NVE'' and ''Edge'' 113 Bridge: IEEE Std 802.1Q-2011 compliant device [802.1Q]. In this 114 draft, Bridge is used interchangeably with Layer 2 115 switch. 117 DA: Destination Address 119 DC: Data Center 121 EoR: End of Row switches in data center. Also known as 122 aggregation switches. 124 End Station: Guest OS running on a physical server or on a 125 virtual machine. An end station in this document has at 126 least one IP address and at least one MAC address, which 127 could be in DA or SA field of a data frame. 129 LISP: Locator/ID Separation Protocol 131 RBridge: ''Routing Bridge'', an alternative name for a TRILL 132 switch. 134 NVA: Network Virtualization Authority 136 NVE: Network Virtualization Edge 138 SA: Source Address 140 Station: A node, or a virtual node, with IP and/or MAC addresses, 141 which could be in the DA or SA of a data frame. 143 ToR: Top of Rack Switch in data center. It is also known as 144 access switches in some data centers. 146 TRILL: Transparent Interconnection of Lots of Links [RFC6325] 148 TRILL switch: A device implementing the TRILL protocol [RFC6325] 150 TS: Tenant System 152 VM: Virtual Machines 154 VN: Virtual Network 156 VNID: Virtual Network Instance Identifier 158 3. Overall Requirement for NVE<->NVA Control Plane 160 Section 3.1 of [nvo3-cp-req] describes the basic requirement of 161 inner address to outer address mapping for NVO3. A NVE needs to 162 know the mapping of the Tenant System destination (inner) address 163 to the (outer) address (IP) on the Underlying Network of the 164 egress NVE, in the same way as a TRILL Edge node needing to know 165 how the inner MAC/VLAN is mapped to the egress TRILL edge. 167 Section 3.1 of [nvo3-cp-req] states that a protocol is needed to 168 provide this inner to outer mapping and VN Context to each NVE 169 that requires it and keep the mapping updated in a timely manner. 171 Timely updates are important for maintaining connectivity between 172 Tenant Systems. 174 TRILL's directory mechanism and LISP mapping database system are 175 to achieve the same goal as NVO3's NVE-NVA control plane, i.e. 176 distributing the mapping table that edge nodes use to tunnel 177 traffic across the underlying network. Therefore it is worthwhile 178 to examine the TRILL's directory mechanism and LISP mapping 179 database system, and analyze the gaps. 181 4. Existing Directory Components 183 For the ease of description, we match the terminologies used by 184 TRILL/LISP to NVO3. The document will use the NVO3's 185 terminologies as much as possible throughout the document to 186 describe TRILL's directory assistance mechanism. 188 NVO3 LISP TRILL 190 ---- -------- -------------------------- 192 NVE Edge Edge, TRILL Edge or RBridge Edge 194 NVA MapServer Directory 196 4.1. Types of NVA: 198 NVAs can be centralized or distributed with each NVA holding the 199 mapping information for a subset of VNs. Centralized NVA could 200 have multiple entities for redundancy purpose. A NVA could be 201 instantiated on a server/VM attached to a NVE, very much like a 202 TS attached to a NVE, or could be integrated with a NVE. When a 203 NVA is a standalone server/VM attached to a NVE, it has to be 204 reachable via the attached NVE by other NVEs. A NVA can also be 205 instantiated on a NVE that doesn't have any TSs attached. The 206 NVE-NVA control plane for NVA being attached to NVE will require 207 additional functions on NVEs than NVA being instantiated on NVE. 209 4.2. Key components of the information kept in the NVA 211 The information held by the TRILL directories is inner-outer 212 address mapping information as well as hosts' VLAN IDs. Same is 213 true for NVO3's NVA. For each TS (or VM), TRILL directory has the 214 following attributes: 216 1. Inner Address: TS (host) Address family (IPv4/IPv6, MAC, 217 virtual network Identifier MPLS/VLAN, etc) 218 2. Outer Address: The list of locally attached edges (NVEs); 219 normally one TS is attached to one edge, TS could also be 220 attached to 2 edges for redundancy (dual homing). One TS is 221 rarely attached to more than 2 edges, though it could be 222 possible; 223 3. Timer for NVEs to keep the entry when pushed down to or 224 pulled from NVEs. 225 4. Optionally the list of interested remote edges (NVEs). This 226 information is for NVA to promptly update relevant edges 227 (NVEs) when there is any change to this TS' attachment to 228 edges (NVEs). However, this information doesn't have to be 229 kept per TS. It can be kept per VN. 231 NVO3's NVA will need one additional attribute: VN Context (VN 232 ID and/or VN Name). 234 4.3. Mapping Entries Distribution Mechanism 236 A directory can offer services in a Push, Pull mode, or the 237 combination of the two. 239 4.3.1. Push Mode 241 Under this mode, Directory Server(s) push the inner-outer 242 mapping for all the entries of the VNs that are enabled on an 243 edge node (NVE). If the destination of a data frame arriving 244 at the Ingress Edge (NVE) can't be found in its inner-outer 245 mapping database that are pushed down from the Directory 246 Server(s) (or NVA), the Ingress edge could be configured with 247 one or more of the following policies: 249 - simply drop the data frame, 250 - Using legacy method(s) to forward the data frames to 251 other edges, or 252 - start the ''pull'' process to get information from Pull 253 Directory Server(s) (or NVA) 254 When the edge is waiting for reply from Pull process, 255 the edge can either drop or queue the packet. 257 Again, the VN Context (VNID or VN name) needs to be added for 258 NVO3. 260 One drawback of the Push Mode is that it usually will push 261 more mapping entries to an edge (NVE) than needed. Under the 262 normal process of edge cache aging and unknown destination 263 address flooding, rarely used entries would have been removed. 264 It would be difficult for Directory Servers (NVA) to predict 265 the communication patterns among TSs within one VN. 266 Therefore, it is likely that the Directory Servers will push 267 down all the entries for all the VNs that are enabled on the 268 NVE. 270 And with Push there really can't be any source-based policy. 271 It's all or nothing. 273 4.3.1.1. Requesting Push Service 275 In the Push Mode, it is necessary to have a way for an edge 276 node (NVE) to request directory server(s) (NVA) to start the 277 pushing process, e.g. when the NVE is initialized or re- 278 started. Or it can be like a routing protocol where it just 279 happens automatically. 281 Push Directory servers (NVAs) advertise their availability to 282 push mapping information for a particular virtual network to 283 all edges who participate in the VN. There could be multiple 284 directories (NVAs), with each having mapping information for a 285 subset of VNs. 287 TRILL edge uses modified Virtual Network scoped instances of 288 the IS-IS reliable link state flooding protocol, a.k.a. the 289 ESADI protocol mechanism, to announce all the Virtual Networks 290 in which it is participating to directories (NVAs) who have 291 the mapping information for the VNs. An edge subscribes to 292 push directory information. 294 The subscription is VN scoped, so that a directory server 295 doesn't need to push down the entire set of mapping entries. 296 Each Push Directory server also has a priority. For 297 robustness, the one or two directories with the highest 298 priority are considered as Active in pushing information for 299 the VN to all edges who have subscribed for that VN. 301 4.3.1.2. Incremental Push Service 303 Whenever there is any change in TS' association to an edge 304 (NVE), which can be triggered by TS being added, removed, or 305 de-commissioned, an incremental update can be sent to the 306 edges that are impacted by the change. Therefore, sequence 307 numbers have to be maintained by directory servers (NVA) and 308 edges (NVEs). 310 If the Push Directory server is configured to believe it has 311 complete mapping information for VN X then, after it has 312 actually transmitted all of its ESADI-LSPs for X it waits its 313 CSNP time (see Section 6.1 of [ESADI]), and then updates its 314 ESADI-Parameters APPsub-TLV to set the Complete Push (CP) bit 315 to one. It then maintains the CP bit as one as long as it is 316 Active. 318 4.3.2. Pull Mode 320 Under this mode, an NVE pulls the mapping entry from the 321 directory servers (or NVA) when its cache doesn't have the 322 entry. 324 The main advantage of Pull Mode is that state is stored only 325 where it needs to be stored and only when it is required. In 326 addition, in the Pull Mode, edge nodes (NVEs) can age out 327 mapping entries if they haven't been used for a certain period 328 of time. Therefore, each edge (NVE) will only keep the entries 329 that are frequently used, so its mapping table size will be 330 smaller than a complete table pushed down from NVA. 332 The drawback of Pull Mode is that it might take some time for 333 NVEs to pull the needed mapping from NVA. Before NVE gets the 334 response from NVA, the NVE has to buffer the subsequent data 335 frames with destination address to the same target. The buffer 336 could overflow before the NVE gets the response from NVA. 337 However, this scenario should not happen very often in data 338 center environment because most likely the TSs are end systems 339 which have to wait for (TCP) acknowledgement before sending 340 subsequent data frames. Another option is forward, not flood, 341 subsequent frames to a default location, i.e. forward to a re- 342 encapsulating NVE. 344 The practice of an edge waiting and dropping packets upon 345 receiving an unknown DA is not new. Most deployed routers 346 today drop packets while waiting for target addresses to be 347 resolved. It is too expensive to queue subsequent packets 348 while resolving target address. The routers send ARP/ND 349 requests to the target upon receiving a packet with DA not in 350 its ARP/ND cache and wait for an ARP or ND responses. This 351 practice minimizes flooding when targets don't exist in the 352 subnet. When the target doesn't exist in the subnet, routers 353 generally re-send an ARP/ND request a few more times before 354 dropping the packets. The holding time by routers to wait for 355 an ARP/ND response when the target doesn't exist in the subnet 356 can be longer than the time taken by the Pull Mode to get 357 mapping from NVA. 359 4.3.2.1. Pull Requests 361 Here are some events that can trigger the pulling process: 363 o An edge node (NVE) receives an ingress data frame with a 364 destination whose attached edge (NVE) is unknown, or 365 o The edge node (NVE) receives an ingress ARP/ND request for 366 a target whose link address (MAC) or attached edge (NVE) 367 is unknown. 369 Each Pull request can have queries for multiple inner-outer 370 mapping entries. 372 4.3.2.2. Pull Response 374 There are several possibilities of the Pull Response: 376 1. Valid inner-outer address mapping, coupled with the valid 377 timer indicating how long the entry can be cached by the 378 edge (NVE). 379 The timer for cache should be short in an environment where 380 VMs move frequently. The cache timer can also be configured. 382 2. The target being queried is not available. The response 383 should include the policy if requester should forward data 384 frame in legacy way, or drop the data frame. 386 3. The requestor is administratively prohibited from getting an 387 informative response. 389 If no response is received to a Pull Directory request within 390 a configurable timeout, the request should be re-transmitted 391 with the same Sequence Number up to a configurable number of 392 times that defaults to three. 394 4.3.2.3. Cache Consistency 396 It is important that the cached information be kept consistent 397 with the actual placement of VMs. Therefore, it is highly 398 desirable to have a mechanism to prevent NVEs from using the 399 staled mapping entries. 401 When data at a Pull Directory changes, such as entry being 402 deleted or new entry added, and there may be unexpired stale 403 information at a querying edge (NVE), the Pull Directory MUST 404 send an unsolicited message to the edge (NVE). 406 To achieve this goal, a Pull Directory server MUST maintain 407 one of the following, in order of increasing specificity. 409 1. An overall record per VN of when the last returned query 410 data will expire at a requestor and when the last query record 411 specific negative response will expire. 413 2. For each unit of data (IA APPsub-TLV Address Set) held by 414 the server and each address about which a negative response 415 was sent, when the last expected response with that unit or 416 negative response will expire at a requester. 418 Note: It is much more important to cache negative reply, 419 because there are many invalid address queries. Study has 420 shown that for each valid ND query, there are 100's of invalid 421 address queries. 423 3. For each unit of data held by the server and each address 424 about which a negative response was sent, a list of Edges that 425 were sent that unit as the response or sent a negative 426 response to the address, with the expected time to expiration 427 at each of them. 429 4.3.2.4. Pull Request Errors 431 If errors occur at the query level, they MUST be reported in a 432 response message separate from the results of any successful 433 queries. If multiple queries in a request have different 434 errors, they MUST be reported in separate response messages. 435 If multiple queries in a request have the same error, this 436 error response MAY be reported in one response message. 438 4.3.2.5. Redundant Pull Directories (NVAs) 440 There could be multiple directories (NVA) holding mapping 441 information for a particular VN for reliability or scalability 442 purposes. Pulling Directories (NVAs) advertise themselves by 443 having the Pull Directory flag on in their Interested VNs sub- 444 TLV [rfc6326bis]. 446 A pull request can be sent to any of them that is reachable 447 but it is RECOMMENDED that pull requests be sent to a server 448 (NVA) that is least cost from the requesting edge (NVE). 450 4.3.3. Hybrid Mode 452 For some edge nodes that have great number of VNs enabled and 453 combined number of hosts under all those VNs are large, 454 managing the inner-outer address mapping for hosts under all 455 those VNs can be a challenge. This is especially true for Data 456 Center gateway nodes, which need to communicate with a 457 majority of VNs if not all. 459 For those Edge nodes, a hybrid mode should be considered. That 460 is the Push Mode being used for some VNs, and the Pull Mode 461 being used for other VNs. It is the network operator's 462 decision by configuration as to which VNs' mapping entries are 463 pushed down from directories (NVA) and which VNs' mapping 464 entries are pulled. 466 In addition, directory can inform the Edge to use legacy way 467 to forward if it doesn't have the mapping information, or the 468 Edge is administratively prohibited from forwarding data frame 469 to the requested target. 471 5. Redundancy 473 For redundancy purpose, there should be more than one directory 474 (NVAs) that hold mapping information for each VN. At any given 475 time, only one or a small number of push directories is 476 considered as active for a particular VN. All NVAs should 477 announce its capability and priority to all the edges. 479 6. Inconsistency Processing 481 If an edge (NVE) notices that a Push Directory server (NVA) is no 482 longer reachable [RFCclear], it MUST ignore any Push Directory 483 data from that server because it is no longer being updated and 484 may be stale. 486 There may be transient conflicts between mapping information from 487 different Push Directory servers (NVAs) or conflicts between 488 locally learned information and information received from a Push 489 Directory server. TRILL associates a confidence level with 490 address table information so, in case of such conflicts, 491 information with a higher confidence value is preferred over 492 information with a lower confidence. In case of equal confidence, 493 Push Directory information is preferred to locally learned 494 information and if information from Push Directory servers 495 conflicts, the information from the higher priority Push 496 Directory server is preferred. 498 7. Gap Summary 500 7.1. Features necessary to NVO3 but not present in TRILL 502 NVO3's NVA will need one additional attribute: VN context (VN 503 ID and/or VN Name). 505 For data center networks that don't have IS-IS protocol 506 enabled, other mechanism have to be considered. 508 7.2. Additional detailed requirement applicable to NVO3's NVA 510 Here are some of the TRILL's directory detailed requirements that 511 should be considered by NVO3 NVA as well: 513 - Push Mode: 514 o For redundancy purposes, for each VN there should be 515 multiple NVA entities holding the mapping information for 516 the TSs in the VN. At any given time, only one or a small 517 number of the NVAs are considered as Active for a 518 particular VN. All NVAs should announce their capability 519 and priority to all the edges. 520 o If the destination of a data frame arriving at the Ingress 521 Edge (NVE) can't be found in its inner-outer mapping table 522 that are pushed down from the Directory Server(s) (NVA), 523 the Ingress edge could be configured to: 525 simply drop the data frame, 526 flood it to all other edges that are in the same VN, 527 or 528 start the ''pull'' process to get information from Pull 529 Directory Server(s) (or NVA) 530 o If an NVE lost its connection to its NVA, it MUST ignore 531 any Push Directory data from that server because it is no 532 longer being updated and may be stale. 533 o When transient conflict occurs: higher priority data take 534 precedence. 536 - Pull Mode: 537 o The Pull Directory response could indicate that the 538 address being queried is not available in NVA or that the 539 requestor is administratively prohibited from getting an 540 informative response. 541 o The timer for ingress NVE caching should be short in an 542 environment where VMs move frequently. The cache timer 543 could be configured or could be sent along with the Pulled 544 reply from the NVA. 545 o Each Pull request can have multiple queries for different 546 TSs. 547 o It is highly desirable to have a mechanism to prevent NVEs 548 from using the stale mapping entries pulled from NVA. 550 o While waiting for query response from NVA, the NVE has to 551 buffer the subsequent data frames with destination address 552 to the same target. The buffer could overflow before the 553 NVE gets the response from NVA. 554 o If no response is received to a Pull Directory request 555 within a configurable timeout, the request should be re- 556 transmitted with the same Sequence Number up to a 557 configurable number of times. 559 - Hybrid Mode: 560 o NVE can be configured to get some VN's mapping entries via 561 push mode and other VN's mapping entries via pull mode. 563 8. Security Considerations 565 Accurate mapping of inner address into outer addresses is 566 important to the correct delivery of information. The security 567 of specific directory assisted mechanisms will be discussed in 568 the document or documents specifying those mechanisms. 570 For general TRILL security considerations, see [RFC6325]. 572 9. IANA Considerations 574 This document requires no IANA actions. RFC Editor: please delete 575 this section before publication. 577 10. Acknowledgements 579 Special thanks to Dino Farinacci for valuable suggestions and 580 comments to this draft. 582 11. References 584 11.1. Normative References 586 As an Informational document, this draft has no Normative 587 References. 589 [nvo3-nve-nva-cp-req] draft-ietf-nvo3-nve-nva-cp-req-00, "Network 590 Virtualization NVE to NVA Control Protocol 591 Requirements", Kreeger, et al. July 31, 3013. 593 11.2. Informative References 595 [802.1Q] IEEE Std 802.1Q-2011, "IEEE Standard for Local and 596 metropolitan area networks - Virtual Bridged Local Area 597 Networks", May 2011. 599 [802.1Qbg] IEEE Std 802.1Qbg-2012, ''Media Access Control (MAC) 600 Bridges and Virtual Bridged Local Area Networks -- Edge 601 Virtual Bridging'', July 2012. 603 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", 604 RFC 826, November 1982. 606 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 607 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 608 September 2007. 610 [RFC6325] Perlman, et, al ''RBridge: Base Protocol Specification'', 611 https://datatracker.ietf.org/doc/rfc6325/, July, 2011 613 [RFC6439] Perlman, et, al ''RBridges: Appointed Forwarders'', 614 https://datatracker.ietf.org/doc/rfc6439/, Nov 2011 616 Authors' Addresses 618 Linda Dunbar 619 Huawei Technologies 620 5430 Legacy Drive, Suite #175 621 Plano, TX 75024, USA 622 Phone: (469) 277 5840 623 Email: linda.dunbar@huawei.com 624 Donald Eastlake 625 Huawei Technologies 626 155 Beaver Street 627 Milford, MA 01757 USA 628 Phone: 1-508-333-2270 629 Email: d3e3e3@gmail.com