idnits 2.17.00 (12 Aug 2021) /tmp/idnits51271/draft-mynam-grow-diverse-path-impl-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 06, 2013) is 3295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4223' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 262, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Tantsura, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational S. Yilmaz 5 Expires: November 07, 2013 K. Patel 6 Cisco Systems 7 S. Mynam 8 Dell Force10 Networks 9 R. Raszuk 10 NTT MCL 11 May 06, 2013 13 Diverse Path Implementation Report 14 draft-mynam-grow-diverse-path-impl-01 16 Abstract 18 This document provides an implementation report for Diverse Path as 19 defined in RFC6774. The editor did not verify the accuracy of the 20 information provided by respondents or by any alternative means. The 21 respondents are experts with the implementations they reported on, 22 and their responses are considered authoritative for the 23 implementations for which their responses represent. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 07, 2013. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Implementation Forms . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Support for multiple RRs . . . . . . . . . . . . . . . . 3 68 2.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 4 69 2.3. Deployment Consideration . . . . . . . . . . . . . . . . 4 70 2.4. Usage of Diverse Path . . . . . . . . . . . . . . . . . . 4 71 2.5. Bestpath algorithm . . . . . . . . . . . . . . . . . . . 5 72 2.6. Interoperable Implementations . . . . . . . . . . . . . . 5 73 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 4. Security considerations . . . . . . . . . . . . . . . . . . . 6 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 6.2. Informative References . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 The BGP4 protocol specifies the selection and propagation of a single 84 best path for each prefix. Apart from BGP Add-Paths Proposal , today 85 BGP has no other mechanisms to distribute paths other then best path 86 between its speakers. BGP Divrsepath proposal does not specify any 87 changes to the BGP protocol definition as specificed by BGP Add-Paths 88 proposal. It does not require upgrades to provider edge or core 89 routers nor does it need network wide upgrades. Diverse Path 90 attempts do solve the addpath problem and provision an interim 91 solution to the customers who cannot deploy addpath solution on 92 certain networks. Due to the simple natiure of Diverse Path with 93 simple upgrades and configuration to the Route Reflectors without any 94 configurations on the edge routers, Diverse Path becomes very easy to 95 deploy 96 This document provides an implementation report for Diverse Path as 97 defined in RFC6774 - Distribution of Diverse BGP Paths 99 The editor did not verify the accuracy of the information provided by 100 respondents or by any alternative means. The respondents are experts 101 with the implementations they reported on, and their responses are 102 considered authoritative for the implementations for which their 103 responses represent. 105 2. Implementation Forms 107 Contact and implementation information for person filling out this 108 form: 110 Name: Satish Mynam, Email: mynam@cisco.com, Vendor: Cisco Systems, 111 Inc. Release: IOS 113 Name: Jeff Tantsura, Email: jeff.tantsura@ericsson.com, Vendor: 114 Ericsson, Release: IPOS, SEOS 116 2.1. Support for multiple RRs 118 Does the implementation support Sec.4.[RFC6774] Provision for Multi 119 plane route reflection? 121 Cisco: YES 123 Ericsson: YES 125 Does the implementation provide support for Sec4.1[RFC6774] Co- 126 located best and backup path RRs? 128 Cisco: YES 130 Ericsson: YES 132 Does the implementation provide provision for Sec 4.3.[RFC6774] Multi 133 plane route servers for Internet Exchanges? 135 Cisco: YES 137 Ericsson: NO 139 2.2. Path Selection 141 Does BGP diverse Path implementation follow the procedures for 142 selection of the bestpath outlined in Section 9.1.Decision Process in 143 RFC 4271? 145 Cisco: YES 147 Ericsson: YES 149 2.3. Deployment Consideration 151 Does BGP diverse Path implementation be easily enabled by 152 introduction of a new route reflector, route server plane dedicated 153 to the selection and distribution of Nth best-path? 155 Cisco: YES 157 Ericsson: YES (2nd Best-path) 159 Does BGP diverse Path implementation require any upgrades to the edge 160 /core routers? 162 Cisco: NO 164 Ericsson: NO 166 Can BGP diverse Path implementation be deployed on multiple RR 167 clusters? 169 Cisco: YES 171 Ericsson: YES 173 Does your BGP diverse Path implementation involve major modification 174 to BGP implementations in the entire network? 176 Cisco: NO 178 Ericsson: NO 180 2.4. Usage of Diverse Path 182 Does BGP diverse Path implementation require any modifications to 183 BGP4 protocol? 185 Cisco: NO 186 Ericsson: NO 188 Does it help in the Multi-path load balancing applications for both 189 IBGP and EBGP? 191 Cisco: YES 193 Ericsson: NO 195 Does the implementation support second session from RR to the same 196 RR-client preferably terminated at a different loopback address of 197 the route reflector and provide second bestpath to the RR-client? 199 Cisco: NO 201 Ericsson: YES 203 2.5. Bestpath algorithm 205 Does it add any modifications to the 9.1.Decision Process in RFC 206 4271? Does it skip any steps in the decision process? 208 Cisco: NO. No modifications to the algorithm are done except when 209 RRs are not co-located and have different metric to reach the edge 210 routers a configurable CLI command is provided for the user to 211 control the disabling of the IGP metric check in the Decision Process 212 to select bestpath and backupath 214 Ericsson: NO. No modifications to the algorithm are done except when 215 RRs are not co-located and have different metric to reach the edge 216 routers a configurable CLI command is provided for the user to 217 control the disabling of the IGP metric check in the Decision Process 218 to select bestpath and backupath 220 Does the implementation provide support for disabling IGP metric for 221 bestpath selection on Sec 4.2 [RFC6774] randomly located best and 222 backup path RRs? 224 Cisco: YES 226 Ericsson: YES 228 2.6. Interoperable Implementations 230 List other implementations that you have tested interoperability of 231 Diverse Path 232 Cisco: The implementation should be interoperable with other vendor 233 BGP implementations as no BGP Protocol changes are needed 235 Ericsson: The implementation should be interoperable with other 236 vendor BGP implementations as no BGP Protocol changes are needed 238 3. IANA Considerations 240 This document makes no request of IANA. 242 Note to RFC Editor: this section may be removed on publication as an 243 RFC. 245 4. Security considerations 247 No new security issues are introduced to the BGP protocol by this 248 specification. 250 5. Acknowledgements 252 6. References 254 6.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", 260 RFC 4223, October 2005. 262 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 263 Protocol 4 (BGP-4)", RFC 4271, January 2006. 265 6.2. Informative References 267 [RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K. 268 Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, 269 November 2012. 271 Authors' Addresses 273 Jeff Tantsura, (editor) 274 Ericsson 275 300 Holger Way 276 San Jose, CA 95134 277 US 279 Email: jeff.tantsura@ericsson.com 280 Selma Yilmaz 281 Cisco Systems 282 170 West Tasman Drive 283 San Jose, CA 95134 284 US 286 Email: seyilmaz@cisco.com 288 Keyur Patel 289 Cisco Systems 290 170 West Tasman Drive 291 San Jose, CA 95134 292 US 294 Email: keyupate@cisco.com 296 Satish Mynam 297 Dell Force10 Networks 298 350 Holger Way 299 San Jose, CA 95134 300 US 302 Email: Satish_Mynam@Dell.com 304 Robert Raszuk 305 NTT MCL 307 Email: robert@raszuk.net