Network Working Group Z. Li Internet-Draft T. Zhou Intended status: Informational Huawei Technologies Expires: April 18, 2013 October 15, 2012 Applicability of LDP Multi-Topology for Unicast Fast-reroute Using Maximally Redundant Trees draft-li-rtgwg-ldp-mt-mrt-frr-00 Abstract In this document, we analyze the applicability of the LDP multi- topology(MT) for unicast fast-reroute using Maximally Redundant Trees(MRT) . We analyze the label allocation behavior and label forwarding entry setup with LDP Multi-Topology when MRT fast-reroute is used. Different application scenarios are considered and guidance on the applicability of LDP MT for unicast fast-reroute using MRT is provided. 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. Li & Zhou Expires April 18, 2013 [Page 1] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 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. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Routing Calculation . . . . . . . . . . . . . . . . . . . 4 3.2. Label Distribution . . . . . . . . . . . . . . . . . . . . 4 3.3. Fowrding Entry Creation . . . . . . . . . . . . . . . . . 5 3.4. Switchover and Re-Convergence . . . . . . . . . . . . . . 5 3.5. Switchback . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Application Scenorios . . . . . . . . . . . . . . . . . . . . 6 4.1. 2-Connected Network . . . . . . . . . . . . . . . . . . . 6 4.2. Non-2-Connected Network . . . . . . . . . . . . . . . . . 9 4.3. Proxy Node . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. LDP over TE . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. IP-Only Network . . . . . . . . . . . . . . . . . . . . . 15 5. Considertations . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. IGP MT and LDP MT . . . . . . . . . . . . . . . . . . . . 16 5.2. Multiple IGP . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Label Space . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Proxy Egress . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Policy Control . . . . . . . . . . . . . . . . . . . . . . 17 5.6. LDP DOD . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Li & Zhou Expires April 18, 2013 [Page 2] Internet-Draft App of LDP MT for Unicast 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 fast- reroute of unicast traffic. LDP multi- topology[I-D.ietf-mpls-ldp-multi-topology] has been proposed to provide unicast forwarding in the architecture. We provide the analysis of the applicability of LDP MT for unicast fast-reroute using MRT. The procedures is described and typical examples is provided based on LDP MT for MRT unicast FRR architecture. Guidance are provided against different application scenarios to improve the applicability. 2. Terminology 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. 2-connected cluster: A maximal set of nodes that are 2-connected. 2-edge-connected: A network graph where at least two links must be removed to partition the network. cut-link: A link whose removal partitions the network. A cut-link by definition must be connected between two cut-vertices. If 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. cut-vertex: A vertex whose removal partitions the network. 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. FIB Forwarding Information Base. The database used by the packet forwarder to determine what actions to perform on a packet. 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) < Distance_opt(N, S) + Distance_opt(S, D) 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 Li & Zhou Expires April 18, 2013 [Page 3] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 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. Redundant Trees (RT): A pair of trees where the path from any node X to the root R along the first tree is node-disjoint with the path from the same node X to the root along the second tree. These can be computed in 2-connected graphs. SPF Shortest Path First, e.g., Dijkstra's algorithm. SPT Shortest path tree 3. Procedures 3.1. Routing Calculation IGP will flood information related with MRT FRR of each router and calculate routes for all destinations based on MRT. The details for the algorithm can refer to [I-D.enyedi-rtgwg-mrt-frr-algorithm]. For each destination, there are at least three routes that are associated with default topology, red topology and blue topology. The route of red topology or blue topology will be chosen as the secondary route. The most important thing for the routing calculation is consistancy of all nodes in the network. In order to guarantee the consistance, following rules should be specified for the MRT caluculation: -- rules for choosing the root node; -- rules for choosing the next-hop in the blue topology and the red topogy. Rules for choosing the secondary route can be determined locally if multipole routes exist. It will not propose interoperability issue. According to [I-D.ietf-rtgwg-mrt-frr-architecture] the secondary route derived from LFA calculation can be prefered since it exists in the default topology. If ther is no secondary route for LFA, the blue topology can be prefered since it can be protected again by the red topology. 3.2. Label Distribution When LDP MT is used for MRT fast-reroute, LDP will negotiate the MT capability when setup session. Once IGP calaculates routes for destinations based on MRT, LDP will advertise label mapping message with corresponding MT-ID for the specic FEC. There are at least Li & Zhou Expires April 18, 2013 [Page 4] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 three label bindings for each FEC that are associated with default topology, red topology and blue topology. We use L_primary for the label binding of the default topology, L_blue for the label binding of the blue topology and L_red for the label binding of the red topology. MT-IDs for the blue topology and the red topology can be specified adminstratively. In order to avoid inconsistancy and simplify operation and management, we suggest MT-IDs can be reserved for MRT fast-reroute usage. 3.3. Fowrding Entry Creation LDP will crete label fording entry for each FEC in different topologies. The route calculated based on MRT will determine which label binding will be chosen for each FEC in a specific topology. For the default topology, the secondary label forwarding entry will be determined by the secondary route in the blue topology or the red topology. For the blue topology, the secondary label forwarding entry will be created according to the secondary route in the red topology. Though the forwarding entry need be chosen according to MT information, there is not any MT information which should be processed in the fowrding plane and the existing label forwarding can be used well for MRT fast-reroute. 3.4. Switchover and Re-Convergence When failure happens, the traffic can swich to the secondary forwarding entry in 50ms in the fowarding plane. The control plance will do the re-convergence process according to the link state change. During the course of re-convergence, the micro-loop can be produced. The methods proposed by [RFC5714] can be used to prevent micro-loop. In order to reduce the routing calculation load, the MRT fast-reroute calculation can be delayed to gurantee the primary route's re- convergece. Protected Traffic will be forwarded in the red or blue topology until re-convergence of the primary route is done. If failure happens again in the delayed period of MRT FRR calculation, it will cause traffic loss. 3.5. Switchback When link failure or node failure recovers, IGP-LDP synchronization should be used for the default topology to prevent traffic loss. During the period of IGP-LDP synchronization, MRT FRR caluculation can also be done. It will provide a best-effort protection if failure happens in the period. Li & Zhou Expires April 18, 2013 [Page 5] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 4. Application Scenorios 4.1. 2-Connected Network In order to explain how LDP MT works for MRT FRR, we choose the following typical topology as an example. In the figure, (a) is the original topology, (b) is the blue topology calculated by MRT and (c) is the red topology calculated by MRT. [E]--[D]--[H]--[J] [E]<-[D]<-[H]<-[J] [E]->[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 Topogy 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 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 topoloby 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 E node, both blue topology and red topology are available for Li & Zhou Expires April 18, 2013 [Page 6] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 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 prefered. 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] | | | | | | ^ | | ^ | | ^ | | ^ | | | | | | | | | | | | 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, "<--" between E and D 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. Li & Zhou Expires April 18, 2013 [Page 7] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 According to above MRT calculation result and label allocation for multi-topoloty, following forwarding entries will be installed for each node: Default Topogy 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 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: Li & Zhou Expires April 18, 2013 [Page 8] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 1. For an ingress label forwarding entry as follows, when foward, 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. 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 R Red MRT towards R Figure 5: A non-2-connected network We wiil not explain how LDP MT is applied for the MRT FRR in details. We choose the node I as the destination and choose R and F to observe Li & Zhou Expires April 18, 2013 [Page 9] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 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. Default Topogy 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 Topogy 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 thers 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 prefixes are advertised by boder nodes 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 inlude inter-area, inter-AS and partial deployment of compatible MRT FRR routers. 2.5.12 Inter-Area and Inter-AS For Inter-area scenarios, it is desirable to go back to the default fowarding 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 Li & Zhou Expires April 18, 2013 [Page 10] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 reached. The first one need change of the traditional label allocation method for LDP which always distribues the same label for one FEC to all peers. When the second one used, it must be guaranteed that the IP fowarding should be done by ABR. If there is an inner label, it will cause wrong fowarding behavior. Since it is difficult to determine the type of the packet, the second mechanism must be used carefully. Li & Zhou Expires April 18, 2013 [Page 11] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 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 (d) Label Distribution Change 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 fowarding entries can be created in the node ABR1 and ABR2: Li & Zhou Expires April 18, 2013 [Page 12] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 Default Topogy Blue Topology Red Topology ABR1 Ingress --/L P /Lr A Transit L/L P Lb/Lb P Lr/Lr A /Lr A /Lr A ABR1 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 Topogy 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, prefiexes 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 has been proposed by [I-D.ietf-rtgwg-mrt-frr-architecture]. It need further study. 2.5.13 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 boder node has to advertise label for the prefix as the proxy egress. Li & Zhou Expires April 18, 2013 [Page 13] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 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 Figure 11: Partial Deployment 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 fowarding entries can be created in the node D and E: Default Topogy 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.4. LDP over TE There is also additional complexity for LDP over TE. An example deployment is shown in the following figure. LDP over TE is deployed in nodes B, C, E and H. That is, nodes I, J and K do not support LDP. Li & Zhou Expires April 18, 2013 [Page 14] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 For MRT FRR, the deployment can be seen as two independ topologies. For nodes I, J and H, 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 MPLS TE tunnels are 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] | | \ / | | | | \ / | | [R] | [Proxy] [Proxy] | | | | / \ | | | | / \ | | [A]--[B] [E]--[F] (b) Graph I for MRT Compputation [D]--[C]======[H]--[G] | | \\ // | | | | \\// | | [R] | \\ | | | | //\\ | | | | // \\ | | [A]--[B]======[E]--[F] (b) Graph II for MRT Compputation Figure 13: LDP over TE Network and LDP MT Label Distribution for MRT FRR 4.5. 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. Li & Zhou Expires April 18, 2013 [Page 15] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 5. Considertations 5.1. IGP MT and LDP MT MRT computation can be seen as a local process for IGP if only the computation is consistant for all nodes of the network. That is, multi-topolgy is not necessary for IGP to advertise link states with MT-ID. MT-ID is only advertised in LDP for the FEC usage. That is, for MRT fast-reroute, IGP MT-ID can be independent of LDP MT-ID. But this proposes compexity for operation and management. It seems desirable to keep the consistancy 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, for LDP, the address familiy 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 consistant 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. 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, we recommend that MT-IDs could be reserved for the MRT fast-reroute usage. The reserved MT-IDs can be used as the default ones in simple application scenarios. 5.2. Multiple IGP If multiple IGPs deploys in one network, the best route will be determined according to prority of these IGPs. This will cause the inconsitancy issue for MRT fast-reroute. For example, when IS-IS and OSPF deploys 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 consistant in IS-IS and OSPF, the MRT fast-reroute cannot work well. It is highly desirable that in one network only one IGP deploys or link states shoule be guaranteed consistant in different IGPs. 5.3. 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 resouce occupancy. MRT FRR Li & Zhou Expires April 18, 2013 [Page 16] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 need create two redundant topologies to provide backup path. The two topologies cover all links and nodes of the MRT network. It will have great effect on the system resoure occupancy since it will also take more resource to install routes and label forwarding entries for different topologies. When deploy LDP MT for MRT FRR, especially in the scenario of upgrading, it should take care that the sytem resource is enough to accomodate more routes and forwarding entries. Besides the issue related with resouce occupancy, label usage is also an important issue to be taken into account. For one FEC, there are at least three label bindings are 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 negative effect on normal services such as L2VPN, L3VPN, etc. 5.4. Proxy Egress In several scenarios for which MRT FRR is deployed, proxy egress LSPs have to 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 issue if LDP MT is deployed for MRT FRR. It is highly desirable that such unnecessary LSPs should be prohibited to setup to faciliate MRT FRR deployment. 5.5. 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 inconsistancy of the protection. For example, if one node sets up the LSP for one FEC and another node does not setup the LSP for the specific FEC in the blue topology, the traffic will be dropped when the traffic switches to the blue topology. 5.6. LDP DOD LDP DoD is used.In some scenarios such as 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 Li & Zhou Expires April 18, 2013 [Page 17] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 will be created as the method above. The difference from LDP DU is that there is no label distributed for the secondary route calculated in the default topology. The label forwarding entry in the blue topology or the red topology will be used as the secondary one directly. 6. Summary MRT FRR for unicast have following advantages: -- Provide 100% coverage for unicast traffic. -- The complexity of the algorithm is moderate in O(e) or o( e + n log n ). -- Co-deployment with LFA to provide better protection. When LDP MT is combined with MRT FRR, follow advantages can be proposed: -- Simplify operation and management with few additional configurations and states introduced. -- Inherit procedures of LDP to achieve high scalability -- Propose no additional change on label forwarding behavior in the fowarding plane to faciliate incremental deployment Combination LDP MT and MRT FRR is a natural way to implement 100% fast-reroute coverage for unicast traffic. When deploy, more system resource and label occupancy must be taken into account to prevent possible wrong behavior. 7. IANA Considerations This document makes no request of IANA. 8. Security Considerations Label issue 9. Acknowledgements Li & Zhou Expires April 18, 2013 [Page 18] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 10. Normative References [I-D.enyedi-rtgwg-mrt-frr-algorithm] Atlas, A., Envedi, G., and A. Csaszar, "Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute", draft-enyedi-rtgwg-mrt-frr-algorithm-01 (work in progress), March 2012. [I-D.ietf-mpls-ldp-multi-topology] Zhao, Q., Fang, L., Zhou, C., Li, L., and N. So, "LDP Extensions for Multi Topology Routing", draft-ietf-mpls-ldp-multi-topology-04 (work in progress), July 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. [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 Li & Zhou Expires April 18, 2013 [Page 19]