[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                       A. Bashandy
Internet Draft                                             B. Pithawala
Intended status: Standards Track                          Cisco Systems
Expires: October 2012                                       Jakob Heitz
                                                               Ericsson
                                                            May 1, 2012

              Scalable, Loop-Free BGP FRR using Repair Label
                draft-bashandy-idr-bgp-repair-label-04.txt


Abstract

Consider a BGP free core scenario. Suppose the provider edge BGP
speakers PE1, PE2,..., PEn know about a prefix P/m via the external
routers CE1, CE2,..., CEm.  If the PE router PEi loses connectivity to
the primary path, it is desirable to immediately restore traffic by
rerouting packets arriving from the core to PEi and destined to the
prefix P/m to one of the other PE routers that advertised P/m, say PEj,
until BGP re-converges. However if the loss of connectivity of PEi to
the primary path also resulted in the loss of connectivity between PEj
and CEj, rerouting a packet before the control plane converges may
result in a loop. In this document, we propose using a repair label for
traffic restoration while avoiding loops. We propose advertising the
"repair" label through BGP.

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.

   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.




Bashandy                Expires April 30, 2012                 [Page 1]


Internet-Draft        BGP FRR using Repair Label           October 2011

   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 April 1, 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. Conventions used in this document.........................4
      1.2. Terminology...............................................4
   2. Protocol Operation.............................................5
      2.1. Control plane Operation...................................5
         2.1.1. Additional Rules for allocating and advertising a Repair
         label.......................................................6
      2.2. Forwarding Plane Operation................................6
      2.3. Example...................................................7
   3. How to Disseminate Repair Label Information....................9
         3.1.1. Structure of the Repair Label Path Attribute........10
         3.1.2. Semantics of the Repair Label Attribute.............10
         3.1.3. Additional Rule when Forwarding Advertisements
         Containing the Repair Path Attribute.......................11
   4. Security Considerations.......................................12
   5. IANA Considerations...........................................12
   6. Conclusions...................................................12

Bashandy                Expires April 1, 2012                  [Page 2]


Internet-Draft        BGP FRR using Repair Label           October 2011

   7. References....................................................12
      7.1. Normative References.....................................12
      7.2. Informative References...................................13
   8. Acknowledgments...............................................13

1. Introduction

   In a BGP free core, where traffic is tunneled between edge routers
   and edge routers assign labels to prefixes, BGP speakers advertise
   reachability information about prefixes and associate a local label
   with each prefix such as L3VPN [9], 6PE [10], and Softwire [8].
   Suppose that a given edge router is chosen as the best next-hop for
   a prefix P/m. An ingress router that receives a packet from an
   external router and destined for the prefix P/m pushes the label
   advertised by the egress edge router and then "tunnels" the packet
   across the core to that egress router. Upon receiving the labeled
   packet from the core, the egress router uses the label on the packet
   to take the appropriate forwarding decision.

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

         +--------------------------+
         |                          |
         |      BGP free Core       |
         |                          |
         |      +------------------PE1----+
         |     /                    |      \
         |    /                     |       \
         |   /                      |        \
         |  /                       |         \
         | /                        |          *
        PE3                         |          CE....... VPN prefix
         | \                        |          *          (P/m)
         |  \                       |         /
         |   \                      |        /
         |    \                     |       /
         |     \                    |      /
         |      +------------------PE2----+
         |                          |
         |                          |
         +--------------------------+

              Figure 1 VPN prefix reachable via multiple PEs



Bashandy                Expires April 1, 2012                  [Page 3]


Internet-Draft        BGP FRR using Repair Label           October 2011

   PE3 is the ingress PE. PE1 and PE2 are both egress PEs connected to
   CE. CE advertises one or more VPN prefixes, denoted by P/m. PE1 and
   PE2 advertise P/m as VPNv4 or VPNv6 routes to all ingress PEs,
   including PE3, and associates a label with each route.

   Suppose that the ingress PE, PE3, chooses PE1 as the next-hop for
   the prefix P/m. In order to minimize traffic loss, it is highly
   desirable for PE1 to reroute all traffic destined to P/m to PE2 as
   soon as the connectivity to CE is lost without waiting for the
   control plane (whether it is IGP or BGP) to re-converge and compute
   the new best path. In doing so, PE1 pushes the label advertised by
   PE2 for the prefix P/m, and then "tunnels" the packet to PE2.
   However if the loss of PE1-CE connectivity was due to CE crash, then
   PE2 will also reroute the traffic back to PE1, resulting in a loop.
   Due to ultra scalability requirements, where there is a need to
   support thousands of peers and hundreds of thousands of prefixes,
   there is a need to support quick traffic restoration without waiting
   for the control plane to converge and without risking loops.

   1.1. 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.2. Terminology

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

  o  Protected prefix: a prefix P/m (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: an IBGP peer that can reach the protected
     prefix P/m 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 when
     there is no failure. Referring to Figure 1, PE1 is a primary
     egress PE.



Bashandy                Expires April 1, 2012                  [Page 4]


Internet-Draft        BGP FRR using Repair Label           October 2011

  o  CE: an external router through which an egress PE can reach a
     prefix P/m. The router "CE" in Figure 1 is an example of such a
     CE

  o  Ingress PE: a BGP speaker that learns about a prefix through
     another IBGP peer and chooses that IBGP peer as the next-hop for
     the prefix. PE3 in Figure 1 is an example of an ingress PE

  o  Repairing PE: the egress PE that attempts to restore traffic when
     the primary path is no longer reachable "without" waiting for BGP
     to re-converge. The repairing PE restores the traffic by
     rerouting the traffic (through a tunnel) towards the pre-
     calculated repair PE when it detects that the primary path is no
     longer reachable. Referring to Figure 1, if PE3 chooses PE1 as
     the primary egress PE and PE1 decides to reroute traffic to PE2
     on losing reachability with CE, then PE1 is a repairing PE.

  o  Primary label: the label advertised by the primary egress PE to
     be used for normal traffic forwarding.

  o  Repair egress PE: an egress PE other than the primary egress PE
     that can reach the protected prefix P/m through an external
     neighbor. The repair PE is pre-calculated via other repairing PEs
     prior to any failure

  o  Repair label: the label that will be pushed on the packet when
     the repairing PE reroutes the traffic (through a tunnel) towards
     the repair egress PE. Section 2.  discusses how the repair label
     is used. Section 3.  discusses semantics of and the method for
     disseminating repair label information.

  o  Repair path: the repair egress PE and the repair label.

  o  internal and external: internal or external to the core.

2. Protocol Operation

   This section explains the operation of the control and forwarding
   planes of routers participating in BGP-free core traffic
   restoration.

   2.1. Control plane Operation

   1. As usual, each PE allocates a local label for each prefix it can
      reach through an external neighbor CE. This is the primary label
      used for normal traffic forwarding.




Bashandy                Expires April 1, 2012                  [Page 5]


Internet-Draft        BGP FRR using Repair Label           October 2011

   2. To provide repair path information to all PEs, the PE also
      allocates a repair label to the prefix if it can reach that
      prefix via an external neighbor. Different repair label
      allocation schemes are proposed in Section 3. .

   3. The PE advertises both the primary and repair labels to all IBGP
      peers.

   4. When a PE receives the label advertisement from egress PEs, it
      calculates a primary egress PE and a repair egress PE based on
      its internal path selection criteria. Note that the method of
      choosing the repair path is beyond the scope of this document.

   5. In the end, for some of the prefixes advertised by more than one
      PE, a PE will have

       o a primary path

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

   6. A PE "never" protects a repair label. Hence on any PE, a repair
      label only has paths towards the CE. However a primary label may
      have a repair path towards a chosen repair PE

2.1.1. Additional Rules for allocating and advertising a Repair label

  o  A repair PE MUST NOT advertise a repair label for a prefix if it
     does NOT have an external path to the prefix

  o  The forwarding entry for the repair label on the repair PE MUST
     NOT point to an internal path

  o  Repair labels SHOULD be advertised with labeled address families
     only. That is AFI/SAFI 1/4, 2/4, 1/128, and 2/128.



   2.2. Forwarding Plane Operation

   This section specifies the forwarding plane operation when a PE
   receives a packet and any of the following two conditions are true:

  o  The PE lost the primary path and has not yet calculated another
     primary path and programmed it in the forwarding plane.





Bashandy                Expires April 1, 2012                  [Page 6]


Internet-Draft        BGP FRR using Repair Label           October 2011

  o  The arriving packet arrived from the core and the PE does not
     have an external path. It is noteworthy to mention that this
     condition should be a temporary condition until all ingress PEs
     converge and stop sending traffic to that PE.



   The forwarding plane processes arriving traffic as follows:

   1. If the repairing PE is an egress PE, the packet arrives at the
      repairing PE with the primary label at the top because the packet
      is "tunneled" from the ingress PE(s). In that case, the repairing
      PE swaps the incoming label stack with the "repair label stack"
      advertised by the repair egress PE. Section 3.1.2.  specifies all
      the details

   2. The repairing PE tunnels the packet to the repair PE

   3. At the repair PE, the packet arrives with the repair label at the
      top. The repair PE uses the incoming label stack to take
      forwarding decisions

   4. If the repair egress PE can reach the CE, the repair PE forwards
      the packet towards the CE.

   5. If the repair PE cannot reach the CE, the traffic will be dropped
      because a PE never protects a repair label

   2.3. Example

   Consider the L3VPN [9] topology depicted in Figure 2 where two PEs
   are connected to the same PE. Assume that the core is LDP. We will
   be using an advertised repair label.

                                  PE1
                                     \
                                      \
                                       \
                                        \
               LDP core                 CE....... VPN prefix
                                        /        (10.0.0.0/8)
                                       /
                                      /
                                     /
                                   PE2

                         Figure 2 : L3VPN Example



Bashandy                Expires April 1, 2012                  [Page 7]


Internet-Draft        BGP FRR using Repair Label           October 2011

   PE1: Repairing egress PE
   PE2: repair PE
   Primary VPN label advertised by PE1 to all PEs: 4000
   Repair VPN label advertised by PE1 to all PEs: 5000
   Primary VPN label advertised by PE2 to all PEs: 2000
   Repair VPN label advertised by PE2 all PEs: 3000

   LDP label for PE2 on PE1 is 1234
   LDP label for PE1 on PE2 is 4567

   Before failure
   '''''''''''''''
   PE1 has the following FIB entries

   4000 -----> CE (unlabeled)
        -----> PE2, swap 4000 with 3000 and then push 1234
   5000 -----> CE (unlabeled)

   PE2 has the following
   2000 -----> CE (unlabeled)
        -----> PE1, swap 2000 with 5000 and then push 4567
   3000 ------> CE (unlabeled)

   After the CE crashes
   ''''''''''''''''''''
   PE1 has the following entry:
   4000 -----> PE2, swap 4000 with 3000 and then push 1234
   5000 -----> Drop


   PE2 has the following
   2000 -----> PE1, swap 2000 with 5000 and then push 4567
   3000 ------> Drop


   Because of the above routing entries, any traffic arriving from the
   core at PE1 and destined for 10.0.0/8,  is rerouted towards PE2
   using the repair VPN label 3000. PE2 will just drop it instead of
   looping it back towards PE1.

   After the link between PE1 and CE fails (CE did not crash)
   '''''''''''''''''''''''''''''''''''''''''''''''''''''''''
   PE1 has the following entry:
   4000 -----> PE2, swap 4000 with 3000 and then push 1234
   5000 -----> Drop

   PE2 has the following
   2000 -----> CE (unlabeled)
        -----> PE1, swap 2000 with 5000 and then push 4567

Bashandy                Expires April 1, 2012                  [Page 8]


Internet-Draft        BGP FRR using Repair Label           October 2011

   3000 ------> CE


   Because of the above routing entries, any traffic arriving from the
   core at PE1 and destined for 10.0.0/8 is rerouted towards PE2 using
   the repair VPN label 3000. PE2 will forward the traffic towards CE.

3. How to Disseminate Repair Label Information

   We propose to advertise the repair label as an optional path
   attribute. Advertising the repair label as an optional path
   attributes has some advantages:

  o  An egress PE can benefit from a scalable repair label allocation
     schemes such as per-CE repair label allocation

  o  Allows the repairing PE to share the same repair path among
     multiple protected prefixes. Since the repair path is shared by
     all labels sharing the path attribute, the repairing PE can
     optimize its RIB and FIB by sharing the same repair path data
     structure among a large number of protected prefixes.

  o  Reduces the BGP update message size. Instead of having to send
     additional labels per prefix, multiple prefixes can share the
     same repair label

  o  The number of labels used for traffic restoration does not depend
     on the number of protected prefixes

  o  Allows for incremental deployment because the attribute is
     optional

   The main disadvantage of sharing the same repair path among multiple
   primary paths is loss of fine grain control. It is not possible to
   manage, control, or provide differentiated handling to traffic on
   per prefix basis until the network re-converges. The loss of fine
   grain control is limited to the BGP re-convergence period.

   It is noteworthy to mention that per-CE and/or per next-hop repair
   label allocation has some advantages over per-prefix repair label
   allocation. First it results in using fewer labels. Second it allows
   for better packing in BGP messages. Third it does not require
   special handling in the forwarding plane at the repair PE. Fourth it
   simplifies the forwarding plane while maximizing the packet
   switching performance because the egress PE can take a forwarding
   decision with a single FIB lookup.




Bashandy                Expires April 1, 2012                  [Page 9]


Internet-Draft        BGP FRR using Repair Label           October 2011

3.1.1. Structure of the Repair Label Path Attribute

   This document defines the repair label attribute as an optional non-
   transitive path attribute [2] as follows:

      Attribute name: REPAIR_LABEL

      Type code: TBD

      Attribute Flags:

         Optional bit: 1

         Transitive bit: 0

         Partial bit: 0

         Extended Length bit: 0

      Length of the attribute: length in octets of the attribute

      Attribute Value: The attribute value contains a stack of one or
      more labels. The encoding of the labels is identical to encoding
      of the "label" field in [4]. The value of the bottom of stack
      (BOS) bit is determined at traffic restoration time as specified
      in Section 3.1.2. .

3.1.2. Semantics of the Repair Label Attribute

   This document specifies the semantics of the repair label attribute
   when the attribute carries one repair label only. The semantics of
   more than one repair label is beyond the scope of this document.

   Suppose a BGP speaker PE1 receives an update message with a repair
   label attribute containing the label "Lr2" from the IBGP peer PE2.
   Suppose the NLRI in the MP_REACH_NLRI attribute [3] contains the
   prefixes R1, R2,. . . , Rn each bound to a label L21, L22,. . . ,
   L2n, respectively. This means the following:

   1. PE2 will never attempt to repair a packet arriving with the label
      "Lr2". Hence PE2 will either forward the packet to an external CE
      or drop the packet

   2. PE2 expects the following from PE1:






Bashandy                Expires April 1, 2012                 [Page 10]


Internet-Draft        BGP FRR using Repair Label           October 2011

       a. Case a: The route Ri on PE1 is bound to a local label "L1i".
          Suppose PE1 receives a packet from the core with the label
          "L1i" at the top of the stack. If the PE1 loses the primary
          path for a prefix Ri or PE1 receives a packet from the core
          while not having an external path, and PE1 decides that PE2
          is the repair PE for the prefix Ri, then PE1 MUST swap the
          label "L1i" on the packet with the repair label "Lr2" and
          then tunnel the packet to PE2. The bottom of stack (BOS) bit
          MUST be copied from the label arriving on the packet to the
          label "Lr2"

       b. Case b: The route Ri on PE1 is bound to an aggregate label
          (e.g. per-vrf label). In that case, if PE1 receives a packet
          from the core, PE1 has to perform more than one route lookup
          to determine the primary path. Eventually, there will either
          be an IP lookup or a label lookup that points to the primary
          path:

           i. A label lookup points to the primary path: In that case,
               PE1 handles the packet as described in item 2.a above.

          ii. An IP lookup points to the primary path: In that case,
               if the PE1 loses the primary path for a prefix Ri or PE1
               receives a packet from the core while not having an
               external path, PE1 handles the packet as follows

                 1. PE1 pops all labels on the packet

                 2. PE1 MUST push the label "Lr2"

                 3. PE1 tunnels the packet to PE2. The bottom of stack
                    (BOS) bit in "Lr2" MUST be set as specified in [5].

3.1.3. Additional Rule when Forwarding Advertisements Containing the
   Repair Path Attribute

   As specified in Section 3.1.1. , the repair label attribute is a
   non-transitive attribute. However there may be cases, such as inter-
   AS option (b)[9], route reflectors [11], or confederation [12],
   where a router may replace the advertised next-hop with its own
   before forwarding an advertisement. If a BGP speaker replaces the
   next-hop attribute with its own and the advertisement contains a
   repair label attribute with label stack "Sr", there are two options

  o  Option 1: The BGP speaker MUST NOT advertise the repair label
     attribute




Bashandy                Expires April 1, 2012                 [Page 11]


Internet-Draft        BGP FRR using Repair Label           October 2011

  o  Option 2: The BGP speaker MUST replace the repair label stack
     "Sr" with a locally allocated label stack "Sr1" before
     advertising the route and then advertise the stack "Sr1" in the
     repair label attribute. For the forwarding plane, the BGP speaker
     MUST install a swap forwarding entry such that if the BGP speaker
     receives a packet with the label stack "Sr1", it swaps "Sr1" with
     the stack "Sr".

   Note that advertising the repair label attribute by the router
   depends on whether the router understands the semantics of and
   supports the repair label attribute at the time of receiving an
   advertisement containing the repair label attribute.

4. Security Considerations

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

5. IANA Considerations

   This document defines a new BGP path attribute. IANA maintains a
   list of the current BGP attribute typecodes in [6]. This document
   proposes defining a new typecode value of "TBD" for the REPAIR_LABEL
   path attribute

6. Conclusions

   This document proposes using a repair label to allow restoring
   traffic prior to BGP convergence while avoiding loops

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

   [4]   Rosen, E., Rekhter, Y., "Carrying Label Information in BGP-4",
         RFC 3107, May 2001

   [5]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
         D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC
         3032, January 2001.

Bashandy                Expires April 1, 2012                 [Page 12]


Internet-Draft        BGP FRR using Repair Label           October 2011

   7.2. Informative References

   [6]   BGP Parameters, http://www.iana.org/assignments/bgp-
         parameters/bgp-parameters.xhtml

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

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

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

   [10]  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

   [11]  Bates, T., Chen, E., and Chandra, R., "BGP Route Reflection:
         An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456,
         April 2006

   [12]  Traina, P., McPherson, P., and Scudder, J., "Autonomous System
         Confederations for BGP", RFC 5065, August 2007

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

   Burjiz Pithawala
   Cisco Systems
   170 West Tasman Dr, San Jose, CA 95134
   Email: bpithaw@cisco.com

   Jakob Heitz
   Ericsson
   100 Headquarters Drive, San Jose, CA, 95134
   Email: jakob.heitz@ericsson.com

Bashandy                Expires April 1, 2012                 [Page 13]


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