BGP Bestpath Selection Criteria Enhancement
draft-ietf-idr-bgp-bestpath-selection-criteria-08
IDR Working Group Rajiv Asati
Internet Draft Cisco Systems
Intended status: Standards Track
Expires: April 10, 2018
October 10, 2017
BGP Bestpath Selection Criteria Enhancement
draft-ietf-idr-bgp-bestpath-selection-criteria-08.txt
Abstract
BGP specification [RFC4271] prescribes 'BGP next-hop reachability'
as one of the key 'Route Resolvability Condition' that must be
satisfied before the BGP bestpath candidate selection. This
condition, however, may not be sufficient (as explained in the
Appendix section) and desire further granularity.
This document defines enhances the "Route Resolvability Condition"
to facilitate the next-hop to be resolved in the chosen data plane.
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 April 10, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Asati, Rajiv Expires April 10, 2018 [Page 1]
Internet-Draft BGP Bestpath Selection Criteria Enhanced October 10, 2017
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. Specification Language.........................................3
3. Route Resolvability Condition - Modification...................3
4. Conclusions....................................................4
5. Security Considerations........................................4
6. IANA Considerations............................................5
7. Acknowledgments................................................5
8. Appendix.......................................................5
9. References.....................................................7
Author's Addresses................................................8
1. Introduction
As per BGP specification [RFC4271], when a router receives a BGP
path, BGP must qualify it as the valid candidate prior to the BGP
bestpath selection using the 'Route Resolvability Condition'
(section#9.1.2.1 of RFC4271]. After the path gets qualified as the
bestpath candidate, it becomes eligible to be the bestpath, and may
get advertised out to the neigbhor(s), if it became the bestpath.
However, in BGP networks that utilize data plane protocol other than
IP, such as MPLS [RFC3031] etc. to forward the received traffic
towards the next-hop, the above qualification condition may not be
sufficient. In fact, this may expose the BGP networks to experience
traffic blackholing i.e. traffic loss, due to malfunctioning of the
chosen data plane protocol to the next-hop. This is explained
further in the Appendix section.
This document defines further granularity to the "Route
Resolvability Condition" by (a) resolving the BGP next-hop
Asati, Rajiv Expires April 10, 2018 [Page 2]
Internet-Draft BGP Bestpath Selection Criteria Enhanced October 10, 2017
reachability in the forwarding database of a particular data plane
protocol, and (b) optionally including the BGP next-hop "path
availability" check.
The goal is to enable BGP to select the bestpaths based on whether
or not the corresponding nexthop can be resolved in the valid data
plane.
2. Specification Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Show full document text