Diverse Path Implementation Report
draft-mynam-grow-diverse-path-impl-00

Abstract

This document provides an implementation report for Diverse Path as defined in draft-ietf-grow-diverse-bgp-path-dist-03. 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 September 01, 2011.

Copyright Notice

Copyright (c) 2011 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. Implementation Forms
• 2.1. Support for multiple RRs
• 2.2. Path Selection
• 2.3. Deployment Consideration
• 2.4. Usage of Diverse Path
• 2.5. Bestpath algorithm
• 2.6. Interoperable Implementations
• 3. IANA Considerations
• 4. Security considerations
• 5. Acknowledgements
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

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

This document provides an implementation report for Diverse Path as defined in draft-ietf-grow-diverse-bgp-path-dist-03

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

2.1. Support for multiple RRs

Does the implementation support Sec.4. [draft-ietf-grow-diverse-bgp-path-dist-03] Provision for Multi plane route reflection?

Cisco: YES

Does the implementation provide support for Sec4.1[draft-ietf-grow-diverse-bgp-path-dist-03 ] Co-located best and backup path RRs?

Cisco: YES

Does the implementation provide provision for Sec 4.3. [draft-ietf-grow-diverse-bgp-path-dist-03] Multi plane route servers for Internet Exchanges?

Cisco: YES

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

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

Does BGP diverse Path implementation require any upgrades to the edge/core routers?

Cisco: NO

Can BGP diverse Path implementation be deployed on multiple RR clusters?

Cisco: YES

Does your BGP diverse Path implementation involve major modification to BGP implementations in the entire network?

Cisco: NO

2.4. Usage of Diverse Path

Does BGP diverse Path implementation require any modifications to BGP4 protocol?

Cisco: NO

Does it help in the Multi-path load balancing applications for both IBGP and EBGP?

Cisco: YES

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

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

Does the implementation provide support for disabling IGP metric for bestpath selection on Sec 4.2 [draft-ietf-grow-diverse-bgp-path-dist-03] randomly located best and backup path RRs?

Cisco: YES

2.6. Interoperable Implementations

List other implementations that you have tested interoperability of Diverse Path

Cisco: 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

6.2. Informative References

Authors' Addresses