Internet DRAFT - draft-li-rtgwg-igp-ext-mrt-frr
draft-li-rtgwg-igp-ext-mrt-frr
Network Working Group Z. Li
Internet-Draft N. Wu
Intended status: Standards Track Q. Zhao
Expires: August 29, 2013 Huawei Technologies
February 25, 2013
Routing Extension for Fast-Reroute Using Maximally Redundant Trees
draft-li-rtgwg-igp-ext-mrt-frr-01
Abstract
The document proposes the routing protocol extension and procedures
to support fast reroute using maximally redundant trees.
Requirements Language
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 29, 2013.
Copyright Notice
Copyright (c) 2013 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
Li, et al. Expires August 29, 2013 [Page 1]
Internet-Draft Routing Extension for MRT FRR February 2013
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MRT-FRR TLV Format . . . . . . . . . . . . . . . . . . . . . . 3
3.1. IS-IS MRT-FRR Sub-TLV Format . . . . . . . . . . . . . . . 3
3.2. OSPF MRT FRR TLV Format . . . . . . . . . . . . . . . . . 5
4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7
4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Sending . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Receiving . . . . . . . . . . . . . . . . . . . . . . 8
4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Sending . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Receiving . . . . . . . . . . . . . . . . . . . . . . 10
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Li, et al. Expires August 29, 2013 [Page 2]
Internet-Draft Routing Extension for MRT FRR February 2013
1. Introduction
[I-D.ietf-rtgwg-mrt-frr-architecture]describes the architecture based
on Maximally Redundant Trees (MRT) to provide 100% coverage for FRR
of unicast traffic. Protocol extensions and considerations are also
been proposed. The document defines the extension of routing
protocols for fast reroute using maximally redundant trees. The
detailed procedures are defined based the extension.
2. Terminology
GADAG: Generalized ADAG - a graph that is the combination of the
ADAGs of all blocks.
Maximally Redundant Trees (MRT): A pair of trees where the path from
any node X to the root R along the first tree and the path from the
same node X to the root along the second tree share the minimum
number of nodes and the minimum number of links. Each such shared
node is a cut-vertex. Any shared links are cut-links. Any RT is an
MRT but many MRTs are not RTs.
3. MRT-FRR TLV Format
3.1. IS-IS MRT-FRR Sub-TLV Format
IS-IS MRT FRR sub-TLV is defined to advertise necessary information
related with MRT FRR. It is an optional sub-TLV which can be
advertised in the router capability TLV([RFC4971]) . The information
has only level-wide scope. If there is no MRT FRR sub-TLV
advertised, that router should be seen as that it does not support
MRT FRR.
The IS-IS MRT FRR sub-TLV is composed of 1 octet for the type, 1
octet specifying the TLV length and a value field. The IS-IS MRT FRR
sub-TLV format (Figure 1) is as follows:
TYPE: TBD
LENGTH: 12
Li, et al. Expires August 29, 2013 [Page 3]
Internet-Draft Routing Extension for MRT FRR February 2013
No. of Octets
+--------------------------------+
|R|R|R|R| Primary MT ID | 2
+--------------------------------+
|R|R|R|R| Blue MRT MT ID | 2
+--------------------------------+
|R|R|R|R| Red MRT MT ID | 2
+--------------------------------+
| MRT Capabilities Available | 2
+----------------+---------------+
|MRT Algorithm ID| 1
+----------------+
|MRT Fd Mechanism| 1
+----------------+---------------+
| GADAG Root Election Priority | 2
+--------------------------------+
Figure 1 IS-IS MRT FRR Sub-TLV Format
The IS-IS MRT FRR sub-TLV is made of the following fields:
-- Primary MT-ID: This specifies the MT-ID of the primary topology,
12 bits.
-- Blue MRT MT-ID: This specifies the MT-ID to be associated with the
Blue MRT forwarding topology. It is needed for use in signaling.
All routers in the MRT Island MUST agree on a value, 12 bits.
-- Red MRT MT-ID: This specifies the MT-ID to be associated with the
Red MRT forwarding topology. It is needed for use in signaling. All
routers in the MRT Island MUST agree on a value, 12 bits.
-- MRT Capabilities Available: This specifies the set of capabilities
that the router can support.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|*| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit0 - MRT-BIT
Bit1 - IP-BIT
Bit2 - LDP-BIT
Bit3 - PIM-BIT
Bit4 - PIMG-BIT
Bit5 - mLDP-BIT
Bit6 - mLDPG-BIT
-- MRT Algorithm ID: This identifies the particular MRT algorithm
used by the router. By having an Algorithm ID, it is possible to
Li, et al. Expires August 29, 2013 [Page 4]
Internet-Draft Routing Extension for MRT FRR February 2013
change the algorithm used or use different ones in different
networks. It may be desirable to advertise a list ordered by
preference to allow transitions.
+-+-+-+-+-+-+-+-+
|0|1|2|*|*|*|*|*|
+-+-+-+-+-+-+-+-+
Bit0 - LP-BIT
Bit1 - SPF-BIT
Bit2 - HYBRID-BIT
-- MRT Fd Mechanism: This specifies which forwarding mechanisms the
router supports. If IP-in-IPv4 or IP-in-IPv6 is used as forwarding
mechanisms for IP, Red MRT Loopback Address and Blue MRT Loopback
Address should be advertised by the Multi-Topology Reachable IPv4/
IPv6 Prefixes TLV ([RFC5120]).
+-+-+-+-+-+-+-+-+
|0|*|2|3|4|*|*|*|
+-+-+-+-+-+-+-+-+
Bit0: LDP Destination-Topology Label
Bit2: IP-in-IPv4
Bit3: IP-in-IPv6
Bit4: Encode MT-ID in Labels
-- GADAG Root Election Priority: This specifies the priority of the
router for being used as the GADAG root of its island. A GADAG root
is elected from the set of routers with the highest priority; ties
are broken based upon highest System ID. The sensitivity of the MRT
Algorithms to GADAG root selection is still being evaluated. This
provides the network operator with a knob to force particular GADAG
root selection.
3.2. OSPF MRT FRR TLV Format
OSPF MRT FRR TLV is defined to advertise necessary information
related with MRT FRR. It is an optional TLV which can be advertised
in the OSPF router information LSA([RFC4970]) . The information has
only area-wide scope. If there is no MRT FRR TLV advertised, that
router should be seen as that it does not support MRT FRR.
The OSPF MRT FRR TLV has the following format:
TYPE: TBD
LENGTH: 12
Li, et al. Expires August 29, 2013 [Page 5]
Internet-Draft Routing Extension for MRT FRR February 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri MT ID | Blue MRT MT ID| Red MRT MT ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRT Capabilities Available | MRT Algr ID | MRT Fd Mecha |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GADAG Root Election Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 OSPF MRT FRR TLV Format
The OSPF MRT FRR TLV is made of the following fields:
-- Pri MT-ID: This specifies the MT-ID of the primary topology. It
is a 7-bit-field since AS-External-LSAs use the high-order bit in the
MT-ID field (E-bit) for the external metric-type.
-- Blue MRT MT-ID: This specifies the MT-ID to be associated with the
Blue MRT forwarding topology. It is needed for use in signaling.
All routers in the MRT Island MUST agree on a value, 7 bits.
-- Red MRT MT-ID: This specifies the MT-ID to be associated with the
Red MRT forwarding topology. It is needed for use in signaling. All
routers in the MRT Island MUST agree on a value, 7 bits.
-- MRT Capabilities Available: This specifies the set of capabilities
that the router can support.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|*| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit0 - MRT-BIT
Bit1 - IP-BIT
Bit2 - LDP-BIT
Bit3 - PIM-BIT
Bit4 - PIMG-BIT
Bit5 - mLDP-BIT
Bit6 - mLDPG-BIT
-- MRT Algr ID: This identifies the particular MRT algorithm used by
the router. By having an Algorithm ID, it is possible to change the
algorithm used or use different ones in different networks. It may
be desirable to advertise a list ordered by preference to allow
transitions.
Li, et al. Expires August 29, 2013 [Page 6]
Internet-Draft Routing Extension for MRT FRR February 2013
+-+-+-+-+-+-+-+-+
|0|1|2|*|*|*|*|*|
+-+-+-+-+-+-+-+-+
Bit0 - LP-BIT
Bit1 - SPF-BIT
Bit2 - HYBRID-BIT
-- MRT Fd Mecha: This specifies which forwarding mechanisms the
router supports. If IP-in-IPv4 or IP-in-IPv6 are used as forwarding
mechanisms for IP, Red MRT Loopback Address and Blue MRT Loopback
Address should be advertised by the Multi-Topology Reachable IPv4/
IPv6 Prefixes TLV ([RFC4915]).
+-+-+-+-+-+-+-+-+
|0|*|2|3|4|*|*|*|
+-+-+-+-+-+-+-+-+
Bit0: LDP Destination-Topology Label
Bit2: IP-in-IPv4
Bit3: IP-in-IPv6
Bit4: Encode MT-ID in Labels
-- GADAG Root Election Priority: This specifies the priority of the
router for being used as the GADAG root of its island. A GADAG root
is elected from the set of routers with the highest priority; ties
are broken based upon highest Router ID. The sensitivity of the MRT
Algorithms to GADAG root selection is still being evaluated. This
provides the network operator with a knob to force particular GADAG
root selection.
4. Elements of Procedure
4.1. IS-IS
4.1.1. Sending
MRT FRR sub-TLV is encapsulated in the Router Capability TLV and
advertised through LSP PDU in the level-wide. MRT FRR sub-TLV is an
optional TLV. If the router cannot support MRT FRR, it MUST NOT send
the sub-TLV. Since the advertisement scope of the MRT sub-TLV is
level-wide, when it is advertised the D-Bit and S-Bit of the Router
Capability TLV MUST be set as 0. If other sub-TLVs in the Router
Capability TLV need different values for the two bits, there MUST be
an independent Router Capability TLV for the MRT FRR sub-TLV.
If the router can support multiple MRT FRR instances, there can be
multiple MRT FRR sub-TLVs to be advertised. In these sub-TLVs and
Li, et al. Expires August 29, 2013 [Page 7]
Internet-Draft Routing Extension for MRT FRR February 2013
there are different primary MT-IDs and associated Red/Blue MT-IDs.
MT-IDs advertised by the MRT FRR sub-TLV MUST NOT be the reserved
values for MT-ID([RFC5120]). In one MRT FRR sub-TLV, the Blue MT-ID
MUST be different from the Red MT-ID.
MRT FRR sub-TLV MUST advertise the actual MRT capabilities, MRT
algorithms and MRT forwarding mechanisms that the router can support.
The corresponding bit MUST be set as 1 if it is supported.
Otherwise, it MUST be set as 0.
GADAG Root Election Priority is a 16-bit unsigned integer which
default value is set to 0x8000. The higher numerical value means the
higher priority. GADAG Root Election is ordered with the priority
and the IS-IS system ID is used as the tiebreaker. That is, if the
priority is the same, the router with higher IS-IS system ID will be
chosen. When a new MRT-capable router is added and its priority is
higher than the current root, the MRT island will recalculate GADAG
and new Blue/Red next hops for each prefix in the primary topology.
If the current root fails, the new root will be re-elected and MRT
calculation will be done according to the new root. Routers that are
marked as overloaded([RFC3787]) is not qualified as candidate for
root selection.
When MRT related information is changed in the router or existing
IS-IS LSP mechanisms are triggered for refresh or update, MRT sub-TLV
MUST be advertised with LSP.
4.1.2. Receiving
MRT capability SHOULD NOT affect the peer setup and the routing
calculation of the default SPF topology.
MRT FRR sub-TLV should be validated like other sub-TLVs when
received. MRT FRR sub-TLV is also taken for the checksum calculation
and authentication.
If MRT FRR sub-TLV is received and the D-Bit and S-Bit of the router
capability TLV may be not 0, MRT FRR sub-TLV MUST NOT leak to other
levels. If the receiver router can not support MRT, it MUST ignore
MRT FRR sub-TLV.
If multiple MRT FRR sub-TLVs are received in one LSP, it means
multiple MRT instances are supported by the sender router. If the
MT-ID conflict is found in the multiple MRT FRR sub-TLVs, the
associated sub-TLVs MUST be ignored.
The MRT capability field, the MRT algorithm field and the MRT
forwarding mechanism field MUST NOT be 0. If one of these field is
Li, et al. Expires August 29, 2013 [Page 8]
Internet-Draft Routing Extension for MRT FRR February 2013
0, the sub-TLV MUST be ignored.
According to the group {primary MT-ID, the Red MRT MT-ID and the Blue
MRT MT-ID} identified by the received MRT FRR sub-TLV, the receiver
router will take the MRT capability for intersection. If there is no
intersection, the router will stop processing for the group. For the
MRT algorithm, the receiver router will also take it for
intersection. If there is no intersection, the router will stop
processing. For the MRT forwarding mechanism, the receiver router
not only check if there is intersection, but also check if the
intersection found can satisfy the requirement of the MRT capability
intersection.
After the intersection is found for the group {primary MT-ID, the Red
MRT MT-ID and the Blue MRT MT-ID}, the receiver router will elect the
root node according to the GADAG Root Election Priority. If there
are updates about the priority for existing MRT FRR sub-TLV or the
new MRT FRR sub-TLV is received or the current root node fails, the
receiver will recalculate GADAG and new Blue/Red next hops for each
prefix in the primary topology.
4.2. OSPF
4.2.1. Sending
MRT FRR TLV is encapsulated in the router information LSA whose
opaque type is 10 advertised in the area-wide. MRT FRR TLV is an
optional TLV. If the router can not support MRT FRR, it MUST NOT
send the TLV.
If the router can support multiple MRT FRR instances, there can be
multiple MRT FRR TLVs to be advertised. In these TLVs and there are
different primary MT-IDs and associated Red/Blue MT-IDs. MT-IDs
advertised by the MRT FRR TLV MUST NOT be the reserved values for
MT-ID([RFC4915]). In one MRT FRR TLV, the Blue MT-ID MUST be
different from the Red MT-ID.
MRT FRR TLV MUST advertise the actual MRT capabilities, MRT
algorithms and MRT forwarding mechanisms that the router can support.
The corresponding bit MUST be set as 1 if it is supported.
Otherwise, it MUST be set 0.
GADAG Root Election Priority is a 16-bit unsigned integer which
default value is set to 0x8000. The higher numerical value means the
higher priority. GADAG Root Election is ordered with the priority
and the OSPF Router ID is used as the tiebreaker. That is, if the
priority is the same, the router with higher OSPF Router ID will be
chosen. When a new MRT-capable router is added and its priority is
Li, et al. Expires August 29, 2013 [Page 9]
Internet-Draft Routing Extension for MRT FRR February 2013
higher than the current root, the MRT island will recalculate GADAG
and new Blue/Red next hops for each prefix in the primary topology.
If the current root fails, the new root will be re-elected and MRT
calculation will be done according to the new root. Routers that are
marked as stub router([RFC3137]) are not qualified as candidate for
root selection.
When MRT related information is changed in the router or existing
OSPF LSA mechanisms are triggered for refresh or update, MRT TLV MUST
be advertised with LSA.
4.2.2. Receiving
MRT capability SHOULD NOT affect the neighbor setup and the routing
calculation of the default SPF topology.
MRT FRR TLV should be validated like other TLVs when received. MRT
FRR TLV is also taken for the checksum calculation and
authentication.
The MRT capability field, the MRT algorithm field and the MRT
forwarding mechanism field MUST NOT be 0. If one of these field is
0, the TLV MUST be ignored.
According to the group {primary MT-ID, the Red MRT MT-ID and the Blue
MRT MT-ID} identified by the received MRT FRR TLV, the receiver
router will take the MRT capability for intersection. If there is no
intersection, the router will stop processing for the group. For the
MRT algorithm, the receiver router will also take it for
intersection. If there is no intersection, the router will stop
processing. For the MRT forwarding mechanism, the receiver router
not only check if there is intersection, but also check if the
intersection found can satisfy the requirement of the MRT capability
intersection.
After the intersection is found for the group {primary MT-ID, the Red
MRT MT-ID and the Blue MRT MT-ID}, the receiver router will elect the
root node according to the GADAG Root Election Priority. If there
are updates about the priority for existing MRT FRR TLV or the new
MRT FRR TLV is received ro the current root node fails, the receiver
will recalculate GADAG and new Blue/Red next hops for each prefix in
the primary topology.
5. Backward Compatibility
The MRT FRR TLVs defined in this document do not introduce any
interoperability issue. For OSPF, a router not supporting the MRT
Li, et al. Expires August 29, 2013 [Page 10]
Internet-Draft Routing Extension for MRT FRR February 2013
FRR TLV SHOULD just silently ignore the TLV as specified in
[RFC2370]. For an IS-IS, a router not supporting the MRT FRR sub-TLV
SHOULD just silently ignore the sub-TLV.
6. IANA Considerations
6.1. IS-IS
This document introduces a new sub-TLV for IS-IS. The type is to be
determined by IANA.
6.2. OSPF
This document introduces a new TLV for OSPF. The type is to be
determined by IANA.
7. Security Considerations
This routing extension is not currently believed to introduce new
security concerns.
8. Normative References
[I-D.enyedi-rtgwg-mrt-frr-algorithm]
Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan,
"Algorithms for computing Maximally Redundant Trees for
IP/LDP Fast- Reroute",
draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in
progress), October 2012.
[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Envedi, G., Csaszar, A.,
Konstantynowicz, M., White, R., and M. Shand, "An
Architecture for IP/LDP Fast-Reroute Using Maximally
Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01
(work in progress), March 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001.
[RFC3787] Parker, J., "Recommendations for Interoperable IP Networks
Li, et al. Expires August 29, 2013 [Page 11]
Internet-Draft Routing Extension for MRT FRR February 2013
using Intermediate System to Intermediate System (IS-IS)",
RFC 3787, May 2004.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", RFC 4971, July 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Nan Wu
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: eric.wu@huawei.com
Quintin Zhao
Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
US
Email: quintin.zhao@huawei.com
Li, et al. Expires August 29, 2013 [Page 12]
