idnits 2.17.1 draft-retana-idr-add-paths-implementation-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 (November 13, 2014) is 3445 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4724' is mentioned on line 592, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational November 13, 2014 5 Expires: May 17, 2015 7 Advertisement of Multiple Paths in BGP: Implementation Report 8 draft-retana-idr-add-paths-implementation-01 10 Abstract 12 This document reports the results of an ADD-PATH implementation 13 survey. The survey had 22 questions about implementations' support 14 for advertising multiple paths in BGP. After a brief summary of the 15 results, each response is listed. This document contains responses 16 from six implementers who completed the survey. 18 The editor did not use external means to verify the accuracy of the 19 information submitted by the respondents. The respondents are 20 considered experts on the products they reported on. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 17, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Results of the Survey . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Overview of Differences . . . . . . . . . . . . . . . . . 3 60 3.2. Implementation Identification . . . . . . . . . . . . . . 4 61 3.3. Implementations and Interoperability . . . . . . . . . . 5 62 4. Implementation Report . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Section 2: How to Identify a Path . . . . . . . . . . . . 6 64 4.1.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 6 65 4.1.2. Path Identifier Assignment . . . . . . . . . . . . . 6 66 4.1.3. Path Identifier Assignment (2) . . . . . . . . . . . 6 67 4.1.4. Route Re-advertisement . . . . . . . . . . . . . . . 7 68 4.1.5. Received Path Identifier . . . . . . . . . . . . . . 7 69 4.2. Section 3: Extended NLRI Encodings . . . . . . . . . . . 8 70 4.2.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 8 71 4.3. Section 4: ADD-PATH Capability . . . . . . . . . . . . . 8 72 4.3.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 8 73 4.4. Section 5: Operation . . . . . . . . . . . . . . . . . . 9 74 4.4.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 9 75 4.4.2. Implicit Replacement . . . . . . . . . . . . . . . . 9 76 4.4.3. Silently Ignore . . . . . . . . . . . . . . . . . . . 9 77 4.4.4. Send/Receive Logic . . . . . . . . . . . . . . . . . 10 78 4.4.5. Update Procedure . . . . . . . . . . . . . . . . . . 10 79 4.4.6. Update Generation with Encoding . . . . . . . . . . . 11 80 4.4.7. Multiple Address Family Support . . . . . . . . . . . 11 81 4.4.8. Multiple Address Family Support (2) . . . . . . . . . 12 82 4.4.9. Bestpath . . . . . . . . . . . . . . . . . . . . . . 12 83 4.4.10. Path Identifier Persistency . . . . . . . . . . . . . 13 84 4.4.11. Graceful Restart . . . . . . . . . . . . . . . . . . 13 85 4.5. Section 6: Applications . . . . . . . . . . . . . . . . . 14 86 4.5.1. Applications . . . . . . . . . . . . . . . . . . . . 14 87 4.6. Section 7: Deployment Considerations . . . . . . . . . . 15 88 4.6.1. Deployment Experience . . . . . . . . . . . . . . . . 15 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 8.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 This document reports results from a survey of implementations of the 100 Advertisement of Multiple Paths in BGP [I-D.ietf-idr-add-paths], 101 where a BGP [RFC4271] extension that allows the advertisement of 102 multiple paths for the same address prefix without the new paths 103 implicitly replacing any previous ones is defined. The essence of 104 the extension is that each path is identified by a path identifier in 105 addition to the address prefix. 107 The ADD-PATH implementation survey had 22 detailed questions about 108 compliance with [I-D.ietf-idr-add-paths]. Six implementers (Cumulus 109 Networks, Cisco Systems, Exa Networks, Juniper Networks, Alcatel- 110 Lucent and CZ.NIC) completed the survey. Section 3.1 provides an 111 overview of the differences between the implementations. Section 4 112 provides a compilation of the results. 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Results of the Survey 122 The respondents replied "Yes" or "No" to the survey's questions to 123 indicate whether their implementation supports the Functionality/ 124 Description of the [RFC2119] language in [I-D.ietf-idr-add-paths]. 125 The respondents replied "Other" to indicate an alternate behavior and 126 had the opportunity to provide comments in all cases. Some questions 127 were informative. 129 3.1. Overview of Differences 131 This section provides the reader with a shortcut to the points where 132 the implementations differ. 134 Two of the implementations work only in receive-mode; they don't 135 implement any advertisement of routes. Obviously, those 136 implementations are not compliant with the sections related to the 137 advertisement of routes. Taking that fact into account, all the 138 responders had consistent and compliant answers to all the sections 139 of the survey. 141 3.2. Implementation Identification 143 3.3.1. Cumulus 145 Company/Organization Name: Cumulus Networks 147 Implementation Name/Version: quagga 149 Date: 11/3/2014 151 Contact Name: Daniel Walton 153 Contact e-mail: dwalton@cumulusnetworks.com 155 3.3.2. Cisco 157 Company/Organization Name: Cisco Systems 159 Implementation Name/Version: IOS-XE 161 Date: 11/03/2014 163 Contact Name: Mohammed Mirza 165 Contact e-mail: mohamirz@cisco.com 167 3.3.3. Exa 169 Company/Organization Name: Exa Networks 171 Implementation Name/Version: ExaBGP 173 Date: 01/11/2014 175 Contact Name: Thomas Mangin 177 Contact e-mail: thomas.mangin@exa-networks.co.uk 179 3.3.4. Juniper 181 Company/Organization Name: Juniper Networks 183 Implementation Name/Version: JUNOS 11.3 and later 185 Date: August 2011 187 Contact Name: Jeff Haas 188 Contact e-mail: jhaas@juniper.net 190 3.3.5. ALU 192 Company/Organization Name: Alcatel-Lucent 194 Implementation Name/Version: SROS 196 Date: 11/10/2014 198 Contact Name: Adam Simpson 200 Contact e-mail: adam.simpson@alcatel-lucent.com 202 3.3.6. CZ.NIC 204 Company/Organization Name: CZ.NIC 206 Implementation Name/Version: BIRD 208 Date: 2014-11-12 210 Contact Name: Ondrej Zajicek 212 Contact e-mail: santiago@crfreenet.org 214 3.3. Implementations and Interoperability 216 +---------+---------+-------+-----+---------+-----+--------+ 217 | | Cumulus | Cisco | Exa | Juniper | ALU | CZ.NIC | 218 | Cumulus | | Yes | | | | Yes | 219 | Cisco | | Yes | | | | | 220 | Exa | | Yes | | | | | 221 | Juniper | | | | | | | 222 | ALU | | Yes | | | | | 223 | CZ.NIC | | | | | | | 224 +---------+---------+-------+-----+---------+-----+--------+ 226 4. Implementation Report 228 For every item listed, the respondents indicated whether their 229 implementation supports the Functionality/Description or not (Yes/No) 230 according to the [RFC2119] language indicated. Any comments are 231 included. If appropriate, the respondents indicated with "Other" the 232 fact that the support is neither Yes/No (an alternate behavior, for 233 example). Refer to the appropriate sections in 234 [I-D.ietf-idr-add-paths] for additional details. 236 4.1. Section 2: How to Identify a Path 238 4.1.1. Base Behavior 240 Functionality/Description: Is your implementation compatible with the 241 use of the Path Identifier as described in this section? 243 [RFC2119]: N/A 245 Implementation Yes/No/Other Comments 246 -------------- ------------ -------- 247 Cumulus Yes 248 Cisco Yes 249 Exa Yes 250 Juniper Yes 251 ALU Yes 252 CZ.NIC Yes 254 4.1.2. Path Identifier Assignment 256 Functionality/Description: Explain how Path Identifiers are assigned 257 in your implementation. 259 [RFC2119]: N/A 261 Implementation Comments 262 -------------- ------------------------------------------------------ 263 Cumulus quagga is RX only for now so this is not an issue 264 Cisco Each net has unique path-id per paths under it. The 265 path ids that are withdrawn can get assigned to the 266 newer paths. 267 Exa By the user 268 Juniper Incrementally assign an id based on the N+1 of the 269 max(N) of the path ids already assigned. 270 ALU Path IDs are per address family. Every new advertised 271 path uses the next available path ID (in sequential 272 order) for the address family. 273 CZ.NIC Each route source (like add_path-unaware BGP peer) has 274 allocated fixed path id. 276 4.1.3. Path Identifier Assignment (2) 278 Functionality/Description: "...the Path Identifier MUST be assigned 279 in such a way that the BGP speaker is able to use the (prefix, path 280 identifier) to uniquely identify a path advertised to a neighbor." 282 Can your implementation uniquely identify an advertised path based on 283 the (prefix, path identifier) pair? 285 [RFC2119]: MUST 287 Implementation Yes/No/Other Comments 288 -------------- ------------ ----------------------------------------- 289 Cumulus Yes 290 Cisco Yes 291 Exa Other This is left to the user of the 292 application to do. 293 Juniper Yes 294 ALU Yes 295 CZ.NIC Yes 297 4.1.4. Route Re-advertisement 299 Functionality/Description: "A BGP speaker that re-advertises a route 300 MUST generate its own Path Identifier to be associated with the re- 301 advertised route." 303 Does your implementation generate a new Path Identifier when re- 304 advertising a route? 306 [RFC2119]: MUST 308 Implementation Yes/No/Other Comments 309 -------------- ------------ ----------------------------------------- 310 Cumulus Other Comments quagga does not support TX yet 311 Cisco Yes 312 Exa Other ExaBGP does not re-advertise routes 313 Juniper Yes 314 ALU Yes 315 CZ.NIC Other New path_id is allocated for each unique 316 path_id received through add_path-aware 317 BGP session. 319 4.1.5. Received Path Identifier 321 Functionality/Description: "A BGP speaker that receives a route 322 SHOULD NOT assume that the identifier carries any particular 323 semantics; it SHOULD be treated as an opaque value." 325 Does your implementation treat a received Path Identifier as an 326 opaque value? 328 [RFC2119]: SHOULD NOT 329 Implementation Yes/No/Other Comments 330 -------------- ------------ -------- 331 Cumulus Yes 332 Cisco Yes 333 Exa Yes 334 Juniper Yes 335 ALU Yes 336 CZ.NIC Yes 338 4.2. Section 3: Extended NLRI Encodings 340 4.2.1. Base Behavior 342 Functionality/Description: Does your implementation use the encodings 343 specified in this section? 345 [RFC2119]: N/A 347 Implementation Yes/No/Other Comments 348 -------------- ------------ -------- 349 Cumulus Yes 350 Cisco Yes 351 Exa Yes 352 Juniper Yes 353 ALU Yes 354 CZ.NIC Yes 356 4.3. Section 4: ADD-PATH Capability 358 4.3.1. Base Behavior 360 Functionality/Description: Is your implementation able to send and 361 receive the ADD-PATH Capability as described in this section? 363 [RFC2119]: N/A 365 Implementation Yes/No/Other Comments 366 -------------- ------------ -------- 367 Cumulus Yes 368 Cisco Yes 369 Exa Yes 370 Juniper Yes 371 ALU Yes 372 CZ.NIC Yes 374 4.4. Section 5: Operation 376 4.4.1. Base Behavior 378 Functionality/Description: Is your implementation compatible with the 379 operation described in this section? 381 [RFC2119]: N/A 383 Implementation Yes/No/Other Comments 384 -------------- ------------ -------------------------- 385 Cumulus Other RX yes, TX not implemented 386 Cisco Yes 387 Exa Yes 388 Juniper Yes 389 ALU Yes 390 CZ.NIC Yes 392 4.4.2. Implicit Replacement 394 Functionality/Description: "...a new advertisement for a given 395 address prefix and a given path identifier replaces a previous 396 advertisement for the same address prefix and path identifier." 398 Does your implementation replace previous advertisements with the 399 same (prefix, path identifier) pair? 401 [RFC2119]: N/A 403 Implementation Yes/No/Other Comments 404 -------------- ------------ ------------------------------- 405 Cumulus Yes 406 Cisco Yes 407 Exa Other ExaBGP does not implement a FIB 408 Juniper Yes 409 ALU Yes 410 CZ.NIC Yes 412 4.4.3. Silently Ignore 414 Functionality/Description: "If a BGP speaker receives a message to 415 withdraw a prefix with a path identifier not seen before, it SHOULD 416 silently ignore it." 418 Does your implementation silently ignore the withdraw of a prefix 419 with a new path identifier? 421 [RFC2119]: SHOULD 422 Implementation Yes/No/Other Comments 423 -------------- ------------ ----------------------------------------- 424 Cumulus 425 Cisco Yes 426 Exa Other ExaBGP is a "BGP engine", it only convert 427 BGP packet to some JSON that another 428 application can consume ( and vice-versa 429 ). 430 Juniper Yes 431 ALU Yes 432 CZ.NIC 434 4.4.4. Send/Receive Logic 436 Functionality/Description: "For a BGP speaker to be able to send 437 multiple paths to its peer, that BGP speaker MUST advertise the ADD- 438 PATH capability with the Send/Receive field set to either 2 or 3, and 439 MUST receive from its peer the ADD-PATH capability with the Send/ 440 Receive field set to either 1 or 3, for the corresponding ." 443 Does your implementation follow the send/receive logic as specified 444 in this section? 446 [RFC2119]: MUST 448 Implementation Yes/No/Other Comments 449 -------------- ------------ -------- 450 Cumulus Yes 451 Cisco Yes 452 Exa Yes 453 Juniper Yes 454 ALU Yes 455 CZ.NIC Yes 457 4.4.5. Update Procedure 459 Functionality/Description: "A BGP speaker MUST follow the existing 460 procedures in generating an UPDATE message for a particular to a peer unless the BGP speaker advertises the ADD-PATH 462 Capability to the peer indicating its ability to send multiple paths 463 for the , and also receives the ADD-PATH Capability from 464 the peer indicating its ability to receive multiple paths for the 465 ..." 467 Does your implementation follow normal procedures when generating 468 UPDATES if the ADD-PATH capability is not sent and received? 470 [RFC2119]: MUST 472 Implementation Yes/No/Other Comments 473 -------------- ------------ -------- 474 Cumulus Yes 475 Cisco Yes 476 Exa Yes 477 Juniper Yes 478 ALU Yes 479 CZ.NIC Yes 481 4.4.6. Update Generation with Encoding 483 Functionality/Description: "...in which case the speaker MUST 484 generate a route update for the based on the combination 485 of the address prefix and the Path Identifier, and use the extended 486 NLRI encodings specified in this document." 488 If the ADD-PATH capability has been sent and received, does your 489 implementation generate new UPDATEs using the (prefix, path 490 identifier) pair and the encodings defined in this document? 492 [RFC2119]: MUST 494 Implementation Yes/No/Other Comments 495 -------------- ------------ ----------------------- 496 Cumulus Other TX is not supported yet 497 Cisco Yes 498 Exa Yes 499 Juniper Yes 500 ALU Yes 501 CZ.NIC Yes 503 4.4.7. Multiple Address Family Support 505 Functionality/Description: "The peer SHALL act accordingly in 506 processing an UPDATE message related to a particular ." 508 Does your implementation support the use of the ADD-PATH capability 509 for multiple pairs? 511 [RFC2119]: SHALL 512 Implementation Yes/No/Other Comments 513 -------------- ------------ ----------------------------------------- 514 Cumulus Yes 515 Cisco Yes 516 Exa Yes 517 Juniper Yes 518 ALU Yes 519 CZ.NIC Other BIRD currently does not support multiple 520 pairs in one connection, separate 521 connection is used for IPv4 and IPv6 522 (unicast). 524 4.4.8. Multiple Address Family Support (2) 526 Functionality/Description: Which pairs does your 527 implementation support when using the ADD-PATH capability? 529 [RFC2119]: N/A 531 Implementation Comments 532 -------------- ------------------------------------------------------ 533 Cumulus IPv4 unicast and IPv6 unicast 534 Cisco ipv4 unicast and ipv6 unicast 535 Exa 1/1 2/1 1/4 2/4 536 Juniper IPv4 Unicast, IPv6 Unicast, IPv4 Labeled Unicast, IPv6 537 Labeled Unicast 538 ALU 1/1, 1/4, 1/128, 2/1, 2/4, 2/128 539 CZ.NIC IPv4 unicast and IPv6 unicast 541 4.4.9. Bestpath 543 Functionality/Description: "A BGP speaker SHOULD include the bestpath 544 when more than one path are advertised to a neighbor unless the 545 bestpath is a path received from that neighbor." 547 Does your implementation include the bestpath when multiple paths are 548 announced to a neighbor, as described? 550 [RFC2119]: SHOULD 551 Implementation Yes/No/Other Comments 552 -------------- ------------ ----------------------------------------- 553 Cumulus Yes 554 Cisco Yes 555 Exa Other ExaBGP does not have a FIB, this is user 556 controlled. 557 Juniper Yes 558 ALU Yes 559 CZ.NIC Yes 561 4.4.10. Path Identifier Persistency 563 Functionality/Description: "As the Path Identifiers are locally 564 assigned, and may or may not be persistent across a control plane 565 restart of a BGP speaker..." 567 Are the path identifiers persistent across control plane restarts in 568 your implementation? 570 [RFC2119]: N/A 572 Implementation Yes/No/Other Comments 573 -------------- ------------ ----------------------------------------- 574 Cumulus No 575 Cisco No XE-BGP-ADD-Paths need to have HA 576 enhancements 577 Exa Other User controlled 578 Juniper Other In the case of the BGP graceful restart 579 feature, path IDs are not persistent. In 580 the case of the JUNOS Non-stop Routing 581 feature, they persist. 582 ALU No With high availability (HA) the path IDs 583 are persistent if there is still one 584 remaining control card after 585 reset/failure of the other control card. 586 CZ.NIC No 588 4.4.11. Graceful Restart 590 Functionality/Description: "...an implementation SHOULD take special 591 care so that the underlying forwarding plane of a "Receiving Speaker" 592 as described in [RFC4724] is not affected during the graceful restart 593 of a BGP session." 595 Please explain how your implementation addresses Graceful Restart. 597 [RFC2119]: SHOULD 598 Implementation Comments 599 -------------- ------------------------------------------------------ 600 Cumulus Quagga has partial GR support (it is GR aware for 601 other restarting nodes) but does not maintain the 602 forwarding plane during a restart. 603 Cisco XE-BGP-ADD-Paths need to have HA enhancements 604 Exa No FIB, not relevant 605 Juniper During BGP graceful restart procedures, the receiving 606 speaker ignores the path-id for purposes of 607 identifying a matching route. Once a refreshed route 608 has been correlated to a previous path, the path-id is 609 updated. 610 ALU Graceful restart is supported for the receiving router 611 role so by definition graceful restart does not affect 612 the forwarding plane. 613 CZ.NIC FIB is not modified until initial graceful restart 614 phase is finished. 616 4.5. Section 6: Applications 618 4.5.1. Applications 620 Functionality/Description: Please list or explain which applications 621 that require the propagation of multiple paths are supported by your 622 implementation. 624 [RFC2119]: N/A 626 Implementation Comments 627 -------------- ------------------------------------------------------ 628 Cumulus None yet....RX onlys 629 Cisco 1. RR client to RR use cases for ipv4 and ipv6. 2. RR 630 to RR clients(could be ASBRs) use cases for ipv4 and 631 ipv6. 632 Exa N/A 633 Juniper Persistent route flap damping suppression. 634 Distribution of additional destinations or BGP 635 nexthops for multi-path purposes. 636 ALU Add-Paths ion IBGP sessions allows for better load- 637 sharing (more ECMP paths), advertisement of potential 638 backup paths, reduced routing churn. 639 CZ.NIC (iBGP) route reflector / RR client, (eBGP) route 640 server / RS client, use cases where paths are 641 distributed for other purposes than filling FIBs (like 642 topology-aware CDNs). 644 4.6. Section 7: Deployment Considerations 646 4.6.1. Deployment Experience 648 Functionality/Description: Please comment on deployment experience 649 with your implementation. 651 [RFC2119]: N/A 653 Implementation Comments 654 -------------- ------------------------------------------------------ 655 Cumulus 656 Cisco 657 Exa Cisco routers exporting ADD-PATH routes to ExaBGP, 658 routes are then stored in a distributed Database. A 659 complex best path selection (including latency) is 660 performed on the stored routes, and the best routes 661 are then re-injected in the core via ExaBGP. 662 Juniper 663 ALU 664 CZ.NIC 666 5. Security Considerations 668 This document reports the results of an ADD-PATH implementation 669 survey. As such, it does not iintroduce any security risks. 671 6. IANA Considerations 673 This document has no IANA actions. 675 7. Acknowledgements 677 The editor would like to thank Daniel Walton, Mohammed Mirza, Thomas 678 Mangin, Jeff Haas, Adam Simpson and Ondrej Zajicek. 680 8. References 682 8.1. Normative References 684 [I-D.ietf-idr-add-paths] 685 Walton, D., Retana, A., Chen, E., and J. Scudder, 686 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 687 add-paths-10 (work in progress), October 2014. 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, March 1997. 692 8.2. Informative References 694 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 695 Protocol 4 (BGP-4)", RFC 4271, January 2006. 697 Author's Address 699 Alvaro Retana 700 Cisco Systems, Inc. 701 7025 Kit Creek Rd. 702 Research Triangle Park, NC 27709 703 USA 705 Email: aretana@cisco.com