Network Working Group                                       A. Bashandy
Internet Draft                                            Cisco Systems
Intended status: Standards Track
Expires: February 2013                                  August 31, 2012

    IS-IS Extension for BGP FRR Protection against Edge Node Failure
              draft-bashandy-isis-bgp-edge-node-frr-01.txt


Abstract

Consider a BGP free core scenario where traffic is tunneled between
edge routers. Suppose the edge BGP speakers PE1, PE2,..., PEn know
about a prefix P/m via the external routers CE1, CE2,..., CEm.  If
the edge router PEi crashes or becomes totally disconnected from the
core, it desirable for a core router "P" that is carrying traffic to
the failed edge router PEi to immediately restore traffic by re-
routing packets originally tunneled to PEi and destined to the prefix
P/m to one of the other edge routers that advertised P/m, say PEj,
until BGP re-converges. If the packets originally flowing to the
failed edge router PEi are labeled, then the repairing core router P
router may need to swap, push, or pop the label advertised by the
failed edge router PEi with another label before re-routing the
packet through an LSP terminating PEj so that PEj can correctly
forward the packet. The document proposes an extension to IS-IS
protocol to inform core routers about the repair edge router PEj and,
for labeled packets, the label that needs to be pushed/swapped before
sending the packet into the tunnel terminating on 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.

   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 February 31, 2013                [Page 1]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

   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 February 31, 2013.

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 IS-IS Extension...................................5
   3. Operation of the Repair Egress Path TLVs.......................5
      3.1. Structure of the Repair Egress Path TLVs..................5
      3.2. Semantics of the Repair Path TLV..........................7
   4. Example........................................................8
   5. Security Considerations........................................9
   6. IANA Considerations............................................9
   7. Conclusions....................................................9
   8. References.....................................................9
      8.1. Normative References......................................9
      8.2. Informative References...................................10
   9. Acknowledgments...............................................10
   Appendix A. Modification History.................................11
      A.1. Changes from 00..........................................11

Bashandy              Expires February 31, 2013                [Page 2]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012


1. Introduction

   In a BGP free core, where traffic is tunneled between edge routers,
   BGP 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 router assigns local labels to
   prefixes and associates the local label with each advertised prefix
   such as L3VPN [10], 6PE [11], and Softwire [9]. 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 sends the packet through a tunnel
   to that egress router. If the prefix P/m is a labeled prefix, the
   ingress router pushes the label advertised by the egress router
   before sending the packet into the tunnel terminating on 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 and/or the label 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 [8]. Another more common and widely deployed
   scenario is L3VPN [10] with multi-homed VPN sites. As an example,
   consider the L3VPN topology depicted in Figure 1.


























Bashandy              Expires February 31, 2013                [Page 3]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012


                                      PE1 .............+
                                                       |
                                              +--------+------------+
                                              |                     |
                                              |   VPN 1 Network     |
                                              |                     |
                                              +---+-----------------+
                                                  |
                                          /----- CE1....... VPN prefix
                                         /                (10.0.0.0/8)
                                        /
         BGP-free core       P--------PE0
                                        \
                                         \                (20.0.0.0/8)
                                          \------CE2....... VPN prefix
                                                  |
                                              +---+-----------------+
                                              |                     |
                                              |   VPN 2 Network     |
                                              |                     |
                                              +--------+------------+
                                                       |
                                      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

   Refer to [7].



Bashandy              Expires February 31, 2013                [Page 4]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

   1.3. Problem definition

   The general problem for the example shown in Section 1.  is
   specified in [7]. The objective of this document is to specify an
   IS-IS [2] [3][4][5] extension to let the primary egress PE inform
   repairing core router(s) about the repair path [7] in a BGP-free
   core for both labeled and unlabeled protected prefixes. Other
   problems, such as determining the repair PE or the repair path or
   failure detection, are beyond the scope of this document.

2. The Proposed IS-IS Extension

   This document specifies two new TLVs, namely "IPv4 Repair Egress
   Path" and "IPv6 Repair Egress Path". The new IPv4 and IPv6 Repair
   Egress Path TLVs identify the primary egress next-hop and its
   corresponding "Repair Egress Path" specified in [7] for IPv4 primary
   next-hop [7] and IPv6 primary next-hop [7], respectively

   The encoding of the proposed TLVs is as follows

   TLV Type (Value TBD):

      1 octet identifying the IPv4 or IPv6 Repair Egress Path TLV code
      point. The code point value is assigned by IANA from the IANA "IS-
      IS TLV Code point Registry".

      The code point for "IPv4 Repair Egress Path" means the "Primary
      next-hop" sub-field contains an IPv4 address. The code point for
      "IPv6 Repair Egress Path" means "Primary next-hop" sub-field
      contains an IPv6 address.

   Length:

      The length of the value field in multiples of 1 octet

   Value (variable length):

      The value specifies the IPv4 Repair Egress Path. Details in
      Section 3.

3. Operation of the Repair Egress Path TLVs

   3.1. Structure of the Repair Egress Path TLVs

   The "Value" field of the proposed TLVs contains more than one "repair
   tuple". Each "repair tuple" consists of the following sub-fields in
   the following order

   o  L bit

Bashandy              Expires February 31, 2013                [Page 5]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

         If set, then the repair path contains the underlying repair
         label

   o  P bit

         If set, then the label in the "Underlying Repair label" sub-
         field MUST be pushed instead of swapped. More details about
         this field in Section 3.2.

   o  AF-different Bit (D bit for simplicity)

        If set, the "Primary next-hop" sub-field contains an IPv4
        address while the "Repair Next-hop" contains an IPv6 address or
        vice versa.

   o  MT bit (M bit for simplicity)

        If set, then the sub-fields " MTID-Num" and "MT-List" exist

   o  Reserved (Mandatory)

        This is a 4 bits field that MUST be zero by transmitter(s) and
        ignored by receiver(s)

   o  Primary next-hop (Mandatory)

        This is either a 4 octet IPv4 address or 16 octet IPv6 address
        representing the protected primary next-hop as defined in [7].

   o  Repair next-hop (Mandatory)

        This is the repair next-hop as defined in [7]. It has the same
        syntax as "Primary next-hop" sub-field

   o  Underlying Repair label (optional)

        If the L bit is set, then this field MUST contain the
        underlying repair label as defined in [7]. The length of this
        field is 3 octets.

   o  MTID-Num (Optional, 1 octet)

        The number of elements in the sub-field "MT-List". If the "MT"
        bit is set, then this field MUST exist and contain a value
        greater than zero

   o  MT-List (optional, variable length)



Bashandy              Expires February 31, 2013                [Page 6]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

        The size of the field is multiple of 2 octets. It represents a
        list of topology IDs. Each entry in the list represents a
        topology ID and has the same format and semantics of the "R"
        bits and the "MT ID" field in TLVs 235 and 237 defined in [6].
        The semantics of the "MT-List" are specified in Section 3.2. If
        the "MT" bit is set, then this field MUST exist and contain at
        least one entry.

   The "value" field of the proposed "IPv4/IPv6 Repair Egress Path" TLV
   MAY contain more than one "repair tuple", each consisting of the sub-
   fields defined in this section. See Section 4. provides an example of
   how the "value" field may look like.

   3.2. Semantics of the Repair Path TLV

   The Repair egress Path TLV is an implementation of the repair path
   defined in [7]. This section explains the IS-IS specific use.

   The "Primary next-hop" and "Repair next-hop" subfield in specified in
   this document identifies the exit point of the primary and repair
   tunnels [7], respectively.

   The semantics of the "P" bit is identical to the semantics of the
   "Push" flag in [7].

   The same values of "Primary next-hop" and "Repair next-hop" subfield
   MUST NOT appear more than once in the "IPv4/IPv6 egress repair path"
   TLVs in the same LSP

   The "MT-LIST" represents a list of topology IDs to be used to
   calculate the path taken by the repair tunnel. The semantics of the
   "MT-LIST" sub-field is as follows. If the repairing router decides to
   calculate a repair tunnel towards the "Repair next-hop", then the
   path taken by the tunnel SHOULD be calculated according to one of the
   topologies specified in the list "MT-LIST". If the path taken by the
   repair tunnel does not satisfy the conditions specified in [7], then
   the repairing not SHOULD NOT install this repair tunnel in the
   forwarding plane.

   The addresses specified in the "Primary next-hop" and "Repair next-
   hop" sub-fields SHOULD be covered by (possibly different)
   reachability TLVs. Furthermore, if the "MT-LIST" sub-field exists,
   then the prefix covering the "Repair next-hop" SHOULD be advertised
   in a TLV of type 235 or 237 and the "MT ID" sub-field value in the
   235 or 237 TLV SHOULD be identical to one of the topology IDs in the
   "MT-LIST" sub-field defined in this document.

   This document does NOT require that the address family of the primary
   and repair next-hop be identical. However an implementation MAY

Bashandy              Expires February 31, 2013                [Page 7]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

   require that the "Primary Next-Hop" and "Repair Next-hop" fields
   belong to the same address family. Thus a core P router MAY ignore
   the "IPv4/IPv6 Repair Egress Path" TLVs if the "AF-different" bit is
   set. Similarly, a primary egress PE MAY NOT advertise the "IPv4/IPv6
   Repair Egress Path" TLVs with the field "AF-Different" set.

   For a protected Primary BGP next-hop allocated according to [7], the
   TLVs defined in this document support no more than one repair egress
   path per repair tuple. However a protected PE MAY advertise more than
   one repair path for the same protected next-hop by advertising more
   than one "repair tuple" for the same primary NH but with different
   repair paths. If a repairing core router receives more than one
   repair path for the same protected next-hop, the repairing core
   router MAY choose one repair path. The method of choosing a repair
   path is beyond the scope of this document.

4. Example

   Figure 2 illustrates an example for the "value" field "IPv4 Repair
   Egress Path".

                                                      Number of Octets
                    +--+--+--+--+--------------------+
                    |0 |0 |0 |0 |     Zero           |      1
                    +--+--+--+--+--------------------+
                    |           1.1.1.1              |      4
                    +--------------------------------+
                    |           2.2.2.2              |      4
                    +--+--+--+--+--------------------+
                    |1 |0 |0 |1 |     Zero           |      1
                    +--+--+--+--+--------------------+
                    |           1.1.1.1              |      4
                    +--------------------------------+
                    |           3.3.3.3              |      4
                    +--------------------------------+
                    |             0x20b1             |      3
                    +--------------------------------+
                    |               2                |      1
                    +--+--+--+--+--------------------+
                    |0 |0 |0 |0 |  0x2b1             |      2
                    +--+--+--+--+--------------------+
                    |0 |0 |0 |0 |  0x1ac             |      2
                    +--+--+--+--+--------------------+

    Figure 2 Example of "Value" field for "IPv4 Repair Egress Path" TLV





Bashandy              Expires February 31, 2013                [Page 8]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

   Figure 2 illustrates the case where "IPv4 Repair Egress Path" has two
   "repair tuples". The first one represents primary and repair path
   without MT support and without any label. The second repair tuple is
   the case where the repair path is labeled using the underlying repair
   label 0x20b1 and the repair next-hop belongs to two topologies.

5. Security Considerations

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

6. IANA Considerations

   This document introduces two new TLVs that require code point
   assignment by:

   o  IPv4 Repair Egress Path TLV type to be assigned from the IANA "IS-
      IS TLV Codepoints Registry".

   o  IPv6 Repair Egress Path TLV type to be assigned from the IANA "IS-
      IS TLV Codepoints Registry".

7. Conclusions

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

8. References

   8.1. Normative References

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

   [2]   International Organization for Standardization, "Intermediate
         system to Intermediate system intra-domain routing
         information exchange protocol for use in conjunction with the
         protocol for providing the connectionless-mode Network
         Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov
         2002.

   [3]   Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
         environments", RFC 1195, December 1990.



Bashandy              Expires February 31, 2013                [Page 9]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

   [4]   Li, T., and Smit, H., "IS-IS Extensions for for Traffic
         Engineering", RFC5305, October 2008

   [5]   Hopps, C. "Routing IPv6 with IS-IS", RFC5308, October 2008

   [6]   Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
         Topology (MT) Routing in IS-IS", RFC 5120, February 2008.

   8.2. Informative References

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

   [8]   Marques,P., Fernando, R., Chen, E, Mohapatra, P., Gredler,
         H., "Advertisement of the best external route in BGP", draft-
         ietf-idr-best-external-05.txt, January 2012.

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

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

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

9. Acknowledgments

   Special thanks to Les Ginsberg, Keyur Patel, and Anton Smirnov 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









Bashandy              Expires February 31, 2013               [Page 10]


Internet-Draft       IS-IS for BGP Edge Node FRR            August 2012

Appendix A.                 Modification History

A.1. Changes from 00

   Some editorial Changes













































Bashandy              Expires February 31, 2013               [Page 11]