Network Working Group Zhenbin Li Internet-Draft Tao Zhou Intended status: Informational Quintin Zhao Expires: October 28, 2013 Huawei Technologies Tianle Yang China Mobile April 26, 2013 Applicability of LDP Multi-Topology for Unicast Fast-reroute Using Maximally Redundant Trees draft-li-rtgwg-ldp-mt-mrt-frr-02 Abstract In this document, procedures' considerations on the applicability of LDP MT for unicast fast-reroute using MRT are provided. The behaviors of label allocation and label forwarding entry setup with LDP Multi-Topology and MRT fast-reroute are described in details. Different application scenarios of the combining of the LDP multi- topology(MT) and unicast fast-reroute using Maximally Redundant Trees(MRT) are also analyzed. 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 October 28, 2013. Copyright Notice Zhenbin Li, et al. Expires October 28, 2013 [Page 1] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 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 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. Operation Procedures . . . . . . . . . . . . . . . . . . . . 4 3.1. Routing Calculation . . . . . . . . . . . . . . . . . . . 4 3.2. Label Distribution . . . . . . . . . . . . . . . . . . . 5 3.3. Forwarding Entry Creation . . . . . . . . . . . . . . . . 5 3.4. Switchover and Re-Convergence . . . . . . . . . . . . . . 5 3.5. Switchback . . . . . . . . . . . . . . . . . . . . . . . 6 4. Application Scenario Analysis . . . . . . . . . . . . . . . . 6 4.1. 2-Connected Network . . . . . . . . . . . . . . . . . . . 6 4.2. Non-2-Connected Network . . . . . . . . . . . . . . . . . 10 4.3. Proxy Node . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Inter-Area and Inter-AS . . . . . . . . . . . . . . . . . 11 4.5. Partial Deployment . . . . . . . . . . . . . . . . . . . 14 4.6. LDP over TE . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. IP-Only Network . . . . . . . . . . . . . . . . . . . . . 16 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 5.1. IGP MT and LDP MT . . . . . . . . . . . . . . . . . . . . 16 5.2. Simplified Provision . . . . . . . . . . . . . . . . . . 17 5.3. IGP Multi-process . . . . . . . . . . . . . . . . . . . . 18 5.4. Multiple IGP . . . . . . . . . . . . . . . . . . . . . . 21 5.5. Label Space . . . . . . . . . . . . . . . . . . . . . . . 22 5.6. Proxy Egress . . . . . . . . . . . . . . . . . . . . . . 22 5.7. Policy Control . . . . . . . . . . . . . . . . . . . . . 22 5.8. Resource Allocations . . . . . . . . . . . . . . . . . . 23 5.9. LDP DOD . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Normative References . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Zhenbin Li, et al. Expires October 28, 2013 [Page 2] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 1. Introduction [I-D.ietf-rtgwg-mrt-frr-architecture] describes the architecture based on Maximally Redundant Trees (MRT) to provide 100% coverage for fast-reroute of unicast traffic. LDP multi-topology [I-D.ietf-mpls-ldp-multi-topology] has been proposed to provide multi-topology-based unicast forwarding in the architecture. Guidance is provided for different application scenarios to improve the applicability. The analysis of the applicability of LDP MT for unicast fast-reroute using MRT is provided. The procedures are described and typical examples are provided based on LDP MT and MRT unicast FRR architecture. When LDP MT is combined with MRT FRR, follow advantages can be achieved: o Provide 100% coverage for unicast traffic. o The complexity of the algorithm is moderate in O(e) or o( e + n log n ). o Co-deployment with LFA to provide better protection coverage. o Simplify operation and management with few additional configurations and states introduced. o Inherit procedures of LDP to achieve high scalability. o Propose no additional change on label forwarding behavior in the forwarding plane to facilitate incremental deployment. 2. Terminology Some of terminologies defined in the [I-D.ietf-rtgwg-mrt-frr-architecture] are repeated here for the clarity of this document. o 2-connected: A graph that has no cut-vertices. This is a graph that requires two nodes to be removed before the network is partitioned. o 2-connected cluster: A maximal set of nodes that are 2-connected. o 2-edge-connected: A network graph where at least two links must be removed to partition the network. o cut-link: A link whose removal partitions the network. A cut-link by definition must be connected between two cut-vertices. If Zhenbin Li, et al. Expires October 28, 2013 [Page 3] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 there are multiple parallel links, then they are referred to as cut-links in this document if removing the set of parallel links would partition the network. o cut-vertex: A vertex whose removal partitions the network. o ECMP Equal cost multi-path: Where, for a particular destination D, multiple primary next-hops are used to forward traffic because there exist multiple shortest paths from S via different output layer-3 interfaces. o FIB Forwarding Information Base. The database used by the packet forwarder to determine what actions to perform on a packet. o LFA Loop-Free Alternate. A neighbor N, that is not a primary neighbor E, whose shortest path to the destination D does not go back through the router S. The neighbor N must meet the following condition: Distance_opt(N, D)[D]->[H]->[J] | | | | | ^ ^ ^ ^ | | | | | | | v | | | | v v v [R] [C] [G]--[I] [R] [C] [G]->[I] [R] [C] [G]<-[I] | | | | | ^ ^ ^ ^ | | | | | | | v | | | | v v | [A]--[B]--[F]---| [A]->[B]->[F]---| [A]<-[B]<-[F]<--| (a) Topology (b) Blue Topology (c) Red Topology Figure 1: 2-Connected Network According to the MRT calculation, for a specific destination H, there are following paths in different topologies for other nodes, Default Topology Blue Topology Red Topology R R->A->B->F->G->H R->A->B->F->G->H R->E->D->H A A->B->F->G->H A->B->F->G->H A->R->E->D->H B B->F->G->H B->F->G->H B->A->R->E->D->H Zhenbin Li, et al. Expires October 28, 2013 [Page 6] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 C C->B->F->G->H C->B->F->G->H C->D->H D D->C->B->F->G->H D->E->R->A->B->F D->H E E->D->C->B->F->G->H E->R->A->B->F->G->H E->D->H F F->G->H F->G->H F->B->A->R->E->D->H G G->H G->H G->F->B->A->R->E->D->H I I->G->H I->J->H I->G->F->B->A->R->E->D->H J J->H J->H J->I->G->F->B->A->R->E->D->H Figure 2: Paths in Different Topologies for H Note: 1. Assume that the metric of {E,R}, {D,H}, {R,C}, {G,I} and {F,I} is extreme high so that the route of the default topology is reasonable. 2. Assume tie-breaking rules determine that in blue topology the route from G to H chooses the path G->H instead of G->I->J->H. 3. Assume tie-breaking rules determine that in red topology the route from I to H chooses the path I->G->F->B->A->R->E->D->H instead of I->F->B->A->R->E->D->H. 4. For D node, both blue topology and red topology are available for the backup. The blue topology is preferred. From the above calculation example, we can see that how the tie- breaking rule has to be applied when choose the nexthop in a specific topology and the topology which is used for the secondary route. For the reason of simplicity, there is no LFA calculation for the secondary route. If exists, it should be preferred. We assume that labels are allocated in different topologies as the following figure. <-- L/Lb/Lr <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr [E]------------------[D]------------------[H]-------------------[J] | | | | | | ^ | | ^ | | ^ | | ^ | | | | | | | | | | | | v | | v | | v | | v | | L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr | | | | | | | <-- L/Lb/Lr | | | | --> L/Lb/Lr | [R]------------------[C] [G]-------------------[I] | | | | | | ^ | | ^ | | ^ | | ^ Zhenbin Li, et al. Expires October 28, 2013 [Page 7] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 | | | | | | | | | | | | v | | v | | v | | v | | L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr | | | | | | | | | | | | [A]------------------[B]------------------[F]--------------------| <-- L/Lb/Lr <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr Figure 3: Label Allocation for LDP Multi-Topology Note: 1. "<--" means the direction in which the label is distributed. For example, "<--" from D to E means that the label is distributed by D to E. 2. L means the label for H distributed in the default topology. Lb means the label for H distributed in the blue topology. Lr means the label for H distributed in the red topology. 3. L distributed by different nodes in the default topology does not mean they must be the same. This is also applied to Lb and Lr. According to above MRT calculation result and label allocation for multi-topology, following forwarding entries will be installed for each node: Default Topology Blue Topology Red Topology R Ingress --/L A /Lr E Transit L/L A Lb/Lb A Lr/Lr E /Lr E /Lr E A Ingress --/L B /Lr R Transit L/L B Lb/Lb B Lr/Lr R /Lr R /Lr R B Ingress --/L F /Lr A Transit L/L F Lb/Lb F Lr/Lr A /Lr A /Lr A C Ingress --/L B /Lr D Transit L/L B Lb/Lb B Lr/Lr D /Lr D /Lr D D Ingress --/L C /Lb E Zhenbin Li, et al. Expires October 28, 2013 [Page 8] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 Transit L/L C Lb/Lb E Lr/Lr H /Lb E /Lr H E Ingress --/L D /Lb R Transit L/L D Lb/Lb R Lr/Lr D /Lb R /Lr D F Ingress --/L G /Lr B Transit L/L G Lb/Lb G Lr/Lr B /Lr B /Lr B G Ingress --/L H /Lr F Transit L/L H Lb/Lb H Lr/Lr F /Lr F /Lr F I Ingress --/L G /Lb J Transit L/L G Lb/Lb J Lr/Lr G /Lb J /Lr G J Ingress --/L H /Lr I Transit L/L H Lb/Lb H Lr/Lr I /Lr I /Lr I Figure 4: Label Forwarding Entries Installed in Each Node for FEC H Note: 1. For an ingress label forwarding entry as follows, when forward, L will be pushed and sent to the next hop A. If failure happens, Lr will be pushed and sent to the next hop E. Ingress --/L A /Lr E 2. For a transit label forwarding entry as follows, when packet with the incoming label L arrives, L will be swapped to L and sent to the next hop A. If failure happens, L will be swapped to Lr and sent to the next hop E. Transit L/L A /Lr E Above forwarding entries construct the label switch path used for fast-reroute in the forwarding plane. We can see that the existing MPLS label forwarding can be used without any extension. Zhenbin Li, et al. Expires October 28, 2013 [Page 9] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 4.2. Non-2-Connected Network [I-D.ietf-rtgwg-mrt-frr-architecture] proposes following non-2-connected network. [E]---[D]---| | | | |----[I] | | | | | [R]---[C] [F]---[G] | | | | | | | | | |----[J] [A]---[B]---| (a) a non-2-connected graph [E]<--[D]<--| [E]-->[D]---| | ^ | [I] ^ | | |--->[I] V | | ^ | V V | [R]-->[C] [F]-->[G] | [R]<--[C] [F]-->[G] | ^ ^ | | ^ | | ^ V | | |--->[J] | V | |----[J] [A]-->[B]---| [A]<--[B]<--| (b) (c) Blue MRT towards I Red MRT towards I Figure 5: A non-2-connected network We will not explain how LDP MT is applied for the MRT FRR in detail. We choose the node I as the destination and choose R and F to observe how MRT and LDP MT work for fast-reroute. According to MRT calculation, the path from R to I in the blue topology is R->A->B->F->G->J->I and the path from R to I in the red topology is R->E->D->F->G->I. We assume in the default topology the path from R to I is R->C->D->F->G->I. Then following forwarding entry will be created in the node R for the destination I. Zhenbin Li, et al. Expires October 28, 2013 [Page 10] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 Default Topology Blue Topology Red Topology R Ingress --/L C /Lb A Transit L/L C Lb/Lb A Lr/Lr E /Lb A /Lr E Figure 6: Label Forwarding Entry of Node R for FEC I For the node F, the path from F to I in the blue topology is F->G->J->I and the path in the red is F->G->I. We assume in the default topology the path from F to I is F->G->I. The following forwarding entry will be created in the node F for the destination I. Default Topology Blue Topology Red Topology F Ingress --/L G Transit L/L G Lb/Lb G Lr/Lr G Figure 7: Label Forwarding Entry of Node F for FEC I We can see that there is no secondary route in the node F for the destination I and correspondingly there is no LDP FRR forwarding entry. 4.3. Proxy Node There are several application scenarios proposed by [I-D.ietf-rtgwg-mrt-frr-architecture] which will use proxy node for MRT. That is, if a set of prefixes are advertised by border routers of an MRT island, a single proxy node can be used to represent the set and the proxy node and associated links are added to the network topology for MRT calculation. The application scenarios include inter-area, inter-AS and partial deployment of compatible MRT FRR routers. 4.4. Inter-Area and Inter-AS For Inter-area scenarios, it is desirable to go back to the default forwarding topology when leaving an area/level. There are two mechanisms proposed by [I-D.ietf-rtgwg-mrt-frr-architecture]. The first one is that ABR will advertise different labels for one specific FEC in different areas. The second one is that penultimate hop pop is done through additional computation by the penultimate router along the in-local-area MRT immediately before the ARB/LBR is reached. The first one need change of the traditional label allocation method for LDP which always distributes the same label for one FEC to all peers. When the second one used, it must be Zhenbin Li, et al. Expires October 28, 2013 [Page 11] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 guaranteed that the IP forwarding should be done by ABR. If there is an inner label, it will cause wrong forwarding behavior. Since it is difficult to determine the type of the packet, the second mechanism must be used carefully. In order to optimize the second mechanism, when the penultimate router receive a packet with MRT label, it can swap the label to corresponding FEC's default topology label instead of penultimate hop pop. 2 2 2 2 A----B----C A----B----C 2 | | 2 2 | | 2 | | | | [ABR1] [ABR2] [ABR1] [ABR2] | | | | p,10 p,15 10 |---[P]---| 15 (a) Initial topology (b)with proxy-node <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr A------------------B------------------C | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr [ABR1] [ABR2] | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr 10 |-----------------[P]-----------------| 15 (c) Label Distribution <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr A------------------B------------------C | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/L/L L/L/L | L/Lb/Lr [ABR1] [ABR2] | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr 10 |-----------------[P]-----------------| 15 Zhenbin Li, et al. Expires October 28, 2013 [Page 12] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 (d) Label Distribution Change Note: In (b),(c) and (d), label distributed by proxy nodes is actually distributed for proxy nodes by nodes in different areas from A/B/C nodes. Figure 8: Inter-area Network and LDP MT Label Distribution for MRT FRR According to the label distribution and MRT computation as shown in (c) of the above figure, following forwarding entries can be created in the node ABR1 and ABR2: Default Topology Blue Topology Red Topology ABR1 Ingress --/L P /Lr A Transit L/L P Lb/Lb P Lr/Lr A /Lr A /Lr A ABR2 Ingress --/L P /Lb C Transit L/L P Lb/Lb C Lr/Lr P /Lb C /Lr P Figure 9: Label Forwarding Entry of Node ABR1 and ABR2 for Proxy Node If the first method on change of label allocation as shown in (d) of the above figure, following forwarding entry will be created in the node A and C: Default Topology Blue Topology Red Topology A Ingress --/L ABR1 /Lr B Transit L/L ABR1 Lb/L ABR1 Lr/Lr B /Lr B /Lr B C Ingress --/L ABR2 /Lb B Transit L/L ABR2 Lb/Lb B Lr/L ABR2 /Lb B /L ABR2 Figure 10: Label Forwarding Entry of Node A and C for Proxy Node For inter-AS scenarios, prefixes advertised by ASBRs will set up LSP in the default topology as proxy egress. The number of prefixes will have great effect on the label allocation of LDP. When MRT fast- reroute deploys, it should be confirmed firstly that labels are enough. Or else, MRT will have negative effect on the deployment of normal service. Besides this, the complexities for ASBR protection Zhenbin Li, et al. Expires October 28, 2013 [Page 13] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 has been proposed by [I-D.ietf-rtgwg-mrt-frr-architecture]. It need further study. 4.5. Partial Deployment For partial deployment and islands of compatible MRT FRR routers, proxy nodes and associated links are added to the network topology for MRT computation. The difference between partial deployment and inter-area is that in the partial deployment scenario the border nodes need proxy egress process for LDP in the blue topology and the red topology. That is, in the blue topology and red topology, the border node of the MRT network topology is not the actual egress for a prefix out of the MRT network. The border node has to advertise label for the prefix as the proxy egress. 2 2 2 2 A----B----C A----B----C 2 | | 2 2 | | 2 | | | | [D] [E] [D] [E] | | | | F---------G |---[P]---| (a) Initial topology (b)with proxy-node <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr A------------------B------------------C | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr [D] [E] | | ^ ^ | | | | | | | | v | | | | v L | L L | L |-----------------[P]-----------------| (c) Label Distribution Note: In (c), label distributed by proxy nodes is actually distributed for proxy nodes by nodes connected to [D] and [E]. Figure 11: Partial Deployment Network and LDP MT Label Distribution for MRT FRR Zhenbin Li, et al. Expires October 28, 2013 [Page 14] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 According to the label distribution and MRT computation as shown in (c) of the above figure, following forwarding entries can be created in the node D and E: Default Topology Blue Topology Red Topology D Ingress --/L P /Lr A Transit L/L P Lb/L P Lr/Lr A /Lr A /Lr A E Ingress --/L P /Lb C Transit L/L P Lb/Lb C Lr/L P /Lb C /L P Figure 12: Label Forwarding Entry of Node D and E for Proxy Node 4.6. LDP over TE There is also additional complexity for LDP over TE scenario in which nodes in the LDP domain need to calculate two different MRT FRR for different nodes in the MPLS TE domain: edge nodes which can support both LDP and TE and internal nodes which only supports TE. Edges nodes combine with nodes in the LDP domain to form a complete topology for MRT FRR calculation. Internal nodes don't support LDP, but are not hidden from IGP topology. Some IP traffic to internal nodes which do not support LDP maybe need MRT FRR provided by nodes in the LDP domain. Nodes in the LDP domain calculate MRT FRR for these internal nodes like partial deployment. An example deployment is shown in the following figure. LDP over TE is deployed in edge nodes B, C, E and H. Internal nodes I, J and K do not support LDP. For MRT FRR, the deployment can be seen as two independent topologies. For internal nodes I, J and K, as shown in the figure (b) it is similar as the process of partial deployment. For other nodes, as shown in the figure (c) it is similar as the process of 2-connected network and the bidirectional MPLS TE paths can be used as the virtual links in MRT computation. [D]--[C]--[I]--[H]--[G] | | \ / | | | | \ / | | [R] | [J] | | | | / \ | | | | / \ | | [A]--[B]--[K]--[E]--[F] (a) Default Topology [D]--[C] [H]--[G] Zhenbin Li, et al. Expires October 28, 2013 [Page 15] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 | | \ / | | | | \ / | | [R] | [Proxy] [Proxy] | | | | / \ | | | | / \ | | [A]--[B] [E]--[F] (b) Graph I for MRT Computation [D]--[C]======[H]--[G] | | \\ // | | | | \\// | | [R] | \\ | | | | //\\ | | | | // \\ | | [A]--[B]======[E]--[F] (c) Graph II for MRT Computation Figure 13: LDP over TE Network and LDP MT Label Distribution for MRT FRR 4.7. IP-Only Network In the IP-only network IP-in-IP has to be used. This means additional loopback addresses have to be introduced. And they are announced with associated MRT color. It will propose complexities for operation and management of the network. We recommend LDP MT should be deployed in the network for the fast-reroute usage to reduce the complexities. It also will not introduce any complexity of IP MT forwarding in the ingress node since the multi-topology only takes effect for protection. Comparing with tunnel IP packet in IP, LDP MT is an easy way to provision fast-reroute. 5. Deployment Considerations 5.1. IGP MT and LDP MT MRT computation can be seen as a local process for IGP if only the computation is consistent for all nodes of the network. That is, multi-topology is not necessary for IGP to advertise link states with MT-ID. MT-ID is only advertised in LDP for LDP's FEC usage. That is, for MRT fast-reroute, IGP MT-ID can be independent of LDP MT-ID. But this proposes complexity for operation and management. It seems desirable to keep the consistency of MT-IDs for both IGP and LDP. There exists another issue regarding the relationship of IGP and LDP. IGP does not support IPv4 and IPv6 in one topology. When multi- topology is used for MRT fast-reroute, the blue topology and the red topology of IPv4 should be different from those of IPv6. However, Zhenbin Li, et al. Expires October 28, 2013 [Page 16] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 for LDP, the address family is adopted for FEC in one multi-topology. Label distribution should be done for both IPv4 and IPv6 in one multi-topology. If the MT-ID is consistent for IGP and LDP, there should be four MT-IDs for IPv4 and IPv6 in one MRT network. For protocol extensions of MRT fast-reroute, both IPv4 and IPv6 should be taken into account for IGP to advertise information related with the blue topology and the red topology. Besides the inconsistency of IGP MT and LDP MT, there exists the inconsistency between the OSPF MT[RFC4915] and the IS-IS MT[RFC5120]. Different MT-ID ranges for OSPF and IS-IS which cause the difficulty in reserving the same MRT MT-IDs for OSPF and IS-IS. When multi-topology is used for MRT fast-reroute, it is error-prone for MT-ID configuration for the blue topology and the red topology on all nodes of the MRT network. In order to simplify operation and management, it is recommended that MT-IDs could be reserved for the MRT fast-reroute usage. Owing to the inconsistency of OSPF MT and IS-IS MT and the inconsistency of IGP MT and LDP MT, it seems a little challenge to reserve these possible values. 5.2. Simplified Provision It is necessary to configure many parameters related with MRT FRR and advertise these capabilities and information by IGP[I-D.li-rtgwg-igp-ext-mrt-frr]. It is concerned that the provision complexity will have negative effect on the utility of MRT FRR. There are two different things for the MRT FRR provision: The first thing is the capability information which can be supported by a MRT-FRR-enabled node. The information can be directly derived without configuration. The second thing is what parameters should be agreed on by all nodes to compute an MRT island. For example, as to [I-D.li-rtgwg-igp-ext-mrt-frr], a node can advertise the supported different algorithms through IGP. The supported algorithms are internal capability which is not necessary to configure. After all nodes advertise the information, they should choose one specific algorithm to compute MRT FRR. This has to be configured or all nodes should agree on a default value in advance. The second thing should be considered more in order to simplify MRT FRR provision. In fact, LDP MT is just the method to simplify the MRT FRR provision comparing with the method that tunnels IP packet in Zhenbin Li, et al. Expires October 28, 2013 [Page 17] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 IP. If the latter method is preferred, it will be more difficult to design IP address carefully for each node than that only blue and red MT IDs is chosen for all nodes in the former method. There are few parameters for LDP-MT-based MRT FRR to be provisioned. The key parameters is just MT IDs and the algorithm's related parameters. As in the section 3.6, It is strongly recommended that the IGP and LDP MT IDs used for MRT FRR should be reserved. It is also the preferred default value for MRT algorithms should be defined in the appropriate documents. By this way a default profile for MRT FRR provision is determined which is composed of a set of default values. This can simplify the MRT FRR provision greatly. If it is not available, all nodes can agree on a internal default profile which is determined by the implementation and save configuration work for MRT FRR. If new nodes add to the network which use different default MT ID values and algorithm-related parameters, it can be changed administratively. 5.3. IGP Multi-process IGP multi-process is used to isolate different areas. If an ip prefix is advertised in multiple processes, each process will calculate routes for the prefix and the shortest one will be chosen to install forwarding entry. Each IGP process calculates routes of MRT FRR independently and has its own pair of MRT topology (blue MRT topology and red MRT topology. Since the MRT paths maybe different in different process, one process' MRT next hop can not be used in another process for a specific prefix to avoid loop. So the primary route and its MRT next hop must be chosen in the same process. In order to achieve this object, there should be different blue MRT MT- IDs and red MRT MT-IDs for these processes. If there are only one pair of MRT topology for multiple processes (i.e. there is only one blue MRT MT-ID and one red MRT MT-ID), loop can happen for MRT FRR when each node chooses its primary next hop and the MRT routes in the same process for the multiple processes. Source | V [E]---------[A]---------[F] | | | | | Link 1| |Link 2 | | | | | . | v . Process L . [B] . Process R . | | . | Link 3| |Link 4 | | | | | | v | | | [C] | Zhenbin Li, et al. Expires October 28, 2013 [Page 18] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 | | | | | v | | +----_Destination-------+ (a) The shortest path in Default topology Source Source | | | | [E]---<-----[A] [A]---------[F] | ^ | | | Link 1| |Link 2 | | | | | . | v . Process L . [B] [B] . Process R . | | . | Link 3| |Link 4 | | | | | | | v | | [C] [C] | | | | | | | v | +-->--Destination Destination-------+ (b) Process L's Blue topology (c) Process R's Blue topology path from LSRB to Destination path from LSRA to Destination Source | | L/Lb/Lr [E]---------[A]---------[F] L/Lb/Lr | L/Lb/Lr ^ | | | | | | | | | | . | v . Process L . [B] . Process R . L/Lb/Lr | | . | | | | | | | | | | | | | [C](fail) | | L/Lb/Lr | | | | | | | +-----Destination-------+ (d) Loop occurs when LSRC fails Figure 14: Loop Issue in IGP Mul-tiprocess Zhenbin Li, et al. Expires October 28, 2013 [Page 19] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 An IGP multi-process deployment is shown in the above figure. Node A, B and C are located in both processes: the left process L and the right process R. The process L is a ring topology, including link1 and link3. And the process R is also a ring topology, including link2 and link4. For the traffic from the Source to the Destination, assume that A chooses the shortest path dertermined by the process R and using link2 as the primary next hop and B chooses the shortest path determined by the process L and using link3 as the primary next hop. Process L and process R calculate MRT topologies independently, but there is only one pair of MRT MT-IDs and the label distribution is the same for different processes, this will cause the following forwarding entries are installed: Node B: The shortest path is determined by process L. The MRT path is calculated in the same process. Assume that B calculates the blue MRT topology shown in the (b) and chooses link1 in the blue MRT topology as its secondary route. Then there is following forwarding entries for node B: Default Topology Blue Topology Red Topology B Transit L/L C Lb/Lb A Lr/Lr C /Lb A /Lr C Node A: The shortest path is determined by process R. The MRT path is calculated in the same process. Assume that A calculates the blue MRT topology shown in the (c). Then there is following forwarding entries for node A: Default Topology Blue Topology Red Topology A Transit L/L B Lb/Lb B Lr/Lr F /Lr F /Lr F According to above forwarding entries, if node C fails, the traffic will be sent by B to A with label Lb using the secondary route. When A receives the traffic with label Lb, it will send the traffic to B using the forwarding entry for the blue topology. Then loop happens for the traffic. The solution of the issue is to use different MRT MTs for different processes. That is, different MRT topologies should be provisioned for different processes so that the different label distribution is done for the multiple processes. This will guarante that when failure happens the switched traffic will be forwarded in the same process. The following figure shows the solution for as to the above example: Zhenbin Li, et al. Expires October 28, 2013 [Page 20] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 Source | | L/Lb/Lr [E]---<-----[A]---------[F] L/Lb'/Lr' | L/Lb/Lr ^ | Lb'/Lr' | | | | | | | | | . | | . Process L . [B] . Process R . L/Lb/Lr | | Lb'/Lr' . | | | | | | | | | | | | | [C](fail) | | L/Lb/Lr | | | | | | | +-----Destination-------+ Figure 15: Separate MRT MT for Multi-process Following forwarding entries will be created for A and B. We can see that if failure happens, the switched traffic is forwarded from A to B to E and the loop issue is avoided. Default Topology Blue MT Red MT Blue MT' Red MT' A Transit L/L B Lb/Lb E Lr/Lr B Lb'/Lb' B Lr'/Lr' F /Lr' F /Lr B /Lr' F B Transit L/L C Lb/Lb A Lr/Lr C Lb'/Lb' C Lr'/Lr' A /Lb A /Lr C /L' A Owing to the loop issue in the IGP multi-process scenario, it must be checked carefully for the reserved MT-IDs or the default profile described above for simplifying provision which will cause multiple processes share the same MRT MT-IDs. In order to prevent loop issue, separate MRT MTs for IGP multi-process have to be taken into account. 5.4. Multiple IGP If multiple IGPs deploy in one network, the best route will be determined according to priority of these IGPs. This might cause the inconsistency issue for MRT fast-reroute. For example, when IS-IS and OSPF are deployed in one network, some nodes will use the best reroute computed by ISIS and some nodes will use the best route computed by OSPF. If the link state is not consistent in IS-IS and OSPF, the MRT fast-reroute cannot work well. It is highly desirable that in one network only one IGP protocol is deployed and link states should be guaranteed consistent if multiple IGPs deploys. Zhenbin Li, et al. Expires October 28, 2013 [Page 21] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 5.5. Label Space Advantages of LDP MT in MRT fast-reroute are apparent for simplified operation and management comparing with using IP tunnel. The main issue of LDP MT for MRT fast-reroute is resource occupancy. MRT FRR need create two redundant topologies to provide backup path. The two topologies cover all links and nodes of the MRT network. It will impact on the system resource occupancy since it will also take more resource to install routes and label forwarding entries for different topologies. When deploying LDP MT for MRT FRR, especially in the scenario of upgrading, consideration should be taken so that there is enough system resource to accommodate more routes and forwarding entries. Besides the issue related with resource occupancy, label usage is also an important issue to be taken into account. For one FEC, there are at least three label bindings distributed by one router. The number of labels for MRT fast-route is triple of that of the network without MRT fast-reroute. When LDP MT for MRT FRR is deployed, it should be guaranteed that enough labels are available so that it will not have impact on normal services such as L2VPN, L3VPN, etc. 5.6. Proxy Egress In several scenarios where MRT FRR is deployed, proxy egress LSPs have to be setup by LDP. The proxy egress LSP maybe not end-to-end to bear VPN service in the network. But it will deteriorate label usage if LDP MT is deployed for MRT FRR. It is highly desirable that such unnecessary LSPs should be prohibited to setup to facilitate MRT FRR deployment. 5.7. Policy Control Policy can be used to reducing the effect of more labels for MRT FRR. It is important to control on the setup of LSP in the default topology. There are two basic scenarios. The first one is the IP- only network. It is difficult to control the number of LSPs for protection since LDP MT is an extension for IP to implement protection. The second one is the multi-service network based on VPN. Policy can be applied to permit only host addresses to setup LSPs. Policy is not recommended to control on LSP in the blue topology and the red topology since it is easy to cause inconsistency of the protection. For example, if one node need to set up MRT backup LSP for one FEC but this FEC is not allowed creating LSP by the policy in the MRT topologies, then the node cannot create the MRT backup LSP. Zhenbin Li, et al. Expires October 28, 2013 [Page 22] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 5.8. Resource Allocations During the deployment of this solution, more system resource and extra label occupancy must be taken into account to avoid the possible resource exhausting. 5.9. LDP DOD LDP DoD is used in some scenarios such as Seamless MPLS[I-D.ietf-mpls-seamless-mpls]. When MRT fast-reroute is deployed, label request will be sent according to the path calculated for different topology. The label forwarding entry will be created as the method above. Comparing with LDP DU, there are less label binding distribution for LDP DoD. In addition, LDP DoD is always used combing with conservative label retention mode. Thus there is no label binding distributed for the secondary route calculated in the default topology so that LFA cannot not be used easily. The label forwarding entry in the blue topology or the red topology will be used as the secondary one directly. 6. IANA Considerations This document makes no request of IANA. 7. Security Considerations There is no security issue introduced by this specification. 8. Acknowledgements 9. 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-mpls-ldp-multi-topology] Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP Extensions for Multi Topology Routing", draft-ietf-mpls- ldp-multi-topology-06 (work in progress), December 2012. [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft- ietf-mpls-seamless-mpls-02 (work in progress), October 2012. Zhenbin Li, et al. Expires October 28, 2013 [Page 23] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 [I-D.ietf-rtgwg-mrt-frr-architecture] Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, J., Konstantynowicz, M., White, R., and M. Shand, "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02 (work in progress), February 2013. [I-D.li-rtgwg-igp-ext-mrt-frr] Li, Z., Wu, N., and Q. Zhao, "Routing Extension for Fast- Reroute Using Maximally Redundant Trees", draft-li-rtgwg- igp-ext-mrt-frr-01 (work in progress), March 2013. [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. [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. [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Tao Zhou Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: tao.chou@huawei.com Zhenbin Li, et al. Expires October 28, 2013 [Page 24] Internet-Draft App of LDP MT for Unicast MRT FRR April 2013 Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 US Email: quintin.zhao@huawei.com Tianle Yang China Mobile 32, Xuanwumenxi Ave. Beijing 01719 China Email: yangtianle@chinamobile.com Zhenbin Li, et al. Expires October 28, 2013 [Page 25]