Network Working Group Z. Li Internet-Draft N. Wu Intended status: Standards Track Huawei Technologies Expires: April 18, 2013 October 15, 2012 Routing Extension for Fast-Reroute Using Maximally Redundant Trees draft-li-rtgwg-igp-ext-mrt-frr-00 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 April 18, 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 Li & Wu Expires April 18, 2013 [Page 1] Internet-Draft Routing Extansion for MRT FRR October 2012 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 . . . . . . . . . . . . . . . . . . . . . 10 6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Li & Wu Expires April 18, 2013 [Page 2] Internet-Draft Routing Extansion for MRT FRR October 2012 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 procotols for fast reoute 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 & Wu Expires April 18, 2013 [Page 3] Internet-Draft Routing Extansion for MRT FRR October 2012 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 speicifies the MT-ID of the primary topology. -- 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. -- 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. -- 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 change the algorithm used or use different ones in different Li & Wu Expires April 18, 2013 [Page 4] Internet-Draft Routing Extansion for MRT FRR October 2012 networks. It may be desirable to advertise a list ordered by preference to allow transitions. +-+-+-+-+-+-+-+-+ |0|1|*|*|*|*|*|*| +-+-+-+-+-+-+-+-+ Bit0 - LP-BIT Bit1 - SPF-BIT -- MRT Fd Mechanism: 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 ([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 & Wu Expires April 18, 2013 [Page 5] Internet-Draft Routing Extansion for MRT FRR October 2012 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 speicifies the MT-ID of the primary topology. -- 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. -- 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. -- 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. +-+-+-+-+-+-+-+-+ |0|1|*|*|*|*|*|*| +-+-+-+-+-+-+-+-+ Bit0 - LP-BIT Bit1 - SPF-BIT Li & Wu Expires April 18, 2013 [Page 6] Internet-Draft Routing Extansion for MRT FRR October 2012 -- 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 supoort MRT FRR, it MUST NOT send the sub-TLV. Since the advertisement scope of the MRT sub-TLV is level-wide, when its advertised the D-Bit and S-Bit of the Router Capability TLV MUST be set as 0. If other sub-TLVs in the Router Capablity 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 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 mechnisms that the router can support. The corresponding bit MUST be set as 1 if it is supported. Li & Wu Expires April 18, 2013 [Page 7] Internet-Draft Routing Extansion for MRT FRR October 2012 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 nexthops 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. 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 advertise of leak to other levels. If the receiver router can not support MRT, it MUST ignore MRT-FRR sub-TLV. If mutiple 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 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} idendified 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 machanism, the receiver router not only check if there is intersection, but also check if the Li & Wu Expires April 18, 2013 [Page 8] Internet-Draft Routing Extansion for MRT FRR October 2012 interseciton 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 pripority 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 nexthops 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 supoort 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 mechnisms 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 higher than the current root, the MRT island will recalculate GADAG and new Blue/Red nexthops 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. 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. Li & Wu Expires April 18, 2013 [Page 9] Internet-Draft Routing Extansion for MRT FRR October 2012 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} idendified 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 machanism, the receiver router not only check if there is intersection, but also check if the interseciton 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 pripority 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 nexthops 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- 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 Li & Wu Expires April 18, 2013 [Page 10] Internet-Draft Routing Extansion for MRT FRR October 2012 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.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. [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. Li & Wu Expires April 18, 2013 [Page 11] Internet-Draft Routing Extansion for MRT FRR October 2012 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 Li & Wu Expires April 18, 2013 [Page 12]