[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03

Network Working Group                                       A. Bashandy
Internet Draft                                            Cisco Systems
Intended status: Standards Track                          July 10, 2011
Expires: January 2012

          Scalable BGP FRR Protection against Edge Node Failure
                 draft-bashandy-bgp-edge-node-frr-00.txt


Abstract

Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/p via the external routers CE1,
CE2,..., CEm.  If the edge router PEi crashes or becomes totally
disconnected from the core, it desirable for a penultimate hop route
''P      '' carrying traffic to the failed edge router PEi to immediately
restore traffic by re-tunneling packets originally tunneled to PEi
and destined to the prefix P/p to one of the other edge routers that
advertised P/p, say PEj, until BGP re-converges. In doing so, it is
highly desirable to keep the core BGP-free while not imposing
restrictions on external connectivity. Thus (1) a core router should
not be required to learn any BGP prefix, (2) the size of the
forwarding and routing tables in the core routers should be
independent of the number of BGP prefixes,(3) there should be no
special router (or group of routers) that handles restoring traffic,
and (4) there should be no restrictions on what edge routers
advertise what prefixes. For labeled prefixes, (5) the penultimate
hop router must swap the label advertised by the failed edge router
PEi for the prefix P/p with the label advertised for the same prefix
by the edge router PEj before re-tunneling the packet to PEj

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material 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.




Bashandy               Expires January 10, 2012                [Page 1]


Internet-Draft        BGP FRR using Repair Label              July 2011

   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 January 10, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   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...................................................3
      1.1. Problem definition........................................4
      1.2. Conventions used in this document.........................5
      1.3. Terminology...............................................5
   2. Control Plane Operation........................................6
      2.1. Control plane Operation for unlabeled prefixes............6
         2.1.1. Step 1: Calculation of the Repair PE.................7
         2.1.2. Step 2: Assigning and Advertising the BGP Next-hop...7
         2.1.3. Step 3: Informing Core Routers about the Repair PE...7
         2.1.4. Step 4: How a P router (a core router) Programs its
         Forwarding Plane............................................8

Bashandy               Expires January 10, 2012                [Page 2]


Internet-Draft        BGP FRR using Repair Label              July 2011

      2.2. Control plane Operation for Labeled Prefixes..............8
         2.2.1. Step 1: Calculation of the Repair PE.................9
         2.2.2. Step 2: Assigning and Advertising the BGP Next-hop...9
         2.2.3. Step 3: Informing core routers about the repair path.9
         2.2.4. Step 4: How a P router (a core router) programs its
         forwarding plane...........................................10
      2.3. Rules for a choosing Repair path.........................11
         2.3.1. General Rules for Choosing and Programming the Repair
         Path.......................................................11
         2.3.2. Rules for Choosing the Repair Path for Labeled Prefixes
         ...........................................................11
      2.4. Forwarding Plane Operation...............................12
         2.4.1. For unlabeled prefix................................12
         2.4.2. For Labeled prefix..................................13
   3. Example.......................................................14
   4. Security Considerations.......................................16
   5. IANA Considerations...........................................16
   6. Conclusions...................................................16
   7. References....................................................16
      7.1. Normative References.....................................16
      7.2. Informative References...................................16
   8. Acknowledgments...............................................17

1. Introduction

   In a BGP free core, where traffic is tunneled between edge routers,
   BGP speakers advertise reachability information about prefixes. For
   labeled address families, namely AFI/SAFI 1/4, 2/4, 1/128, and
   2/128, an edge router assigns local labels to prefixes and
   associates the local label with each advertised prefix such as
   L3VPN [              .6], 6PE .                       [7], and Softwire [                                         .5]. Suppose that a given edge
   router is chosen as the best next-hop for a prefix P/p. An ingress
   router that receives a packet from an external router and destined
   for the prefix P/p "tunnels" the packet across the core to that
   egress router. If the prefix P/p is a labeled prefix, the ingress
   router pushes the label advertised by the egress router before
   tunneling the packet to the egress router. Upon receiving the
   packet from the core, the egress router takes the appropriate
   forwarding decision based on the content of the packet or the label
   pushed on the packet.

   In modern networks, it is not uncommon to have a prefix reachable
   via multiple edge routers. One example is the best external path
   [        .4]. Another more common and widely deployed scenario is L3VPN [                                                                       .6]
   with multi-homed VPN sites. As an example, consider the L3VPN
   topology depicted in F                             .igure 1.




Bashandy               Expires January 10, 2012                [Page 3]


Internet-Draft        BGP FRR using Repair Label              July 2011


                                      PE1
                                        \
                                         \
                                          \
                                           \
                                          CE1....... VPN prefix
                                           /       (10.0.0.0/8)
                                          /
                                         /
                                        /
        BGP free core        P--------PE0
                                        \
                                         \
                                          \
                                           \
                                          CE2....... VPN prefix
                                           /       (20.0.0.0/8)
                                          /
                                         /
                                        /
                                      PE2

             Figure 1 VPN prefix reachable via multiple PEs



   As illustrated in F                          .igure 1, the edge router PE0 is the primary NH
   for both 10.0.0.0/8 and 20.0.0.0/8. At the same time, both
   10.0.0.0/8 and 20.0.0.0/8 are reachable through the other edge
   routers PE1 and PE2, respectively.

   1.1. Problem definition

   The problem that we are trying to solve is as follows

   o  Even though multiple prefixes may share the same egress router,
      they have different backup edge router. In F                                                      .igure 1 above, both
      10.0.0.0/8 and 20.0.0.0/8 share the same primary next hop PE0,
      the routing protocol(s) must identify that the node protecting
      loop free alternate for 10.0.0.0/8 is PE1 while the node
      protecting loop free alternate for 11.0.0.0/8 is PE2

   o  On loosing connection to the edge router, the core router "P"
      needs to redirect traffic towards the "correct" backup edge
      router without waiting for IGP or BGP to re-converge and update
      the routing tables. On the failure of PE0 illustrated in .                                                                    Figure
      1, the core router P MUST reroute traffic for 10.0.0.0/8 towards
      PE1 and traffic for 11.0.0.0/8 towards PE2

Bashandy               Expires January 10, 2012                [Page 4]


Internet-Draft        BGP FRR using Repair Label              July 2011

   o  The core router P MUST NOT be forced to learn about the BGP
      prefixes on any of the edge routers. The same applies for all
      core routers.

   o  There SHOULD NOT be a need for a special router or group of
      routers to handle rerouting traffic on edge node failure.

   o  The size of the routing table on any core router MUST be
      independent of the number of BGP prefixes in the network.

   o  For labeled prefixes, the core router MUST swap the label
      advertised by egress edge router (PE0 in F                                                    .igure 1) with the
      label advertised by the backup router (PE1 and PE2 in F                                                                 .igure 1).



   1.2. Conventions used in this document

   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 [                                                                     .1].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   1.3. Terminology

   This section outlines the terms used in this document. For ease of
   use, we will use terms similar to those used by L3VPN [                                                              .6]

   o  BGP-Free core: A network where BGP prefixes are only known to
      the edge routers and traffic is tunneled between edge routers

   o  Protected prefix: It is a prefix P/p (of any AFI) that a BGP
      speaker has an external path to. The BGP speaker may learn about
      the prefix from an external peer through BGP, some other
      protocol, or manual configuration. The protected prefix is
      advertised to some or all the internal peers.

   o  Primary egress PE: It is an IBGP peer that can reach the
      protected prefix P/p through an external path and advertised the
      prefix to the other IBGP peers. The primary egress PE was chosen
      as the best path by one or more internal peers. In other words,
      the primary egress PE is an egress PE that will normally be used
      by some ingress PEs when there is no failure. Referring to
      F           .igure 1, PE0 is a primary egress PE.



Bashandy               Expires January 10, 2012                [Page 5]


Internet-Draft        BGP FRR using Repair Label              July 2011

   o  Primary next-hop: It is an IPv4 or IPv6 host address belonging
      to the primary egress PE. If the prefix is advertised via BGP,
      then the primary next-hop is the next-hop attribute in the BGP
      update message [                          .2].                             [3].

   o  CE: It is an external router through which an egress PE can
      reach a prefix P/p. The routers "CE1" and "CE2" in F                                                              .igure 1 are
      examples of such CE.

   o  Ingress PE: It is a BGP speaker that learns about a prefix
      through another IBGP peer and chooses that IBGP peer as the
      next-hop for the prefix.

   o  Repairing P router: A core router that attempts to restore
      traffic when the primary egress PE is no longer reachable
      without waiting for IGP or BGP to re-converge. The repairing P
      router restores the traffic by rerouting the traffic (through a
      tunnel) towards the pre-calculated repair PE when it detects
      that the primary egress PE is no longer reachable. Referring to
      F           .igure 1, the router "P" is the repairing P router.

   o  Repair egress PE: It is an egress PE other than the primary
      egress PE that can reach the protected prefix P/p through an
      external neighbor. The repair PE is pre-calculated via other PEs
      prior to any failure. Referring to F                                              .igure 1, PE1 is the repair
      PE for 10.0.0.0/8 while PE2 is the repair PE for 20.0.0.0/8.

   o  Protected egress PE: Any primary egress PE protected by a
      repairing P router.

   o  Protected edge router: Any protected egress PE.

   o  Repair path: It is the repair egress PE. If the protected prefix
      is a labeled prefix, the repair path is the repair egress PE
      together with the label that will be pushed when the repairing P
      router reroutes traffic to the repair PE.

2. Control Plane Operation

   This section specifies the control plane operation needed to solve
   the problem mentioned in the Introduction.

   2.1. Control plane Operation for unlabeled prefixes

   This section specifies the operation of the control plane for
   AFI/SAFI 1/1, 2/1, 1/2, and 2/2

   The control plane operation can be summarized in 4 steps:


Bashandy               Expires January 10, 2012                [Page 6]


Internet-Draft        BGP FRR using Repair Label              July 2011

   1. Calculation of the repair PE

   2. Assigning and advertising the next-hop for protected prefixes

   3. Informing core routers about repair PEs

   4. How a P router (a core router) programs its forwarding plane

2.1.1. Step 1: Calculation of the Repair PE

   1. Consider the prefix P/p learnt by an egress edge router PEi via
      an external neighbor. The edge router advertises the prefix P/p
      to some or all of its IBGP peers

   2. The edge router PEi MAY choose a repair PE for the external
      prefix P/p. Section 2                               ..3. specifies the rules for choosing the
      repair edge router PEj.

   3. In the end, an egress edge route PEi will have a repair edge
      router PEj for some or all prefixes that PEi has external
      path(s) to.

2.1.2. Step 2: Assigning and Advertising the BGP Next-hop

   1. An edge router PEi groups the set of prefixes that have a repair
      PE as follows: Two prefixes belong to the same group if they
      share the same repair PE

   2. For each group, the PE assigns a local next-hop. Thus if a
      prefix P/p belongs to group Gi, its primary next-hop is NHi. For
      example, the PE assigns a different loopback interface address
      as the next-hop for each of the groups of prefixes.

   3. When advertising the prefix and its primary next-hop to its IBGP
      peers, the PE router uses NHi as the next-hop attribute of
      prefixes belonging to the group Gi

2.1.3. Step 3: Informing Core Routers about the Repair PE

   1. In step 2 (Section 2                              ..1.2. ) the egress PE assigns a primary
      next-hop NHi for protected prefixes belonging to group Gi.

   2. The primary next-hop NHi is advertised to the core using IGP as
      usual






Bashandy               Expires January 10, 2012                [Page 7]


Internet-Draft        BGP FRR using Repair Label              July 2011

   3. The repair next-hop is the next-hop attribute advertised for the
      prefix P/p by the repair edge router PEj. Let's denote the
      repair next-hop for prefixes belonging to group Gi by "rNHi".
      Because rNHi is the next-hop advertised by the repair PE, rNHi
      will also be known to all core routers via IGP

   4. The egress PE MUST advertise the pair (NHi,rNHi) to all directly
      connected core routers.

   5. The egress PE MAY advertise the pair (NHi,rNHi) to all core
      routers in the network.

   6. The structure and method of advertising the pair (NHi,rNHi) is
      beyond the scope of this document. For example, the pair
      (NHi,rNHi) may be advertised through an ISIS optional TLV.

   7. The semantics of the pair (NHi,rNHi) are: If the next-hop NHi
      becomes unreachable, then traffic destined to the next-hop NHi
      SHOULD be re-tunneled to the next-hop rNHi because rNHi can
      reach prefixes reachable via the primary next-hop NHi.

   8. Because of the previous steps, core routers that are directly
      connected to the egress PE (and possibly other core routers) are
      aware of the repair next-hop for protected BGP prefixes
      reachable via the egress PE. Note that a core router is totally
      unaware of the BGP prefixes.

2.1.4. Step 4: How a P router (a core router) Programs its Forwarding
   Plane

   1. Through usual IGP mechanism, the P router has a prefix matching
      every BGP next-hop. Let the next-hop NHi match the route Ri

   2. The next-hop of prefix Ri is on the path towards the primary
      egress PE.

   3. Thus the FIB entry for Ri is programmed as follows:

       a. Primary next-hop: the next router on the path towards NHi

       b. Repair next-hop: the next-router on the path towards rNHi

   2.2. Control plane Operation for Labeled Prefixes

   This section specifies the operation of the control plane for
   AFI/SAFI 1/4, 2/4, 1/128, and 2/128.




Bashandy               Expires January 10, 2012                [Page 8]


Internet-Draft        BGP FRR using Repair Label              July 2011

2.2.1. Step 1: Calculation of the Repair PE

   1. As usual, each PE allocates a local label for each prefix it can
      reach through an external neighbor CE. A PE may also allocate a
      repair label is specified in [                                        .11].

   2. Each edge router advertises the prefix together with the local
      label and possibly the repair label [                                               .11] to some or all of its
      IBGP peers.

   3. As a result, an edge router PEi having an external path to the
      prefix P/p may learn about the prefix through other IBGP peers.

   4. The edge router PEi MAY choose a repair PE for the external
      prefix P/p. Rules for choosing the repair PE are specified in
      Section 2                   ..3.

   5. The edge router PEi chooses the one of labels advertised by the
      other edge router PEj for the prefix P/p as the "repair label".
      The algorithm for choosing the repair label is specified in
      Section 2                   ..3.

   6. In the end, if the edge router PEi can reach the prefix P/p
      through and external path and the prefix P/p is advertised by at
      least one other PE, the edge router PEi will have

       o a primary path towards the CE from which it learnt the
          prefix, and

       o a repair path consisting of a repair PE and a repair label
          advertised by the chosen repair PE.

2.2.2. Step 2: Assigning and Advertising the BGP Next-hop

   1. The edge router PEi groups all BGP prefixes for which PEi has an
      external path and a repair path as follows: Two prefixes belong
      to the same group Gi if they share the same repair PE and repair
      label

   2. The remaining steps are identical to the steps used by unlabeled
      prefixes in section 2                               ..1.2.

2.2.3. Step 3: Informing core routers about the repair path

   1. In step 2 (Section 2                              ..2.2. ) the egress PE assigns a primary
      next-hop NHi and a repair path (consisting of a repair next-hop
      and repair label) for protected prefixes belonging to group Gi.

   2. The primary next-hop NHi is advertised into IGP as usual

Bashandy               Expires January 10, 2012                [Page 9]


Internet-Draft        BGP FRR using Repair Label              July 2011

   3. The repair next-hop is the next-hop advertised for the prefix
      P/p by the repair edge router PEj. Denote the repair next-hop
      for prefixes belonging to group Gi by "rNHi". Denote the repair
      label for prefixes belonging to group Gi by "rLi". Because rNHi
      is the next-hop attribute advertised by the repair PE, rNHi will
      also be known to all core routers via IGP

   4. The repairing egress PE MUST advertise the triplet (NHi, rNHi,
      rLi) to all directly connected core routers.

   5. The repairing egress PE MAY advertise the triplet (NHi, rNHi,
      rLi) to all core routers in the network

   6. The triplet (NHi,rNHi, rLi) may be advertised through various
      means, such as ISIS optional TLV. The structure and method of
      advertising the triplet (NHi,rNHi,rLi) is beyond the scope of
      this document.

   7. The semantics of the pair (NHi,rNHi,rLi) are: If the next-hop
      NHi becomes unreachable, then traffic destined to the next-hop
      NHi should be re-tunneled to the next-hop rNHi and the label
      pushed by the ingress PE MUST be swapped with the label rLi

   8. Because of the previous steps, core routers that are directly
      connected to the egress edge router (and possibly other core
      routers) are aware of the repair path for protected BGP prefixes
      reachable via the egress edge router. Note that a core router is
      totally unaware of the BGP prefixes themselves

2.2.4. Step 4: How a P router (a core router) programs its forwarding
   plane

   1. Through usual IGP mechanism, the P router has a prefix matching
      every BGP next-hop. Let the primary next-hop NHi match the route
      Ri

   2. The next-hop of prefix Ri is on the path towards the protected
      egress edge router PEi. The next-hop of the prefix Ri is
      considered the primary path for the prefix Ri

   3. Thus the FIB entry for Ri is programmed as follows

       a. Primary path: the next router on the path towards NHi

       b. Repair path:

           i. Pop label in the packet right under the tunnel header
               (irrespective of the value of that label)


Bashandy               Expires January 10, 2012               [Page 10]


Internet-Draft        BGP FRR using Repair Label              July 2011

          ii. Push the repair label rLi

         iii. Re-tunnel the packet towards the repair next-hop rNHi

   2.3. Rules for a choosing Repair path

   This section specifies rules governing how an egress edge router
   PEi chooses the repair path. Other than the rules in this section,
   the method of choosing the repair path is beyond the scope of this
   document.

2.3.1. General Rules for Choosing and Programming the Repair Path

   This section specifies general rules for choosing the repair path
   for both labeled and unlabeled prefixes.

   1. A repair PE MUST be another edge router PEj that advertises the
      same prefix to the edge router PEi via IBGP peering.

   2. If the repairing "P" router determines that the path taken by
      the tunnel from the repairing "P" router to repair edge router
      PEj passes through the protected edge router PEi, then the
      repairing router "P" SHOULD NOT install the repair path in its
      forwarding plane. Instead the repair path MAY use a different
      FRR protection mechanism such as that specified in [                                                              .8], [                                                                   .9], and
      [           .10].

      The reason for this rule is that the tunnel to the repair edge
      router PEj does not provide protection against the failure of
      the edge node PEi. Instead it provides core protection against
      the failure of the path through the core leading to the
      protected edge node PEi. Thus existing core FRR protection
      mechanisms such as those specified in [                                                 .8], [                                                      .9], and [                                                               .10] can be
      used

2.3.2. Rules for Choosing the Repair Path for Labeled Prefixes

   This section specifies additional rules by which an egress edge
   router PEi chooses the repair path for an external labeled prefix
   P/p.

   1. A primary edge router PEi SHOULD only choose the edge router PEj
      and the repair label rLi as a repair path for the prefix P/p if
      label advertised for the prefix P/p by the repair edge router
      PEj is allocated on per-VPN or per-CE/per-next-hop basis.





Bashandy               Expires January 10, 2012               [Page 11]


Internet-Draft        BGP FRR using Repair Label              July 2011

      The reason for this is as follows. As mentioned in the abstract
      and Introduction, the core of the network SHOULD remain BGP-free
      and the size of the routing table on a core router SHOULD remain
      independent of the number of BGP prefixes. BGP prefix grouping
      in section 2                      ..2.2.  requires two prefixes to belong to two
      different groups if the labels advertised by the repair PE for
      the two prefixes are different. Thus if the repair edge router
      allocates labels on per-prefix basis, protected edge router PEi
      will advertise a different primary next-hop for each protected
      prefix. This is equivalent to having core router "P" knowing
      about every BGP prefix. In addition the size of the routing
      table of the "P" router becomes comparable to the number of BGP
      prefixes.

   2. If the repair edge router PEj advertises a repair label as
      described in [                        .11], then the protected edge router PEi MAY choose
      the repair label advertised by PEj as the repair label for the
      prefix P/p.

      Using the repair label specified in [                                               .11] has two advantages:

       o A repairing edge router PEj need not change the primary
          label allocation policy (which may be per-prefix) but can be
          chosen as repair PE if the repair labels are allocated on
          per-CE or per-VRF basis.

       o As mentioned in [                               .11], an edge router does NOT repair a
          packet arriving with a repair label. Hence using the repair
          label when re-tunneling the packet towards PEj guarantees
          loop freedome in case of PE-CE link failure.



   2.4. Forwarding Plane Operation

   This section specifies the forwarding plane operation on the core
   router "P" when it detects that the protected edge router PEi is no
   longer reachable. We assume that the core router has pre-programmed
   its forwarding plane according to Sections 2                                                   ..1. and .                                                            2.2. .

2.4.1. For unlabeled prefix

   The forwarding table for the route Ri is programmed according to
   section .                2.1.4. As soon as the "P" router detects that the primary
   next-hop for Ri is not reachable it does the following for any
   packet destined to the protected edge router PEi.

   1. Decapsulate tunnel header of the arriving packet


Bashandy               Expires January 10, 2012               [Page 12]


Internet-Draft        BGP FRR using Repair Label              July 2011

   2. Tunnel the packet towards the repair egress PE identified by the
      repair next-hop rNHj

2.4.2. For Labeled prefix

   The forwarding table for the route Ri is programmed according to
   section .                2.2. . Remember that packets tunneled to the egress edge
   PEi have a label under the tunnel encapsulation. As soon as the "P"
   router detects that the primary next-hop for Ri is not reachable it
   does the following for any arriving packet destined to the
   protected edge router PEi

   1. Decapsulate the tunnel header to expose the labeled packet

   2. Swap the label on the top of the packet (irrespective of the
      value of that label) with the repair label rLi

   3. Tunnel the packet towards the repair egress PE identified by
      rNHj































Bashandy               Expires January 10, 2012               [Page 13]


Internet-Draft        BGP FRR using Repair Label              July 2011

3. Example

   We will use and LDP core as an example. Consider the diagram
   depicted in Figure 2 below. We assume that the PEs advertise repair
   labels as specified in [                               .11]

   +-----------------------------------+
   |                                   |
   |   LDP Core                        |
   |                                   |
   |                                  PE1
   |                                   |\
   |                                   | \
   |                                   |  \
   |                                   |   \
   |                                   |  CE1....... VPN prefix
   |                                   |   /       (10.0.0.0/8)
   |                                   |  /        (11.0.0.0/8)
   |                                   | /
   |                                   |/
   PEx                        P--------PE0    Lo1 = 1.1.1.1/32
   |                                   |\     Lo2 = 2.2.2.2/32
   |                                   | \
   |                                   |  \
   |                                   |   \
   |                                   |  CE2....... VPN prefix
   |                                   |   /       (20.0.0.0/8)
   |                                   |  /        (21.0.0.0/8)
   |                                   | /
   |                                   |/
   |                                  PE2
   |                                   |
   |                                   |
   +-----------------------------------+
                Figure 2 : Edge node BGP FRR in LDP core



   1. As we can see, PE0 has 4 prefixes: 10.0.0.0/8, 11.0.0.0/8,
      20.0.0.0/8, and 21.0.0.0/8. PE0 may assign a separate label to
      each prefix. The method and policy of assigning primary labels
      to each prefixes is irrelevant.

   2. PE1 advertises the repair label rL1 for prefixes 10.0.0.0/8 and
      11.0.0.0/8

   3. PE2 advertises the repair label rL2 for prefixes 20.0.0.0/8 and
      21.0.0.0/8


Bashandy               Expires January 10, 2012               [Page 14]


Internet-Draft        BGP FRR using Repair Label              July 2011

   4. As such, PE0 divides its prefixes into two groups
      G1 = {10.0.0.0/8, 11.0.0.0/8}
      G2 = {20.0.0.0/8, 21.0.0.0/8}

   5. When advertising the next-hop to its IBGP peer, PE0 advertises
      1.1.1.1 as the next-hop for prefixes belonging to group G1 and
      2.2.2.2 as the next-hop for prefixes belonging to group G2.

   6. PE0 advertises the prefixes 1.1.1.1/32 and 2.2.2.2/32 using the
      usual IGP mechanism.

   7. When advertising 1.1.1.1/32 into the core, PE0 advertises rL1
      and PE1 as a repair path. When advertising 2.2.2.2/32 into the
      core, PE0 advertises rL2 and PE2 as a repair path. The mechanism
      by which a repair path is advertised is beyond the scope of the
      proposal.

   8. On the penultimate hop router "P", LDP assigns a different LDP
      label to 1.1.1.1/32 and 2.2.2.2/32. Core routers other than
      penultimate hop routers may employ some sort of label
      aggregation to reduce the number of LDP labels

   9. Assume that the penultimate hop router "P" assigns the local LDP
      label L1 for prefix 1.1.1.1/32 and L2 for prefix 2.2.2.2/32

   10.On the penultimate router P, the forwarding entry for L1 will be
      as follows
      Primary path:
      - nexthop is PE0.
      - swap the incoming outer label with the LDP label towards
      1.1.1.1
      Repair path
       - Pop the incoming LDP label
       - Swap the internal label with the repair label rL1
       - Push the LDP label towards PE1
       - Forward the packet

   11.On the core router P, the forwarding entry for L2 will be as
      follows

      Primary path: Same as L1

      Repair Path
       - Pop the incoming LDP label
       - Swap the internal label with the repair label rL2
       - Push the LDP label towards PE2
       - Forward the packet



Bashandy               Expires January 10, 2012               [Page 15]


Internet-Draft        BGP FRR using Repair Label              July 2011

   12.If the P router detects that PE0 is no longer reachable, it can
      use the repair path already pre-programmed in the forwarding
      plane as described above. Because the repair path is pre-
      programmed as in the case of TE and IP FRR, the P router can re-
      route traffic very fast

4. Security Considerations

   No additional security risk is introduced by using the mechanisms
   proposed in this document

5. IANA Considerations

   No requirements for IANA

6. Conclusions

   This document proposes a method that allows fast re-route
   protection against edge node failure or complete disconnected from
   the core in a BGP-free core

7. References

   7.1. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

   [2]   Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol
         4 (BGP-4), RFC 4271, January 2006

   [3]   Bates, T., Chandra, R., Katz, D., and Rekhter Y.,
         "Multiprotocol Extensions for BGP", RFC 4760, January 2007

   7.2. Informative References

   [4]   Marques,P., Fernando, R., Chen, E, Mohapatra, P.,
         "Advertisement of the best external route in BGP", draft-
         ietf-idr-best-external-02.txt, April 2004.

   [5]   Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
         Framework", RFC 5565, June 2009.

   [6]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
         Networks (VPNs)", RFC 4364, February 2006.

   [7]   De Clercq, J. , Ooms, D., Prevost, S., Le Faucheur, F.,
         Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
         Edge Routers (6PE)", RFC 4798, February 2007

Bashandy               Expires January 10, 2012               [Page 16]


Internet-Draft        BGP FRR using Repair Label              July 2011

   [8]   Atlas, A. and A. Zinin, "Basic Specification for IP Fast
         Reroute: Loop-Free Alternates", RFC 5286, September 2008.

   [9]   Shand, S., and Bryant, S., "IP Fast Reroute", RFC5714,
         January 2010

   [10]  Shand, M. and S. Bryant, "A Framework for Loop-Free
         Convergence", RFC 5715, January 2010.

   [11]  Bashandy, P., Pithawala, B., and Hietz J., "Scalable, Loop-
         Free BGP FRR using Repair Label, "draft-bashandy-idr-bgp-
         repair-label-02.txt", June 2011

8. Acknowledgments

   Special thanks to Keyur Patel, Robert Raszuk, and Eric Rosen for
   the valuable comments

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Ahmed Bashandy
   Cisco Systems
   170 West Tasman Dr, San Jose, CA 95134
   Email: bashandy@cisco.com
























Bashandy               Expires January 10, 2012               [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/