Internet DRAFT - draft-li-rtgwg-ldp-mt-mrt-frr
draft-li-rtgwg-ldp-mt-mrt-frr
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)<Distance_opt(N,S)+Distance_opt(S,D)
o 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.
o 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.
o SPF Shortest Path First, e.g., Dijkstra's algorithm.
o SPT Shortest path tree
3. Operation 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.
During the routing calculation, consistency of all nodes in the
network must be kept. In order to achieve the consistence, following
rules should be specified for the MRT calculation:
Zhenbin Li, et al. Expires October 28, 2013 [Page 4]
Internet-Draft App of LDP MT for Unicast MRT FRR April 2013
-- rules for choosing the root node;
-- rules for choosing the next-hop in the blue topology and the red
topology.
Rules for choosing the secondary route can be determined locally if
multiple routes exist. According to
[I-D.ietf-rtgwg-mrt-frr-architecture], the secondary route derived
from LFA calculation is preferred since it exists in the default
topology. If there is no secondary route of LFA, the secondary route
will be chosen in the blue topology or the red topology.
3.2. Label Distribution
When LDP MT is used for MRT fast-reroute, LDP will negotiate the MT
Capability with LDP peer. Once IGP calculates routes for
destinations based on MRT, LDP will advertise label mapping message
with corresponding MT-ID for the specific FEC. There are at least
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, used in IGP and LDP, for the blue topology and the red
topology can be specified administratively. In order to avoid
inconsistency and simplify operation and management, we suggest MT-
IDs should be reserved for MRT fast-reroute usage and the MT-IDs used
in IP and LDP should be consistent.
3.3. Forwarding Entry Creation
LDP creates label fording entry for each FEC in different topologies.
The route calculated based on MRT determines which label binding
should be chosen for each FEC in a specific topology. For the
default topology, the secondary label forwarding entry is determined
by the secondary route in the blue topology or 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 forwarding plane so that the existing label
forwarding mechanism can be reused well for MRT fast-reroute.
3.4. Switchover and Re-Convergence
When failure happens, the traffic can be switched to the secondary
forwarding entry by forwarding plane within 50ms. The control plane
will do the re-convergence process according to the link state
change. During the course of re-convergence, the micro-loop may be
Zhenbin Li, et al. Expires October 28, 2013 [Page 5]
Internet-Draft App of LDP MT for Unicast MRT FRR April 2013
produced. The methods proposed by [RFC5714] can be used to prevent
such micro-loop.
MRT fast-reroute calculation should be delayed. Thus the MRT
topologies are carrying traffic and should not be disrupted until the
new SPF routes are installed everywhere so that traffic is moved off
of the MRT topologies. This way can prevent traffic loss to some
extent. On the other hand, if failure happens again in the delayed
period of MRT FRR calculation, it may cause traffic loss since the
secondary route entry can not be guaranteed.
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 calculation can
also be done. It will provide a best-effort protection if failure
happens in the period.
4. Application Scenario Analysis
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 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]
