idnits 2.17.1 draft-retana-idr-add-paths-implementation-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 (November 10, 2014) is 3452 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4724' is mentioned on line 505, 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 10, 2014 5 Expires: May 14, 2015 7 Advertisement of Multiple Paths in BGP: Implementation Report 8 draft-retana-idr-add-paths-implementation-00 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 three implementers who completed the survey (Cumulus Networks, 17 Cisco Systems and Exa Networks). 19 The editor did not use external means to verify the accuracy of the 20 information submitted by the respondents. The respondents are 21 considered experts on the products they reported on. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 14, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Results of the Survey . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Overview of Differences . . . . . . . . . . . . . . . . . 3 61 3.2. Implementation Identification . . . . . . . . . . . . . . 4 62 3.3. Implementations and Interoperability . . . . . . . . . . 5 63 4. Implementation Report . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Section 2: How to Identify a Path . . . . . . . . . . . . 5 65 4.1.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 5 66 4.1.2. Path Identifier Assignment . . . . . . . . . . . . . 5 67 4.1.3. Path Identifier Assignment (2) . . . . . . . . . . . 6 68 4.1.4. Route Re-advertisement . . . . . . . . . . . . . . . 6 69 4.1.5. Received Path Identifier . . . . . . . . . . . . . . 7 70 4.2. Section 3: Extended NLRI Encodings . . . . . . . . . . . 7 71 4.2.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Section 4: ADD-PATH Capability . . . . . . . . . . . . . 7 73 4.3.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 7 74 4.4. Section 5: Operation . . . . . . . . . . . . . . . . . . 8 75 4.4.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 8 76 4.4.2. Implicit Replacement . . . . . . . . . . . . . . . . 8 77 4.4.3. Silently Ignore . . . . . . . . . . . . . . . . . . . 8 78 4.4.4. Send/Receive Logic . . . . . . . . . . . . . . . . . 9 79 4.4.5. Update Procedure . . . . . . . . . . . . . . . . . . 9 80 4.4.6. Update Generation with Encoding . . . . . . . . . . . 9 81 4.4.7. Multiple Address Family Support . . . . . . . . . . . 10 82 4.4.8. Multiple Address Family Support (2) . . . . . . . . . 10 83 4.4.9. Bestpath . . . . . . . . . . . . . . . . . . . . . . 10 84 4.4.10. Path Identifier Persistency . . . . . . . . . . . . . 11 85 4.4.11. Graceful Restart . . . . . . . . . . . . . . . . . . 11 86 4.5. Section 6: Applications . . . . . . . . . . . . . . . . . 12 87 4.5.1. Applications . . . . . . . . . . . . . . . . . . . . 12 88 4.6. Section 7: Deployment Considerations . . . . . . . . . . 12 89 4.6.1. Deployment Experience . . . . . . . . . . . . . . . . 12 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 95 8.2. Informative References . . . . . . . . . . . . . . . . . 13 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 98 1. Introduction 100 This document reports results from a survey of implementations of the 101 Advertisement of Multiple Paths in BGP [I-D.ietf-idr-add-paths], 102 where a BGP [RFC4271] extension that allows the advertisement of 103 multiple paths for the same address prefix without the new paths 104 implicitly replacing any previous ones is defined. The essence of 105 the extension is that each path is identified by a path identifier in 106 addition to the address prefix. 108 The ADD-PATH implementation survey had 22 detailed questions about 109 compliance with [I-D.ietf-idr-add-paths]. Three implementers 110 (Cumulus Networks, Cisco Systems and Exa Networks) completed the 111 survey. Section 4 provides a compilation of the results. 112 Section 3.1 provides an overview of the differences between the 113 implementations. Section 3.3 provides interoperability information. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Results of the Survey 123 The respondents replied "Yes" or "No" to the survey's questions to 124 indicate whether their implementation supports the Functionality/ 125 Description of the [RFC2119] language in [I-D.ietf-idr-add-paths]. 126 The respondents replied "Other" to indicate an alternate behavior and 127 had the opportunity to provide comments in all cases. Some questions 128 were informative. 130 3.1. Overview of Differences 132 This section provides the reader with a shortcut to the points where 133 the implementations differ. 135 The following questions were not answered "Yes" by all respondents 136 (Note that the question numbers correspond to the subsection numbers 137 of Section 4): 139 MUST 141 4.1.3, 4.1.4, 4.4.6 143 Question 4.1.3 asks about the ability of the implementation to 144 uniquely identify a path. This question is linked to 4.1.2 in which 145 the mechanism used to assigned Path Identifiers is explained. The 146 vendor that did not answer "Yes" to 4.1.3 lets the user assign Path 147 Identifiers; the response to 4.1.3 was "Other: This is left to the 148 user of the application to do." 150 Question 4.1.4 asks about the generation of Path Identifiers when re- 151 advertising a route. All responded chose "Other" -- I believe that 152 there was some misinterpretation on the intent of re-advertisement. 154 Question 4.4.6 asks about using the encoding defined when generating 155 an Update. One vendor replied "Other"; in their case, transmitting 156 Updates hasn't been implemented. 158 3.2. Implementation Identification 160 3.3.1. Cumulus 162 Company/Organization Name: Cumulus Networks 164 Implementation Name/Version: quagga 166 Date: 11/3/2014 168 Contact Name: Daniel Walton 170 Contact e-mail: dwalton@cumulusnetworks.com 172 3.3.2. Cisco 174 Company/Organization Name: Cisco Systems 176 Implementation Name/Version: IOS-XE 178 Date: 11/03/2014 180 Contact Name: Mohammed Mirza 182 Contact e-mail: mohamirz@cisco.com 184 3.3.3. Exa 186 Company/Organization Name: Exa Networks 188 Implementation Name/Version: ExaBGP 190 Date: 01/11/2014 192 Contact Name: Thomas Mangin 193 Contact e-mail: thomas.mangin@exa-networks.co.uk 195 3.3. Implementations and Interoperability 197 +---------+---------+-------+-----+-------+ 198 | | Cumulus | Cisco | Exa | Other | 199 | Cumulus | | Yes | | Bird | 200 | Cisco | | Yes | | | 201 | Exa | | Yes | | | 202 +---------+---------+-------+-----+-------+ 204 4. Implementation Report 206 For every item listed, the respondents indicated whether their 207 implementation supports the Functionality/Description or not (Yes/No) 208 according to the [RFC2119] language indicated. Any respondent 209 comments are included. If appropriate, the respondents indicated 210 with "Other" the fact that the support is neither Yes/No (an 211 alternate behavior, for example). Refer to the appropriate sections 212 in [I-D.ietf-idr-add-paths] for additional details. 214 4.1. Section 2: How to Identify a Path 216 4.1.1. Base Behavior 218 Functionality/Description: Is your implementation compatible with the 219 use of the Path Identifier as described in this section? 221 [RFC2119]: N/A 223 Implementation Yes/No/Other Comments 224 -------------- ------------ -------- 225 Cumulus Yes 226 Cisco Yes 227 Exa Yes 229 4.1.2. Path Identifier Assignment 231 Functionality/Description: Explain how Path Identifiers are assigned 232 in your implementation. 234 [RFC2119]: N/A 235 Implementation Comments 236 -------------- ------------------------------------------------------ 237 Cumulus quagga is RX only for now so this is not an issue 238 Cisco Each net has unique path-id per paths under it. The 239 path ids that are withdrawn can get assigned to the 240 newer paths. 241 Exa By the user 243 4.1.3. Path Identifier Assignment (2) 245 Functionality/Description: "...the Path Identifier MUST be assigned 246 in such a way that the BGP speaker is able to use the (prefix, path 247 identifier) to uniquely identify a path advertised to a neighbor." 249 Can your implementation uniquely identify an advertised path based on 250 the (prefix, path identifier) pair? 252 [RFC2119]: MUST 254 Implementation Yes/No/Other Comments 255 -------------- ------------ ----------------------------------------- 256 Cumulus Yes 257 Cisco Yes 258 Exa Other This is left to the user of the 259 application to do. 261 4.1.4. Route Re-advertisement 263 Functionality/Description: "A BGP speaker that re-advertises a route 264 MUST generate its own Path Identifier to be associated with the re- 265 advertised route." 267 Does your implementation generate a new Path Identifier when re- 268 advertising a route? 270 [RFC2119]: MUST 272 Implementation Yes/No/Other Comments 273 -------------- ------------ ----------------------------------------- 274 Cumulus Other Comments quagga does not support TX yet 275 Cisco Other Once a BGP speaker advertises a path-id 276 it has to also withdraw it. In case it 277 has to readvertise, it either updates the 278 older path-id path or creates a new path 279 with a new unique id. 280 Exa Other ExaBGP does not re-advertise routes 282 4.1.5. Received Path Identifier 284 Functionality/Description: "A BGP speaker that receives a route 285 SHOULD NOT assume that the identifier carries any particular 286 semantics; it SHOULD be treated as an opaque value." 288 Does your implementation treat a received Path Identifier as an 289 opaque value? 291 [RFC2119]: SHOULD NOT 293 Implementation Yes/No/Other Comments 294 -------------- ------------ -------- 295 Cumulus Yes 296 Cisco Yes 297 Exa Yes 299 4.2. Section 3: Extended NLRI Encodings 301 4.2.1. Base Behavior 303 Functionality/Description: Does your implementation use the encodings 304 specified in this section? 306 [RFC2119]: N/A 308 Implementation Yes/No/Other Comments 309 -------------- ------------ -------- 310 Cumulus Yes 311 Cisco Yes 312 Exa Yes 314 4.3. Section 4: ADD-PATH Capability 316 4.3.1. Base Behavior 318 Functionality/Description: Is your implementation able to send and 319 receive the ADD-PATH Capability as described in this section? 321 [RFC2119]: N/A 323 Implementation Yes/No/Other Comments 324 -------------- ------------ -------- 325 Cumulus Yes 326 Cisco Yes 327 Exa Yes 329 4.4. Section 5: Operation 331 4.4.1. Base Behavior 333 Functionality/Description: Is your implementation compatible with the 334 operation described in this section? 336 [RFC2119]: N/A 338 Implementation Yes/No/Other Comments 339 -------------- ------------ -------------------------- 340 Cumulus Other RX yes, TX not implemented 341 Cisco Yes 342 Exa Yes 344 4.4.2. Implicit Replacement 346 Functionality/Description: "...a new advertisement for a given 347 address prefix and a given path identifier replaces a previous 348 advertisement for the same address prefix and path identifier." 350 Does your implementation replace previous advertisements with the 351 same (prefix, path identifier) pair? 353 [RFC2119]: N/A 355 Implementation Yes/No/Other Comments 356 -------------- ------------ ------------------------------- 357 Cumulus Yes 358 Cisco Yes 359 Exa Other ExaBGP does not implement a FIB 361 4.4.3. Silently Ignore 363 Functionality/Description: "If a BGP speaker receives a message to 364 withdraw a prefix with a path identifier not seen before, it SHOULD 365 silently ignore it." 367 Does your implementation silently ignore the withdraw of a prefix 368 with a new path identifier? 370 [RFC2119]: SHOULD 372 Implementation Yes/No/Other Comments 373 -------------- ------------ -------- 374 Cumulus 375 Cisco 376 Exa 378 4.4.4. Send/Receive Logic 380 Functionality/Description: "For a BGP speaker to be able to send 381 multiple paths to its peer, that BGP speaker MUST advertise the ADD- 382 PATH capability with the Send/Receive field set to either 2 or 3, and 383 MUST receive from its peer the ADD-PATH capability with the Send/ 384 Receive field set to either 1 or 3, for the corresponding ." 387 Does your implementation follow the send/receive logic as specified 388 in this section? 390 [RFC2119]: MUST 392 Implementation Yes/No/Other Comments 393 -------------- ------------ -------- 394 Cumulus Yes 395 Cisco Yes 396 Exa Yes 398 4.4.5. Update Procedure 400 Functionality/Description: "A BGP speaker MUST follow the existing 401 procedures in generating an UPDATE message for a particular to a peer unless the BGP speaker advertises the ADD-PATH 403 Capability to the peer indicating its ability to send multiple paths 404 for the , and also receives the ADD-PATH Capability from 405 the peer indicating its ability to receive multiple paths for the 406 ..." 408 Does your implementation follow normal procedures when generating 409 UPDATES if the ADD-PATH capability is not sent and received? 411 [RFC2119]: MUST 413 Implementation Yes/No/Other Comments 414 -------------- ------------ -------- 415 Cumulus Yes 416 Cisco Yes 417 Exa Yes 419 4.4.6. Update Generation with Encoding 421 Functionality/Description: "...in which case the speaker MUST 422 generate a route update for the based on the combination 423 of the address prefix and the Path Identifier, and use the extended 424 NLRI encodings specified in this document." 425 If the ADD-PATH capability has been sent and received, does your 426 implementation generate new UPDATEs using the (prefix, path 427 identifier) pair and the encodings defined in this document? 429 [RFC2119]: MUST 431 Implementation Yes/No/Other Comments 432 -------------- ------------ ----------------------- 433 Cumulus Other TX is not supported yet 434 Cisco Yes 435 Exa Yes 437 4.4.7. Multiple Address Family Support 439 Functionality/Description: "The peer SHALL act accordingly in 440 processing an UPDATE message related to a particular ." 442 Does your implementation support the use of the ADD-PATH capability 443 for multiple pairs? 445 [RFC2119]: SHALL 447 Implementation Yes/No/Other Comments 448 -------------- ------------ -------- 449 Cumulus Yes 450 Cisco Yes 451 Exa Yes 453 4.4.8. Multiple Address Family Support (2) 455 Functionality/Description: Which pairs does your 456 implementation support when using the ADD-PATH capability? 458 [RFC2119]: N/A 460 Implementation Comments 461 -------------- ----------------------------- 462 Cumulus IPv4 unicast and IPv6 unicast 463 Cisco ipv4 unicast and ipv6 unicast 464 Exa 1/1 2/1 1/4 2/4 466 4.4.9. Bestpath 468 Functionality/Description: "A BGP speaker SHOULD include the bestpath 469 when more than one path are advertised to a neighbor unless the 470 bestpath is a path received from that neighbor." 471 Does your implementation include the bestpath when multiple paths are 472 announced to a neighbor, as described? 474 [RFC2119]: SHOULD 476 Implementation Yes/No/Other Comments 477 -------------- ------------ ----------------------------------------- 478 Cumulus Yes 479 Cisco Yes 480 Exa Other ExaBGP does not have a FIB, this is user 481 controlled. 483 4.4.10. Path Identifier Persistency 485 Functionality/Description: "As the Path Identifiers are locally 486 assigned, and may or may not be persistent across a control plane 487 restart of a BGP speaker..." 489 Are the path identifiers persistent across control plane restarts in 490 your implementation? 492 [RFC2119]: N/A 494 Implementation Yes/No/Other Comments 495 -------------- ------------ ----------------------------------------- 496 Cumulus No 497 Cisco No XE-BGP-ADD-Paths need to have HA 498 enhancements 499 Exa Other User controlled 501 4.4.11. Graceful Restart 503 Functionality/Description: "...an implementation SHOULD take special 504 care so that the underlying forwarding plane of a "Receiving Speaker" 505 as described in [RFC4724] is not affected during the graceful restart 506 of a BGP session." 508 Please explain how your implementation addresses Graceful Restart. 510 [RFC2119]: SHOULD 512 Implementation Comments 513 -------------- ------------------------------------------------------ 514 Cumulus Quagga has partial GR support (it is GR aware for 515 other restarting nodes) but does not maintain the 516 forwarding plane during a restart. 517 Cisco XE-BGP-ADD-Paths need to have HA enhancements 518 Exa No FIB, not relevant 520 4.5. Section 6: Applications 522 4.5.1. Applications 524 Functionality/Description: Please list or explain which applications 525 that require the propagation of multiple paths are supported by your 526 implementation. 528 [RFC2119]: N/A 530 Implementation Comments 531 -------------- ------------------------------------------------------ 532 Cumulus None yet....RX onlys 533 Cisco 1. RR client to RR use cases for ipv4 and ipv6. 2. RR 534 to RR clients(could be ASBRs) use cases for ipv4 and 535 ipv6. 536 Exa N/A 538 4.6. Section 7: Deployment Considerations 540 4.6.1. Deployment Experience 542 Functionality/Description: Please comment on deployment experience 543 with your implementation. 545 [RFC2119]: N/A 547 Implementation Comments 548 -------------- ------------------------------------------------------ 549 Cumulus 550 Cisco 551 Exa Cisco routers exporting ADD-PATH routes to ExaBGP, 552 routes are then stored in a distributed Database. A 553 complex best path selection (including latency) is 554 performed on the stored routes, and the best routes 555 are then re-injected in the core via ExaBGP. 557 5. Security Considerations 559 This document reports the results of an ADD-PATH implementation 560 survey. As such, it does not iintroduce any security risks. 562 6. IANA Considerations 564 This document has no IANA actions. 566 7. Acknowledgements 568 The editor would like to thank Daniel Walton, Mohammed Mirza and 569 Thomas Mangin. 571 8. References 573 8.1. Normative References 575 [I-D.ietf-idr-add-paths] 576 Walton, D., Retana, A., Chen, E., and J. Scudder, 577 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 578 add-paths-10 (work in progress), October 2014. 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, March 1997. 583 8.2. Informative References 585 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 586 Protocol 4 (BGP-4)", RFC 4271, January 2006. 588 Author's Address 590 Alvaro Retana 591 Cisco Systems, Inc. 592 7025 Kit Creek Rd. 593 Research Triangle Park, NC 27709 594 USA 596 Email: aretana@cisco.com