draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt   draft-ietf-idr-bgp-bestpath-selection-criteria-05.txt 
IDR Working Group Rajiv Asati IDR Working Group Rajiv Asati
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Standards Track Intended status: Standards Track
Expires: Jan 2012 Expires: February 23, 2012
August 16, 2011 August 23, 2011
BGP Bestpath Selection Criteria Enhancement BGP Bestpath Selection Criteria Enhancement
draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt draft-ietf-idr-bgp-bestpath-selection-criteria-05.txt
Abstract Abstract
BGP specification [RFC4271] prescribes 'BGP next-hop reachability' BGP specification [RFC4271] prescribes 'BGP next-hop reachability'
as one of the key 'Route Resolvability Condition' that must be as one of the key 'Route Resolvability Condition' that must be
satisfied before the BGP bestpath candidate selection. This satisfied before the BGP bestpath candidate selection. This
condition, however, may not be sufficient (as explained in the condition, however, may not be sufficient (as explained in the
Appendix section) and desire further granularity. Appendix section) and desire further granularity.
This document defines enhances the "Route Resolvability Condition" This document defines enhances the "Route Resolvability Condition"
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2012. This Internet-Draft will expire on February 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Specification Language.........................................3 2. Specification Language.........................................3
3. Route Resolvability Condition - Modification...................3 3. Route Resolvability Condition - Modification...................3
4. Conclusions....................................................4 4. Conclusions....................................................4
5. Security Considerations........................................4 5. Security Considerations........................................5
6. IANA Considerations............................................4 6. IANA Considerations............................................5
7. Acknowledgments................................................5 7. Acknowledgments................................................5
8. Appendix.......................................................5 8. Appendix.......................................................5
9. References.....................................................8 9. References.....................................................8
Author's Addresses................................................9 Author's Addresses................................................9
1. Introduction 1. Introduction
As per BGP specification [RFC4271], when a router receives a BGP As per BGP specification [RFC4271], when a router receives a BGP
path, BGP must qualify it as the valid candidate prior to the BGP path, BGP must qualify it as the valid candidate prior to the BGP
bestpath selection using the 'Route Resolvability Condition' bestpath selection using the 'Route Resolvability Condition'
skipping to change at page 4, line 28 skipping to change at page 4, line 28
The mechanism(s) to perform the "path availability" check and the The mechanism(s) to perform the "path availability" check and the
selection of particular data plane are a matter of a policy and selection of particular data plane are a matter of a policy and
outside the scope of this document. outside the scope of this document.
For example, if a BGP VPNv4 path wants to use the MPLS as the For example, if a BGP VPNv4 path wants to use the MPLS as the
data plane protocol to the next-hop, then MPLS path data plane protocol to the next-hop, then MPLS path
availability to the next-hop should be evaluated i.e. liveness availability to the next-hop should be evaluated i.e. liveness
of MPLS LSP to the next-hop should be validated. of MPLS LSP to the next-hop should be validated.
This check is about confirming the availability of functioning path
to the next-hop. Note that it is not necessary to trigger the data-
plane liveness mechanism for a given next-hop as a consequence of
this check, though it may be an option. Another option is to do it a
priori. The selection of a particular option is deemed deployment
specific and outside the scope of this document.
4. Conclusions 4. Conclusions
Both amendments discussed in section 2 provide further clarity and Both amendments discussed in section 2 provide further clarity and
granularity to help the BGP speaker to either continue to advertise granularity to help the BGP speaker to either continue to advertise
a BGP path's reachability or withdraw the BGP path's reachability, a BGP path's reachability or withdraw the BGP path's reachability,
based on the consideration for the path's next-hop reachability based on the consideration for the path's next-hop reachability
and/or availability in a particular data plane. and/or availability in a particular data plane.
It is not expected that the proposed amendments would negatively
impact BGP convergence, barring any implementation specifics.
The intention of this document is to help operators to build BGP The intention of this document is to help operators to build BGP
networks that can avoid self-blackholing. networks that can avoid self-blackholing.
5. Security Considerations 5. Security Considerations
This draft doesn't impose any additional security constraints. This draft doesn't impose any additional security constraints.
6. IANA Considerations 6. IANA Considerations
None. None.
7. Acknowledgments 7. Acknowledgments
Yakov Rekhter provided critical suggestions and feedback to improve Yakov Rekhter provided critical suggestions and feedback to improve
this document. Thanks to John Scudder and Chandrashekhar Appanna for this document. Thanks to John Scudder and Chandrashekhar Appanna for
contributing to the discussions that formed the basis of this contributing to the discussions that formed the basis of this
document. Thanks to Ilya Varlashkin and Michael Benjamin, who made document. Thanks to Ilya Varlashkin and Michael Benjamin, who made
the case to revive this document and provided useful feedback. Also the case to revive this document and provided useful feedback. Also
thanks to Keyur Patel for his feedback. thanks to Keyur Patel, Robert Raszuk and Samita Chakrabarti.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
8. Appendix 8. Appendix
8.1. Problem Applicability 8.1. Problem Applicability
In IP networks using BGP, a router would continue to attract traffic In IP networks using BGP, a router would continue to attract traffic
by advertising the BGP prefix reachability to neighbor(s) as long as by advertising the BGP prefix reachability to neighbor(s) as long as
the router had a route to the next-hop in its routing table, but the router had a route to the next-hop in its routing table, but
 End of changes. 7 change blocks. 
7 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/