Internet DRAFT - draft-mynam-grow-diverse-path-impl
draft-mynam-grow-diverse-path-impl
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]
