draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt   draft-ietf-idr-bgp-bestpath-selection-criteria-02.txt 
IDR Working Group Rajiv Asati IDR Working Group Rajiv Asati
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Informational Intended status: Informational
Expires: Jan 2010 Expires: Nov 2011
August 28, 2009 May 5, 2011
BGP Bestpath Selection Criteria BGP Bestpath Selection Criteria
draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt draft-ietf-idr-bgp-bestpath-selection-criteria-02.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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. This document may contain material the provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on Feb 28, 2010. This Internet-Draft will expire on October 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Abstract document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as warranty as described in the BSD License.
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.
Table of Contents Table of Contents
1. Introduction...................................................3 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........................................5 5. Security Considerations........................................5
6. IANA Considerations............................................5 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
skipping to change at page 3, line 19 skipping to change at page 3, line 6
bestpath selection using the 'Route Resolvability Condition' bestpath selection using the 'Route Resolvability Condition'
(section#9.1.2.1 of RFC4271]. After the path gets qualified as the (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 bestpath candidate, it becomes eligible to be the bestpath, and may
get advertised out to the neigbhor(s), if it became the bestpath. get advertised out to the neigbhor(s), if it became the bestpath.
However, in BGP networks that utilize data plane protocol other than However, in BGP networks that utilize data plane protocol other than
IP, such as MPLS [RFC3031] etc. to forward the received traffic IP, such as MPLS [RFC3031] etc. to forward the received traffic
towards the next-hop, the above qualification condition may not be towards the next-hop, the above qualification condition may not be
sufficient. In fact, this may expose the BGP networks to experience sufficient. In fact, this may expose the BGP networks to experience
traffic blackholing i.e. traffic loss, due to malfunctioning of the traffic blackholing i.e. traffic loss, due to malfunctioning of the
chosen data plane protocol to the next-hop. This is explained further chosen data plane protocol to the next-hop. This is explained
in the Appendix section. further in the Appendix section.
This document defines further granularity to the "Route Resolvability This document defines further granularity to the "Route
Condition" by (a) resolving the BGP next-hop reachability in the Resolvability Condition" by (a) resolving the BGP next-hop
forwarding database of a particular data plane protocol, and (b) reachability in the forwarding database of a particular data plane
optionally including the BGP next-hop "path availability" check. 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 The goal is to enable BGP to select the bestpaths based on whether
not the corresponding nexthop can be resolved in the valid data or not the corresponding nexthop can be resolved in the valid data
plane. plane.
2. Specification Language 2. Specification Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Route Resolvability Condition - Modification 3. Route Resolvability Condition - Modification
skipping to change at page 4, line 31 skipping to change at page 4, line 21
This check is about confirming the availability of the valid This check is about confirming the availability of the valid
forwarding entry for the next-hop in the forwarding database of the forwarding entry for the next-hop in the forwarding database of the
chosen data plane protocol. chosen data plane protocol.
2) The 'path availability' check for the BGP next-hop MAY be 2) The 'path availability' check for the BGP next-hop MAY be
performed. This criterion checks for the functional data plane performed. This criterion checks for the functional data plane
path to the next-hop in a particular data plane protocol. path to the next-hop in a particular data plane protocol.
The path availability check may be performed by any of the OAM data- The path availability check may be performed by any of the OAM data-
plane liveness mechanisms associated with the data plane that is used plane liveness mechanisms associated with the data plane that is
to reach the Next Hop. The data plane protocol for this criterion used to reach the Next Hop. The data plane protocol for this
MUST be the same as the one selected by the previous criterion (#1). criterion MUST be the same as the one selected by the previous
criterion (#1).
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.
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 a granularity to help the BGP speaker to either continue to advertise
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.
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.
skipping to change at page 5, line 37 skipping to change at page 5, line 31
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
independent of whether the router has a functional forwarding path to independent of whether the router has a functional forwarding path
the next-hop. This may cause the forwarded traffic to be dropped to the next-hop. This may cause the forwarded traffic to be dropped
inside the IP network. inside the IP network.
In MPLS or MPLS VPN networks [RFC4364], the same problem is observed In MPLS or MPLS VPN networks [RFC4364], the same problem is observed
if the functional MPLS LSP to the next-hop is not available (due to if the functional MPLS LSP to the next-hop is not available (due to
the forwarding path error on any node along the path to the next- the forwarding path error on any node along the path to the next-
hop). hop).
The following MPLS/VPN topology clarifies the problem - The following MPLS/VPN topology clarifies the problem -
<-eBGP/IGP-> <-------MP-BGP------> <-eBGP/IGP-> <-eBGP/IGP-> <-------MP-BGP------> <-eBGP/IGP->
skipping to change at page 6, line 24 skipping to change at page 6, line 24
In the network illustrated in Figure 1, the PE1 to PE2 LSP may be In the network illustrated in Figure 1, the PE1 to PE2 LSP may be
non-functional due to any reason such as corrupted MPLS Forwarding non-functional due to any reason such as corrupted MPLS Forwarding
Table entry, or the missing MPLS Forwarding table entry, or LDP Table entry, or the missing MPLS Forwarding table entry, or LDP
binding defect, or down LDP session between the P routers (with binding defect, or down LDP session between the P routers (with
independent label distribution control) etc. In such a situation, it independent label distribution control) etc. In such a situation, it
is clear that the CE1->CE2 traffic inserted into the MPLS network by is clear that the CE1->CE2 traffic inserted into the MPLS network by
PE1 will get dropped inside the MPLS network. PE1 will get dropped inside the MPLS network.
It is undesirable to have PE1 continue to convey to the CE1 router It is undesirable to have PE1 continue to convey to the CE1 router
that PE1 (and the MPLS network) is still the next-hop for the remote that PE1 (and the MPLS network) is still the next-hop for the remote
VPN reachability, without being sure of the corresponding LSP health. VPN reachability, without being sure of the corresponding LSP
health.
8.1.1. Multi-Homed VPN Site 8.1.1. Multi-Homed VPN Site
If the remote VPN site is dual-homed to both PE2 and PE3, then PE1 If the remote VPN site is dual-homed to both PE2 and PE3, then PE1
may learn two VPNv4 paths to the prefix a.b.c.d. via PE2 and PE3 may learn two VPNv4 paths to the prefix a.b.c.d. via PE2 and PE3
routers, as shown below in Figure 2. PE1 may select the bestpath for routers, as shown below in Figure 2. PE1 may select the bestpath for
the prefix a.b.c.d via PE2 (say, for which the PE1->PE2 LSP is mal- the prefix a.b.c.d via PE2 (say, for which the PE1->PE2 LSP is mal-
functioning) and advertise that bestpath to CE1 in the context of functioning) and advertise that bestpath to CE1 in the context of
figure 2. figure 2.
<------MP-BGP------> <------MP-BGP------>
CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~
\ / ^ \ / ^
\~~~~~~~~~~PE3~~~~~~~/ ^ \~~~~~~~~~~PE3~~~~~~~/ ^
^ ^
a.b.c.d a.b.c.d
Figure 2 MPLS VPN Network - CE2 Dual-Homing Figure 2 MPLS VPN Network - CE2 Dual-Homing
This causes CE1 to likely send the traffic destined to prefix a.b.c.d This causes CE1 to likely send the traffic destined to prefix
to the PE1 router, which forwards the traffic over the malfunctioning a.b.c.d to the PE1 router, which forwards the traffic over the
LSP to PE2. It is clear that this MPLS encapsulated VPN traffic ends malfunctioning LSP to PE2. It is clear that this MPLS encapsulated
up getting dropped or blackholed somewhere inside the MPLS network. VPN traffic ends up getting dropped or blackholed somewhere inside
the MPLS network.
It is desirable to force PE1 to select an alternate bestpath via that It is desirable to force PE1 to select an alternate bestpath via
next-hop (such as PE3), whose LSP is correctly functioning. that next-hop (such as PE3), whose LSP is correctly functioning.
8.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity 8.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity
The local VPN site may have a backup/dial-up link available at the CE The local VPN site may have a backup/dial-up link available at the
router, but the backup link will not even be activated as long as the CE router, but the backup link will not even be activated as long as
CE's routing table continues to point to the PE router as the next- the CE's routing table continues to point to the PE router as the
hop (over the MPLS/VPN network). next-hop (over the MPLS/VPN network).
<------MP-BGP------> <------MP-BGP------>
CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~
\ / ^ \ / ^
\~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/ ^ \~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/ ^
^ ^
a.b.c.d a.b.c.d
Figure 3 MPLS VPN Network - CE1-CE2 Backup connection Figure 3 MPLS VPN Network - CE1-CE2 Backup connection
Unless PE2 withdraws the route via the routing protocol used on the Unless PE2 withdraws the route via the routing protocol used on the
PE-CE link, CE1 will not be able to activate the backup link (barring PE-CE link, CE1 will not be able to activate the backup link
any tracking functionality) to the remote VPN site. (barring any tracking functionality) to the remote VPN site.
In summary, if PE1 could appropriately qualify the BGP VPNv4 In summary, if PE1 could appropriately qualify the BGP VPNv4
bestpath, then the VPN traffic outage could likely be avoided. Even bestpath, then the VPN traffic outage could likely be avoided. Even
if the VPN site was not multi-homed, it is desirable to force PE1 to if the VPN site was not multi-homed, it is desirable to force PE1 to
withdraw the path from CE1 to improve the CE-to-CE convergence. This withdraw the path from CE1 to improve the CE-to-CE convergence. This
document proposes a mechanism to achieve the optimal BGP behavior at document proposes a mechanism to achieve the optimal BGP behavior at
PE. PE.
8.1.3. 6PE or 6VPE 8.1.3. 6PE or 6VPE
This problem is very much applicable to the MPLS network that is This problem is very much applicable to the MPLS network that is
providing either 6PE [RFC4978] or 6VPE [] service to transport IPv6 providing either 6PE [RFC4978] or 6VPE [RFC4659] service to
packets over the MPLS network. transport IPv6 packets over the MPLS network.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC4364, February 2006. Networks (VPNs)", RFC4364, February 2006.
skipping to change at page 8, line 43 skipping to change at page 8, line 32
Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006
9.2. Informative References 9.2. Informative References
[RFC3031] Rosen, et al., "Multiprotocol Label Switching [RFC3031] Rosen, et al., "Multiprotocol Label Switching
Architecture", RFC3031, Jan 2001. Architecture", RFC3031, Jan 2001.
[RFC5512] Rosen, E., Mohapatra, P., "BGP Encapsulation SAFI and BGP [RFC5512] Rosen, E., Mohapatra, P., "BGP Encapsulation SAFI and BGP
Tunnel Encapsulation Attribute", RFC5512, April 2009. Tunnel Encapsulation Attribute", RFC5512, April 2009.
[RFC4023] Rosen, et al., "Encapsulating MPLS in IP or Generic Routing [RFC4023] Rosen, et al., "Encapsulating MPLS in IP or Generic
Encapsulation", RFC4023, March 2005. Routing Encapsulation", RFC4023, March 2005.
[RFC4817] Townsley, et al., "Encapsulation of MPLS over Layer 2 [RFC4817] Townsley, et al., "Encapsulation of MPLS over Layer 2
Tunneling Protocol Version 3", RFC4817, Nov 2006. Tunneling Protocol Version 3", RFC4817, Nov 2006.
[RFC4978] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS [RFC4978] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS
Using IPv6 Provider Edge Routers", RFC4978, Feb 2007. Using IPv6 Provider Edge Routers", RFC4978, Feb 2007.
[RFC4659] De Clercq, et al., "BGP-MPLS IP VPN Extension for IPv6 [RFC4659] De Clercq, et al., "BGP-MPLS IP VPN Extension for IPv6
VPN", RFC4659, Sep 2006. VPN", RFC4659, Sep 2006.
 End of changes. 21 change blocks. 
69 lines changed or deleted 67 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/