One document matched: draft-li-rtgwg-ldp-mt-mrt-frr-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 05:52:21 |