Internet DRAFT - draft-bashandy-isis-bgp-edge-node-frr
draft-bashandy-isis-bgp-edge-node-frr
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]
