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) ... <any other implementation specific check>



   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) ... <any other implementation specific check>



   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]