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

Versions: 00

Network Working Group                                       A. Bashandy
Internet Draft                                                  K. Raza
Intended status: Standards Track                          Cisco Systems
Expires: September 2012                                   March 5, 2012

     LDP Extension for FRR Edge Node Protection in BGP-Free LDP Core
                 draft-bashandy-mpls-ldp-bgp-frr-00.txt


Abstract

   Consider a BGP free core scenario with LDP running in the core.
   Suppose the edge BGP speakers PE1 and PE2 know about a prefix P/m
   via the external routers CE1 and CE2.  If the edge LSR PE1 crashes
   or becomes totally disconnected from the core, it is desirable for a
   core LSR "P", that is carrying traffic to the failed edge LSR PE1,
   to immediately restore traffic by re-routing packets destined to the
   prefix P/m from the LSP terminating on PE1 to be forwarded over the
   LSP terminating on PE2, until BGP reconverges. If the packets
   originally flowing to the failed edge LSR PE1 are BGP labeled, then
   the repairing core LSR P must swap the label (corresponding to
   prefix P/m) advertised by the failed edge LSR PE1 with the label
   advertised for the same prefix by the edge LSR PE2 before re-routing
   the packets through an LSP terminating on PE2. To implement BGP edge
   node protection in a BGP-free LDP core, this document proposes an
   extension to LDP. This extension allows an LDP speaker running on a
   Edge LSR Node (e.g. PE1) to inform the LDP speakers running on core
   LSRs about the "Repair" edge LSR (e.g. PE2), as well as Repair LSR's
   label for prefix P/m, if any.

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




Bashandy              Expires September 5, 2012                [Page 1]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

   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 September 5, 2012.

Copyright Notice

   Copyright (c) 2012 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
      1.3. Problem definition........................................5
   2. The Proposed LDP Extension.....................................5
      2.1. The LDP "BGP Repair Path status" Code.....................5
      2.2. The LDP "BGP Repair Path Status" TLV......................6
      2.3. LDP Capability Negotiation................................8
      2.4. BGP Repair Status in a LDP Notification message...........8
   3. BGP Repair Path Signaling Procedures...........................9
      3.1. Signaling a BGP Repair Path...............................9
      3.2. Updating a BGP Repair Path...............................10
      3.3. Withdrawing a BGP Repair Path............................10

Bashandy              Expires September 5, 2012                [Page 2]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

   4. Security Considerations.......................................10
   5. IANA Considerations...........................................11
   6. Conclusions...................................................11
   7. References....................................................11
      7.1. Normative References.....................................11
      7.2. Informative References...................................11
   8. Acknowledgments...............................................12

1. Introduction

   In a BGP free core, where traffic is tunneled between edge
   routers/LSRs, (MP)BGP [2][3] speakers advertise reachability
   information about prefixes to edge routers only. For labeled
   address families, namely AFI/SAFI 1/4, 2/4, 1/128, and 2/128, an
   edge LSR assigns local labels to prefixes and associates the local
   label with each advertised prefix such as L3VPN [9], 6PE [10], and
   Softwire [8]. Suppose that a given edge LSR is chosen as the best
   next-hop for a prefix P/m. An   ingress LSR receives a packet
   destined for the prefix P/m from an external router, and sends the
   packet to that egress LSR through an LSP terminating on the egress
   LSR. If the prefix P/m is a BGP labeled prefix, the ingress LSR
   pushes the BGP label advertised by the egress LSR before sending
   the packet into the LDP LSP terminating on the egress LSR. Upon
   receiving the packet from the core, the egress LSR takes the
   appropriate forwarding decision based on the content of the packet
   and/or the label(s) pushed on the packet.

   In modern networks with redundancy in place, 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.


















Bashandy              Expires September 5, 2012                [Page 3]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012


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

             Figure 1 VPN prefix reachable via multiple PEs



   As illustrated in Figure 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. 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

   o  LSR : Label Switched Router (In the context of this document,
      this refers to a router doing label switching on LDP and/or BGP
      labels)

   o  LSP: Label Switched Path

Bashandy              Expires September 5, 2012                [Page 4]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

   o  Primary LSP: It is the LSP from the ingress PE to the primary
      egress PE. This is the LDP implementation of the primary tunnel
      defined in [6].

   o  Repair LSP: It is the LSP from the repairing P router to the
      repair egress PE. This is the LDP implementation of the repair
      tunnel defined in [6].

   For the rest of the terms, refer to [6].

   1.3. Problem definition

   The general problem for the example shown in Section 1. is specified
   in [6]. The objective of this document is to specify an LDP [4]
   extension to let the primary egress PE inform repairing core
   router(s) about the repair path in an LDP core for both labeled and
   unlabeled protected prefixes. In other words, this is an LDP-based
   implementation of step 3 in [6]. Other problems, such as determining
   the repair PE, detecting the protected PE (node/connectivity)
   failure, and interactions between LDP and BGP on protected edge PE
   LSR, are beyond the scope of this document.

2. The Proposed LDP Extension

   As specified in [4] section 3.5.1, an LDP speaker can use LDP
   Notification message to send its status or advisory information
   towards a peer. An LDP Notification message consists of a Status TLV
   and optional parameters, whereas "Status" TLV holds the status code
   being signaled. For an egress PE LSR to convey repair path info (for
   a BGP next-hop) to core LSRs, we propose to convey this information
   via a LDP Notification message that carries a new status code in "LDP
   Status" TLV, a new "BGP Repair Path Status" TLV and FEC TLV
   (corresponding to BGP next-hop) as optional parameters. This
   information is to be advertised to a peer only if the peer has
   signaled the support for "Unrecognized Notification" capability a
   specified in [5].

   The proposed extensions are described more in details in following
   sub-sections.

   2.1. The LDP "BGP Repair Path status" Code

   A new LDP status code, namely "BGP Repair Path status" is defined
   that is to be set in the "Status Code" field of the "Status TLV" as
   defined in [4] section 3.4.6.





Bashandy              Expires September 5, 2012                [Page 5]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

   2.2. The LDP "BGP Repair Path Status" TLV

   A new LDP TLV, namely "BGP Repair Path Status TLV", is defined to be
   used in an LDP Notification message under optional parameters section
   only if the Notification message status code is set to "BGP Repair
   Path status".

   This TLV is an implementation of the repair path defined in [6] and
   is used to convey the information about the Repair edge LSR and its
   associated BGP label, if any, for traffic destination prefix P/m.
   This information is conveyed in the context of the protected primary
   BGP nexthop [6], whose information is carried in the FEC TLV. This
   document allows only one repair path per BGP nexthop.

   The encoding of the "BGP Repair Path Status TLV" is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Repair Path TLV Type(TBD) |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|L|P|     Reserved            |         Address Family        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Repair PE Address (variable size)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Underlying Repair label (optional)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 2 Format of BGP Repair Path Status TLV


   The fields are as follows

      U/F:

          Must be set to 1/0 respectively so that this TLV can be
          ignored if not known or not supported.

      Repair Path TLV Type:

          IANA assigned TLV value

      A bit

          Indicates if Repair Path information is to be "added" or
          "removed". MUST be set to 1 to signal addition of the
          information, and set to signal addition of the information,
          and set to

      L Bit:

Bashandy              Expires September 5, 2012                [Page 6]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

          Indicates whether optional "Underlying Repair Label" [6] field
          is present or not. Must be set to 1 if the TLV also
          contains/encodes "Underlying Repair Label", else must be set
          to 0. This bit MUST be set to 0 when A bit is set to 0.

      P Bit:

         If set, then the label in the "Underlying Repair label" sub
         field MUST be pushed instead of swapped. The "P" bit has the
         same semantics of the "Push" flag in [6]. If the "L" bit is
         zero then the "P" bit MUST be set to zero.

      Reserved:

         MUST be zero on transmit and ignored in receipt

      Address Family

         Identical to the "Address Family" field used in encoding the
         Prefix FEC element value specified in Section 3.4.1 in [4]. May
         be different of the address family of the prefix in the FEC

      Repair PE Address

          The length of this field is dependent on the Address Family
          field. This is either the 4 octet IPv4 address or 16 octet
          IPv6 address of a host address belonging to repair PE. The
          encoding of the Repair PE Address is identical to the encoding
          of the value of the IPv4 or IPv6 Transport Address TLV
          specified in Section 3.5.2 in [4]. This field encodes the
          "Repair Next-hop" defined in [6].

      Underlying Repair Label (optional)

         If included in the TLV, it is a single label defined in
         accordance to Generic Label TLV specified in Section 3.4.2.1 in
         [4]. This field encodes the "Underlying Repair Label" defined
         in [6].

      Length

         The length (in octets) of the TLV following the "Length" field.
         For example, the length MUST be 8 with IPv4 Repair PE address
         or 20 with IPv6 Repair PE address when L bit is set to 0, and
         MUST be 12 and 24 octets otherwise for IPV4 and IPv6 address
         families, respectively.




Bashandy              Expires September 5, 2012                [Page 7]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012




   2.3. LDP Capability Negotiation

   This BGP Repair Path information is to be computed by an edge PE LSR
   under a user configuration control. Once computed, this information
   can be unsolicitedly sent to core P LSRs for edge PE node protection,
   and it is up to the receiving P LSR to store and use this information
   to protect the edge PE LSR.

   Given above procedures, no new LDP capability [RFC5561] negotiation
   is needed between PE and P LSRs to support this feature extensions.
   However, to ensure backward compatibility and deterministic behavior,
   it is required that this information be sent to only those P LSRs
   that support "Unrecognized Notification" capability as specified in
   [5]. This will ensure that these new status and TLV does not cause
   any issue at a receiving P LSR if not known or not supported, and be
   discarded in accordance with "Unrecognized Notification" procedures.

   2.4. BGP Repair Status in a LDP Notification message

   The general format of an LDP Notification message that carries
   information regarding BGP repair path is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Notification (0x0001)     |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Status TLV                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   BGP Repair Path Status TLV                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        FEC TLV                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 3 : LDP Notification message with BGP Repair Status

   The "Status TLV" status code is set to "BGP Repair Path status" to
   indicate that the message is used to convey BGP Repair Path
   information. When this status code is set, a Notification message
   MUST contain both "BGP Repair Status TLV" and a "FEC TLV" in the
   message.

   Since this notification does not refer to any particular message, the
   "Message ID" and "Message Type" fields in the "Status TLV" MUST be
   set to 0.

Bashandy              Expires September 5, 2012                [Page 8]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

   The "BGP Repair Path Status TLV" is encoded as described earlier.

   The FEC TLV MUST contain a single "Prefix FEC Element" that encodes
   the BGP nexthop information as host prefix. This field encodes the
   "Primary Next-hop" defined in [6].

3. BGP Repair Path Signaling Procedures

   To describe the signaling procedures clearly, let's first assume
   that:

   o  Protected edge LSR is PE1, Repair edge LSR is PE2 and repairing
      core LSR is P1 LSR router, and P2 is also a core LSR that does not
      support BGP Repair Path functionality.

   o  IPv4 Host addresses for PE1 and PE2 are A1 and A2 respectively.

   o  Protected BGP IPv4 prefix is P/m.

   o  BGP label assigned by PE2 for P/m is L2.

   o  P1 and P2 LSR support LDP "Unrecognized Notification" Capability.

   3.1. Signaling a BGP Repair Path

   An operator enables this feature on PE1 using a configuration knob.
   The PE1 computes Repair PE information (PE2 address A2, and PE2 BGP
   label L2) for a given BGP prefix P/m. PE1 encodes the LDP
   Notification to advertise the Repair path information to all those
   core LSR peers (including P1/P2 LSRs) who have advertised
   "Unrecognized Notification" Capability TLV for given LDP session.

   The PE1 LSR encodes the following TLVs:

       o "Status" TLV: status code is set to "BGP Repair Path status"
          and "Message Type" and Message ID fields set to 0.

       o "BGP Repair Path Status" TLV: This TLV is encoded with A-bit
          set to 1, L-bit set to 1, P-bit set to 0, Address Family set
          to 1 (IPv4), "Repair PE Address" field populated with A2, and
          "Repair PE's Label" field set to L2.

       o "FEC" TLV: This TLV is encoded with a single "Prefix FEC
          Element" whose Address Family is set to 1 (IPv4) to indicate
          IPV4 prefix, and prefix P/m encoded accordingly.

   After encoding these TLVs, PE1 LSR bundles them in an LDP
   Notification message, as shown in Figure 3, and sends them to its
   upstream core peer P1 and P2 LSRs.

Bashandy              Expires September 5, 2012                [Page 9]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

   On receipt of this information, P1 stores this information and uses
   this to fast reroute the BGP destined traffic to PE2 upon PE2
   node/connectivity failure detection. P2, on the other hand, does not
   recognize this new status in the LDP Notification message and hence
   discards it silently.

   In order to be able to protect primary BGP nexthops, it is required
   that the repairing P LSR (P1) must have a LSP terminating on Repair
   PE host prefix (as indicated by "Repair PE Address" field in the
   received "BGP Repair Path Status" TLV).

   3.2. Updating a BGP Repair Path

   The repair path information is identified by

       o the "primary next-hop" encoded in the "FEC TLV" shown in
          Figure 3 and,

       o the "Repair Next-hop" encoded in the "Repair PE Address" shown
          in Figure 2.

   Once a repair path has been signaled to P core LSR, it can be updated
   by simply sending another LDP Notification message using the
   procedures described in the previous section.

   Upon receipt of a new repair path information, the LDP receiver (P1
   LSR) MUST discard any previously learnt Repair information from the
   sending PE1 LSR, and update it with the most recently received.

   3.3. Withdrawing a BGP Repair Path

   Once a repair path has been signaled to P core LSR, it can be
   withdrawn by simply sending another LDP Notification message using
   the procedures described in the previous section with following
   changes:

       o Set A-bit, L-bit, and P-bit in "BGP Repair Path Status" TLV to
          0

       o No "Underlying Repair Label" field included

   Upon receipt of a withdrawal of a repair path, the LDP receiver (P1
   LSR) MUST discard any previously learnt Repair information from the
   sending PE1 LSR for a given BGP prefix.

4. Security Considerations

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

Bashandy              Expires September 5, 2012               [Page 10]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

5. IANA Considerations

   This document introduces the following new protocol elements that
   require code point assignment by IANA:

   o  "BGP Repair Path status" status code from "LDP Status Code Name
      Space" registry (requested code point: 0x00000050)

   o  "BGP Repair Path Status TLV" from "LDP TLV Type Name Space"
      registry (requested code point: 0x050F)

6. Conclusions

   This document proposes a an LDP extension that allows an egress PE
   to advertise a repair path consisting of a repair egress PE and an
   underlying label to repairing core router. Advertising this
   information to core routers allows core routers to provide FRR
   protection against primary egress PE node failure while keeping the
   core BGP-free.

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]   Anderson, L., Minei, I., and Thomas, B., "LDP
         Specifications", RFC 5036, October 2007

   [5]   R. Asati, P. Mohapatra, E. Chen, B. Thomas, " Signaling LDP
         Label Advertisement Completion", RFC5919, August 2010

   7.2. Informative References

   [6]   Bashandy, A., Pithawala, B., and Patel, K., "Scalable BGP FRR
         Protection against Edge Node Failure", draft-bashandy-bgp-
         edge-node-frr-02.txt, January 2012

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


Bashandy              Expires September 5, 2012               [Page 11]


Internet-Draft     LDP Extension for FRR Edge Node           March 2012

   [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]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
         Reroute: Loop-Free Alternates", RFC 5286, September 2008.

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

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

   [14]  Rosen, E., Biswanathan, A., and Callon, A. "Multiprotocol
         Label Switching Architecture", RFC3031, January 2001

8. Acknowledgments

   Special thanks to Keyur Patel and Alton Lo for the valuable help.

   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

   Kamran Raza
   Cisco Systems,
   2000 Innovation Dr.,   Kanata, ON K2K 3E8, Canada
   EMail: skraza@cisco.com











Bashandy              Expires September 5, 2012               [Page 12]


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