Network Working Group Rajiv Asati Internet Draft Cisco Systems Intended status: Informational Expires: August 2007 Raymond Zhang BT Tom Nadeau Cisco Systems Azhar Sayeed Cisco Systems February 23, 2007 BGP/MPLS Traffic Blackhole Avoidance draft-asati-bgp-mpls-blackhole-avoidance-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on Fail 23, 2007. Copyright Notice Asati, et al. Expires August 23, 2007 [Page 1] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 Copyright (C) The IETF Trust (2007). Abstract In any BGP based MPLS network such as MPLS VPN [RFC4364], an ingress PE router would continue to attract traffic from the CE router by advertising the prefix reachability, even though the Label Switched Path (LSP) from the ingress PE router to the egress PE router may be broken. This causes the VPN traffic to be dropped inside the MPLS VPN network. This document proposes a framework to make BGP consider the MPLS path availability to the "NEXT_HOP" (i.e. egress PE router) during the BGP bestpath candidate selection process. This document also defines a local database for storing the MPLS path health information for one or more IP prefixes and its interaction with BGP. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. Table of Contents 1. Introduction...................................................3 2. Problem Details................................................3 2.1. VPN Deployment Scenarios..................................4 2.1.1. Multi-Homed VPN Site.................................4 2.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity................................................5 3. Proposal.......................................................5 3.1. BGP VPNv4 Path Qualification Changes......................6 3.1.1. IP reachability and MPLS reachability Checks.........7 3.1.2. 2547oIP based BGP VPNv4 paths........................8 3.2. LSP Health Database (LHD).................................9 3.3. BGP and LHD Interaction..................................11 4. IGP and LHD...................................................13 5. Applicability.................................................13 6. Security Considerations.......................................13 7. IANA Considerations...........................................13 Asati, et al. Expires August 23, 2007 [Page 2] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 8. Conclusions...................................................13 9. Acknowledgments...............................................13 10. References...................................................14 10.1. Normative References....................................14 10.2. Informative References..................................14 Author's Addresses...............................................15 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................16 1. Introduction In the current MPLS VPN architecture [RFC4364], a PE router learns the VPNv4 routes from the remote PE routers either over a PE-PE MP- iBGP session or via a PE-RR MP-iBGP session. The remote PE router(s) accepts the VPNv4 routes with the matching import route-targets and advertise them to the CE router(s). The CE router, in turn, is likely to choose the PE router as the next hop to communicate with the relevant remote VPNv4 destinations. The existing [RFC4364] architecture assumes the ingress PE router to have a working label switched path (LSP) to the egress PE router that advertised the VPNv4 route. 2. Problem Details The assumption that the ingress PE router always has a working LSP to the egress PE router that advertised the VPNv4 route, may result in the VPN traffic to be dropped or blackholed inside an MPLS VPN network during an LSP failure event. This is because an ingress PE router could qualify a VPNv4 route (learned via an MP-iBGP session) as a valid route, even though the corresponding next hop is no longer MPLS reachable. <-eBGP/IGP-> <-------MP-BGP------> <-eBGP/IGP-> CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ ^ ======PE1-PE2 LSP==> ^ ^ a.b.c.d Figure 1 MPLS VPN Network Asati, et al. Expires August 23, 2007 [Page 3] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 In the network illustrated in Figure 1, the PE1 to PE2 LSP may be non-functional due to any reason such as down LDP session between the P routers, or the corrupted MPLS Forwarding Table entry, or the missing MPLS Forwarding table entry, or LDP binding defect etc. In such a situation, it is clear that the CE1->CE2 traffic inserted into the MPLS network by PE1 will get dropped inside the MPLS network. 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 VPN reachability, without being sure of the corresponding LSP health. 2.1. VPN Deployment Scenarios It is important to understand the downside of the current framework's limitation using the following two deployment scenarios - 2.1.1. Multi-Homed VPN Site 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 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- functioning) and advertise that bestpath to CE1 in the context of figure 2. <------MP-BGP------> CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ \ / ^ \~~~~~~~~~~PE3~~~~~~~/ ^ ^ a.b.c.d Figure 2 MPLS VPN Network - CE2 Dual-Homing This causes CE1 to likely send the traffic destined to prefix a.b.c.d to the PE1 router, which forwards the traffic over the malfunctioning LSP to PE2. It is clear that this MPLS encapsulated VPN traffic ends up getting dropped or blackholed somewhere inside the MPLS network. Asati, et al. Expires August 23, 2007 [Page 4] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 It is desirable to force PE1 to select an alternate bestpath via that next-hop (such as PE3), whose LSP is correctly functioning. 2.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 router, but the backup link will not even be activated as long as the CE's routing table continues to point to the PE router as the next- hop (over the MPLS/VPN network). <------MP-BGP------> CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ \ / ^ \~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/ ^ ^ a.b.c.d Figure 3 MPLS VPN Network - CE1-CE2 Backup connection 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 any tracking functionality) to the remote VPN site. In summary, if PE1 could appropriately qualify the BGP VPNv4 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 withdraw the path from CE1 to improve the CE-to-CE convergence. This document proposes a mechanism to achieve the optimal BGP behavior at PE. 3. Proposal The crux of the problem is that the BGP VPNv4 path selection is independent of whether the NEXT_HOP is MPLS reachable or not. This draft proposes a mechanism to enable BGP to poll whether there is a valid "MPLS path" to the NEXT_HOP of the VPNv4 path, before qualifying that VPNv4 path as the bestpath candidate. This mechanism Asati, et al. Expires August 23, 2007 [Page 5] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 comprises of the following three building blocks that are later explained in detail in the subsequent sections. 1. BGP VPNv4 path qualification changes: . Qualifies the VPNv4 path as the bestpath candidate only if its NEXT_HOP is MPLS reachable by polling the LSP Health Database. 2. LSP Health Database (LHD): . Maintains the information regarding whether a NEXT_HOP is MPLS reachable or not. 3. BGP & LHD Interaction: . Specifies the way BGP and LHD interacts with each other. The proposal helps the ingress PE to either continue to advertise the BGP VPNv4 path's reachability to the CE router by selecting an alternative VPNv4 bestpath, or withdraw the BGP VPNv4 path's reachability from the CE router, during the relevant LSP failure event. 3.1. BGP VPNv4 Path Qualification Changes As per BGP specification [RFC4271], when a PE router receives a BGP path such as VPNv4 path, BGP qualifies it as the valid candidate for the BGP bestpath using the "Route Resolvability Condition" (Please see section#9.1.2.1 of RFC4271]. Once the path has been qualified as the bestpath candidate, then it gets subjected to the BGP bestpath calculation, which will select the bestpath out of all "bestpath candidates". The BGP path qualification check-list is highlighted below - 1) NEXT_HOP must be IP reachable 2) ... The first check (above) requires the NEXT_HOP of the BGP path to be IP reachable. To determine this reachability, BGP checks the global routing table to validate whether the routing table has a specific or less-specific or default route to the NEXT_HOP. This mechanism is Asati, et al. Expires August 23, 2007 [Page 6] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 also referred to as the "NEXT_HOP Validation". The "NEXT_HOP validation" is done not only for the first time when the BGP (VPNv4) path is first received, but also periodically. The first building block of the proposal is to add another criterion to the "BGP bestpath candidate qualification". The new criterion checks for 'MPLS reachability' to the NEXT_HOP of the BGP path such as VPNv4 path. This means that the NEXT_HOP of the VPNv4 path must be reachable over an MPLS Label Switched Path (LSP). It is desirable to apply this criterion to MPLS only path, as explained in Section 3.1.2. Hence, with the proposed addition, the path qualification check-list now expands to - 1) NEXT_HOP must be IP reachable + 2) NEXT_HOP much be MPLS reachable 3) ... With the above checks in place, if the NEXT_HOP of a VPNv4 path is not IP reachable, then the path will get marked with the "NEXT_HOP IP Unreachable". However, if the NEXT_HOP is IP reachable, but not MPLS reachable, then the BGP VPNv4 path will get marked with the "NEXT_HOP MPLS Unreachable". As a result, the BGP VPNv4 path will get disqualified from becoming the bestpath candidate and will not be considered during the bestpath calculation unless the NEXT_HOP becomes MPLS reachable again. The 'MPLS reachability' to a NEXT_HOP is determined by retrieving the NEXT_HOP specific information from the LSP Health Database (LHD), which is described in section 3.2. The machinery involving BGP and LHD interaction is explained in section 3.3. 3.1.1. IP reachability and MPLS reachability Checks The BGP path qualification (involving the NEXT_HOP reachability) is performed not only when the path is received for the first time, but also later on using either a timer-driven model or event-driven model or both. This machinery is not modified by the change proposed in Asati, et al. Expires August 23, 2007 [Page 7] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 section 3.1. Specifically, the proposal expands the NEXT_HOP reachability check to include checking both: (1) Routing table aka RIB for the IP reachability, and (2) LSP Health Database aka LHD for the MPLS reachability. It is important to note that the LHD check#2 doesn't replace the RIB check#1, but rather complements it. This document doesn't suggest any changes to check#1 whatsoever and assumes that the check#1 will always be performed. Check#2, on the other hand, SHOULD be performed only when appropriate as clarified in section 3.1.2. One benefit of performing both checks, when appropriate as clarified in section 3.1.2, is in the area of troubleshooting, since it will be clear whether the BGP NEXT_HOP is "IP Unreachable" or "MPLS Unreachable". 3.1.2. 2547oIP based BGP VPNv4 paths 2547oIP technology such as 2547oGRE [RFC4023], 2547oL2TPv3 [RFC3931] etc. doesn't require the usage of the MPLS transport between ingress PE router and egress PE router, hence, it is not desirable to perform the proposed 'MPLS reachability' NEXT_HOP check (check#2) during the BGP VPNv4 path qualification for such BGP paths that utilize IP transport. In the simplest form, the above could be achieved by providing a user configurable parameter to enable or disable the check#2 on the router. However, such approach may not work in the deployment involving both 2547oMPLS and 2547oIP BGP VPNv4 paths on the same PE router. Two scenarios in which such deployment may be apparent are (a) the network migration from MPLS to IP or vice versa, (b) the part of network inability to do MPLS. This section explains a method by which BGP can decide whether to perform the 'MPLS reachability' check (check#2) for a given BGP path. In this method, the BGP VPNv4 path is flagged (in the relevant BGP data structure) to denote whether BGP VPNv4 path should be subjected to the "'MPLS reachability' to the NEXT_HOP check" during the BGP path qualification. The flag can be updated based on whether the NEXT_HOP information is also conveyed via a separate discovery Asati, et al. Expires August 23, 2007 [Page 8] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 mechanism such as a separate BGP AFI/SAFI as defined by existing proposals such as [TUN-SAFI], [BGP-TUN], and forthcoming proposals*. If the flag is set to one, then the BGP VPNv4 path is considered to belong to 2547oIP, hence, 'MPLS reachability' check is skipped for the NEXT_HOP(s) of such BGP VPNv4 path(s). If the flag value is zero, the BGP VPNv4 path is considered to belong to 2547oMPLS, hence, 'MPLS reachability' NEXT_HOP check is performed for the NEXT_HOP(s) of such BGP VPNv4 path(s). This method is advantageous since it appropriately takes care of the deployment scenario in which both 2547oMPLS and 2547oIP based VPNv4 paths may exist on the same PE router. (* Please note that the forthcoming proposal(s) may let a BGP speaker convey the choice of encapsulation such as MPLS, GRE, L2TPv3 etc. for a given BGP VPNv4 prefix to another BGP speaker. Such proposals are likely to ease the mean of updating the flag discussed here.) 3.2. LSP Health Database (LHD) As explained in section 3 and 3.1 earlier, BGP will now be required to check for the MPLS reachability to the NEXT_HOP of the BGP VPNv4 path. This means that BGP must somehow obtain the information about NEXT_HOP's MPLS reachability, which is really a forwarding plane element. Since MPLS reachability relies on the forwarding plane, it is optimal to build a database that would keep the information about whether a NEXT_HOP is reachable over an MPLS LSP or not. This database is referred to as LSP Health Database (LHD). BGP would use the information from LHD to perform its "NEXT_HOP reachability" check for MPLS reachability. BGP and LHD interaction could be either timer-driven or event-driven depending upon the implementation, though the document may favor the event-driven interaction for faster convergence. Asati, et al. Expires August 23, 2007 [Page 9] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 How the LHD is populated is outside the scope of this document and will be covered in a separate document since it may be utilized by other application beyond BGP. In short, the LHD could be populated by any 'LSP-health-probe' mechanism such as LSP pings [RFC4389] or BFD LSP [MPLS-BFD] or so forth, to verify whether the LSP to the NEXT_HOP is established or broken. Although the document expects BGP at an edge router such as PE to utilize the LHD, any other application at any router could utilize the LHD. Three questions become apparent when BGP at PE router needs to utilize the information from the LSP Health Database (LHD) - 1. How would the LHD determine the list of BGP NEXT_HOP(s) that need MPLS reachability check? 2. How frequently should the PE router check the LSP Health for each NEXT_HOP? 3. What actions should BGP take when an LSP starts malfunctioning as recorded in the LHD? There are at least two ways to figure out the answer to Q1. Please see the next section 3.3 "BGP and LHD interaction" for the detailed answer. For now, let's assume that LHD has the list of NEXT_HOPs i.e. IP addresses to monitor the LSP health for. Equipped with the list of NEXT_HOPs, the PE router utilizes the 'LSP- health-probe' such as LSP ping, BFD etc. for each NEXT_HOP to validate the LSP health and record it in the LHD. A simplistic view of LHD is shown below - LSP Health Database Sample:: ---------------------------------- NEXT_HOP Prefix | LSP Established ---------------------------------- 192.0.2.11/32 | Yes 192.0.2.12/32 | Yes 192.0.2.13/32 | Yes 192.0.2.14/32 | No ---------------------------------- Figure 4 LSP Health Database - Simplistic View Asati, et al. Expires August 23, 2007 [Page 10] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 Although Q2 is considered specific to the LHD and beyond the scope of this document, it is likely that the PE router may employ either a timer-driven model or event-driven model to update the LHD entries. The frequency of updating the LHD can also be dictated by a user configurable parameter. The frequency should not affect the BGP-LHD interaction machinery. About Q3, if one or more LSP Health Database (LHD) entries are declared or updated to be broken (shown via "No" in the above simplistic LHD view), then BGP may be notified about it depending on the timer-driven or event-driven model in place. As soon as BGP becomes aware of it, BGP may perform the bestpath calculation i.e. 'BGP VPNv4 path qualification' to explore the alternative bestpaths as discussed in section 3.1. Please see more details about this in next section 3.3. 3.3. BGP and LHD Interaction At the high level, LSP Health Database (LHD) maintains the LSP health information for one or more addresses that BGP considers as the NEXT_HOPs. BGP utilizes the information from the LHD to declare the 'MPLS reachability' for a NEXT_HOP during the BGP VPNv4 path qualification. LHD is constructed and populated using mechanisms that are beyond the scope of this document and will be covered in a different document. If the LHD entry shows the LSP for a NEXT_HOP to be "established", then BGP will declare the 'MPLS reachability' to the NEXT_HOP check to have passed and rest of the BGP bestpath calculation may continue as usual. If the LHD shows the LSP for a NEXT_HOP to be not established, then BGP will declare the NEXT_HOP 'MPLS reachability' to have failed and will mark the dependent BGP VPNv4 paths as 'NEXT_HOP MPLS Unreachable'. This will result in such BGP VPNv4 paths be disqualified from becoming the bestpath candidate, and subsequently, PE could update the CE neighbors through one of the following two actions - Assuming the presence of alternative BGP VPNv4 path, PE could select a new bestpath, and advertise it to the CE neighbors. Asati, et al. Expires August 23, 2007 [Page 11] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 Assuming no other alternative BGP VPNv4 path, PE will withdraw the VPNv4 path(s) from the CE neighbors (independent of the PE-CE routing protocol). It is obvious that BGP will have to interact with LHD for each of the NEXT_HOPs of the BGP VPNv4 paths. The following logical question then becomes apparent - How does the router determine which LSPs i.e. NEXT_HOPs should be validated within the LHD ? The document discusses the following two approaches to help LHD obtain the list of NEXT_HOPs - 4. The simplest way is to have the router issue 'LSP-health-probe' for all the host routes since all the NEXT_HOPs are almost always available as the host routes i.e. /32 routes in the routing table. However, every host route is not expected to be the NEXT_HOP, hence, this approach is NOT optimal or accurate since LSP health would be measure for unwanted host routes for no benefits. Moreover, there might be a few fake host routes i.e. /32 routes (including PPP generated /32 routes) that are not really the NEXT_HOPs. 5. The optimal approach is to have the LHD rely on the BGP to provide the list of NEXT_HOPs. BGP should already have a list of the BGP NEXT_HOPs to use it to perform the IP rechability checks. It is logical and appropriate to have LHD perform the LSP Health checks for the NEXT_HOPs specified in this list. Additionally, the list must specify whether LHD should consider all or a subset of the list (since one or more NEXT_HOP may not require MPLS reachability check; This may also depend on the AFI/SAFI of the BGP route). Such inclusion may help to return an appropriate diagnostic code in the MPLS OAM messages such as MPLS ping etc. Although BGP bestpath calculation and LHD check are independent of each other, one may trigger the other i.e. the BGP bestpath calculation may trigger the LHD check for one or more LHD entries, as well as an LHD entry update may trigger the BGP bestpath calculation for the BGP prefixes learned from the NEXT_HOP pertaining to the LHD entry. In the case of LHD entry update providing the trigger to perform the BGP bestpath calculation it is desirable to perform the BGP bestpath calculation only for those BGP prefixes whose NEXT_HOP got updated in the LHD to attain an optimal behavior. LHD will also have to keep up with the changes in the NEXT_HOP list. In other words, if the PE router learns one or more VPNv4 prefix with Asati, et al. Expires August 23, 2007 [Page 12] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 the new NEXT_HOP (this could happen when a new PE router is added to the network), then the BGP will update the NEXT_HOP list, which then should be provided to LHD for further processing. In summary, BGP utilizes the information from the LHD to declare the 'MPLS reachability' to a NEXT_HOP during the BGP VPNv4 path qualification. Although BGP bestpath calculation and LHD check are independent of each other, one may trigger the other. 4. IGP and LHD This proposal requires neither any changes in the IGP, nor any interaction between IGP and LHD. 5. Applicability This proposal, although targeted to VPN prefix, can very well be extended to any BGP prefix whose NEXT_HOP utilizes MPLS transport. Few examples are VPNv6, labeled BGP IPv4 prefix [RFC3107], labeled BGP IPv6 prefix etc. 6. Security Considerations This draft doesn't impose any additional security constraints. 7. IANA Considerations None. 8. Conclusions None. 9. Acknowledgments The authors would like to thank Russ White, Luca Martini, John Monaghan, Chip Popoviciu, Vijay Bollapragada, Carlos Pignataro etc. for their comments and suggestions. Asati, et al. Expires August 23, 2007 [Page 13] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 This document was prepared using 2-Word-v2.0.template.dot. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC4364, February 2006. [RFC4023] Rosen et al., "Encapsulating MPLS in IP or Generic Routing Encapsulation", RFC4023, March 2005 [RFC3931] Lau, J., Townsley, M., and Goyret I., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 [RFC4389] Kompella, K., and Swallo, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006 [RFC3107] Rosen E. and Rekhter Y., "Carrying Label information in BGP-4", RFC 3107, May 2001 10.2. Informative References [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., Swallow, G., "BFD for MPLS LSPs", draft-ietf-bfd-mpls, work in progress. [TUN-SAFI] Nalawade et al, "BGP Tunnel SAFI", draft-nalawade-kapoor- tunnel-safi-05.txt. Asati, et al. Expires August 23, 2007 [Page 14] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 [BGP-TUN] Kapoor R., Nalawade G., "BGP4 Tunnel Encapsulation attribute", draft-nalawade-kapoor-idr-bgp-ssa-03.txt, work in progress. Author's Addresses Rajiv Asati (Editor) Cisco Systems 7025 Kit Creek Road RTP, NC 27560 USA Email: rajiva@cisco.com Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@bt.infonet.com Tom Nadeau Cisco Systems 300 Beaver Brook Road Boxborough, MA, 01719 USA Email: tnadeau@cisco.com Azhar Sayeed Cisco Systems 300 Beaver Brook Road Boxborough, MA, 01719 USA Email: asayeed@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an Asati, et al. Expires August 23, 2007 [Page 15] Internet-Draft BGP/MPLS Traffic Blackhole Avoidance Feb 23, 2007 attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Asati, et al. Expires August 23, 2007 [Page 16]