Network Working Group J. Tantsura, Ed. Internet-Draft Ericsson Intended status: Informational S. Yilmaz Expires: November 07, 2013 K. Patel Cisco Systems S. Mynam Dell Force10 Networks R. Raszuk NTT MCL May 06, 2013 Diverse Path Implementation Report draft-mynam-grow-diverse-path-impl-01 Abstract This document provides an implementation report for Diverse Path as defined in RFC6774. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 07, 2013. Tantsura, et al. Expires November 07, 2013 [Page 1] Internet-Draft draft-mynam-grow-diverse-path-impl-01.txt May 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Implementation Forms . . . . . . . . . . . . . . . . . . . . 3 2.1. Support for multiple RRs . . . . . . . . . . . . . . . . 3 2.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 4 2.3. Deployment Consideration . . . . . . . . . . . . . . . . 4 2.4. Usage of Diverse Path . . . . . . . . . . . . . . . . . . 4 2.5. Bestpath algorithm . . . . . . . . . . . . . . . . . . . 5 2.6. Interoperable Implementations . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. Security considerations . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. Apart from BGP Add-Paths Proposal , today BGP has no other mechanisms to distribute paths other then best path between its speakers. BGP Divrsepath proposal does not specify any changes to the BGP protocol definition as specificed by BGP Add-Paths proposal. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. Diverse Path attempts do solve the addpath problem and provision an interim solution to the customers who cannot deploy addpath solution on certain networks. Due to the simple natiure of Diverse Path with simple upgrades and configuration to the Route Reflectors without any configurations on the edge routers, Diverse Path becomes very easy to deploy Tantsura, et al. Expires November 07, 2013 [Page 2] Internet-Draft draft-mynam-grow-diverse-path-impl-01.txt May 2013 This document provides an implementation report for Diverse Path as defined in RFC6774 - Distribution of Diverse BGP Paths The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. 2. Implementation Forms Contact and implementation information for person filling out this form: Name: Satish Mynam, Email: mynam@cisco.com, Vendor: Cisco Systems, Inc. Release: IOS Name: Jeff Tantsura, Email: jeff.tantsura@ericsson.com, Vendor: Ericsson, Release: IPOS, SEOS 2.1. Support for multiple RRs Does the implementation support Sec.4.[RFC6774] Provision for Multi plane route reflection? Cisco: YES Ericsson: YES Does the implementation provide support for Sec4.1[RFC6774] Co- located best and backup path RRs? Cisco: YES Ericsson: YES Does the implementation provide provision for Sec 4.3.[RFC6774] Multi plane route servers for Internet Exchanges? Cisco: YES Ericsson: NO Tantsura, et al. Expires November 07, 2013 [Page 3] Internet-Draft draft-mynam-grow-diverse-path-impl-01.txt May 2013 2.2. Path Selection Does BGP diverse Path implementation follow the procedures for selection of the bestpath outlined in Section 9.1.Decision Process in RFC 4271? Cisco: YES Ericsson: YES 2.3. Deployment Consideration Does BGP diverse Path implementation be easily enabled by introduction of a new route reflector, route server plane dedicated to the selection and distribution of Nth best-path? Cisco: YES Ericsson: YES (2nd Best-path) Does BGP diverse Path implementation require any upgrades to the edge /core routers? Cisco: NO Ericsson: NO Can BGP diverse Path implementation be deployed on multiple RR clusters? Cisco: YES Ericsson: YES Does your BGP diverse Path implementation involve major modification to BGP implementations in the entire network? Cisco: NO Ericsson: NO 2.4. Usage of Diverse Path Does BGP diverse Path implementation require any modifications to BGP4 protocol? Cisco: NO Tantsura, et al. Expires November 07, 2013 [Page 4] Internet-Draft draft-mynam-grow-diverse-path-impl-01.txt May 2013 Ericsson: NO Does it help in the Multi-path load balancing applications for both IBGP and EBGP? Cisco: YES Ericsson: NO Does the implementation support second session from RR to the same RR-client preferably terminated at a different loopback address of the route reflector and provide second bestpath to the RR-client? Cisco: NO Ericsson: YES 2.5. Bestpath algorithm Does it add any modifications to the 9.1.Decision Process in RFC 4271? Does it skip any steps in the decision process? Cisco: NO. No modifications to the algorithm are done except when RRs are not co-located and have different metric to reach the edge routers a configurable CLI command is provided for the user to control the disabling of the IGP metric check in the Decision Process to select bestpath and backupath Ericsson: NO. No modifications to the algorithm are done except when RRs are not co-located and have different metric to reach the edge routers a configurable CLI command is provided for the user to control the disabling of the IGP metric check in the Decision Process to select bestpath and backupath Does the implementation provide support for disabling IGP metric for bestpath selection on Sec 4.2 [RFC6774] randomly located best and backup path RRs? Cisco: YES Ericsson: YES 2.6. Interoperable Implementations List other implementations that you have tested interoperability of Diverse Path Tantsura, et al. Expires November 07, 2013 [Page 5] Internet-Draft draft-mynam-grow-diverse-path-impl-01.txt May 2013 Cisco: The implementation should be interoperable with other vendor BGP implementations as no BGP Protocol changes are needed Ericsson: The implementation should be interoperable with other vendor BGP implementations as no BGP Protocol changes are needed 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 4. Security considerations No new security issues are introduced to the BGP protocol by this specification. 5. Acknowledgements 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", RFC 4223, October 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 6.2. Informative References [RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K. Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, November 2012. Authors' Addresses Jeff Tantsura, (editor) Ericsson 300 Holger Way San Jose, CA 95134 US Email: jeff.tantsura@ericsson.com Tantsura, et al. Expires November 07, 2013 [Page 6] Internet-Draft draft-mynam-grow-diverse-path-impl-01.txt May 2013 Selma Yilmaz Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: seyilmaz@cisco.com Keyur Patel Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: keyupate@cisco.com Satish Mynam Dell Force10 Networks 350 Holger Way San Jose, CA 95134 US Email: Satish_Mynam@Dell.com Robert Raszuk NTT MCL Email: robert@raszuk.net Tantsura, et al. Expires November 07, 2013 [Page 7]