One document matched: draft-li-rtgwg-ldp-mt-mrt-frr-01.txt
Differences from draft-li-rtgwg-ldp-mt-mrt-frr-00.txt
Network Working Group Zhenbin Li
Internet-Draft Tao Zhou
Intended status: Informational Quintin Zhao
Expires: April 25, 2013 Huawei Technologies
October 22, 2012
Applicability of LDP Multi-Topology for Unicast Fast-reroute Using
Maximally Redundant Trees
draft-li-rtgwg-ldp-mt-mrt-frr-01
Abstract
In this document, procudures' 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 anlyzed.
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 25, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhenbin Li, et al. Expires April 25, 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. Procedure Considerations . . . . . . . . . . . . . . . . . . . 4
3.1. Routing Calculation . . . . . . . . . . . . . . . . . . . 4
3.2. Label Distribution . . . . . . . . . . . . . . . . . . . . 5
3.3. Forwarding Entry Creation . . . . . . . . . . . . . . . . 5
3.4. Switchover and Re-Convergence . . . . . . . . . . . . . . 6
3.5. Switchback . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. IGP MT and LDP MT . . . . . . . . . . . . . . . . . . . . 6
3.7. Multiple IGP . . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Label Space . . . . . . . . . . . . . . . . . . . . . . . 7
3.9. Proxy Egress . . . . . . . . . . . . . . . . . . . . . . . 7
3.10. Policy Control . . . . . . . . . . . . . . . . . . . . . . 8
3.11. LDP DOD . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.12. Resource Allocations . . . . . . . . . . . . . . . . . . . 8
4. Application Scenarios' Analysis . . . . . . . . . . . . . . . 8
4.1. 2-Connected Network . . . . . . . . . . . . . . . . . . . 8
4.2. Non-2-Connected Network . . . . . . . . . . . . . . . . . 12
4.3. Proxy Node . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Inter-Area and Inter-AS . . . . . . . . . . . . . . . . . 13
4.5. Partial Deployment . . . . . . . . . . . . . . . . . . . . 16
4.6. LDP over TE . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. IP-Only Network . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Zhenbin Li, et al. Expires April 25, 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
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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 3]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
o 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.
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. Procedure Considerations
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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 4]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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:
-- 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 blue topology
is preferred 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 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. For
the blue topology, the secondary label forwarding entry is 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 forwarding
plane so that the existing label forwarding can be used well for MRT
fast-reroute.
Zhenbin Li, et al. Expires April 25, 2013 [Page 5]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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
produced. The methods proposed by [RFC5714] can be used to prevent
such micro-loop.
In order to reduce the routing calculation load, the MRT fast-reroute
calculation should be delayed to guarantee the primary route's re-
convergence. Protected traffic is 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 may 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 calculation can
also be done. It will provide a best-effort protection if failure
happens in the period.
3.6. 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,
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.
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
Zhenbin Li, et al. Expires April 25, 2013 [Page 6]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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.
3.7. 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 or link states
should be guaranteed consistent in different IGPs.
3.8. 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.
3.9. 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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 7]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
3.10. 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.
3.11. 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
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.
3.12. Resource Allocations
During the deployment of this solution, more system resource and
label occupancy must be taken into account to avoid the possible
resource exhausting.
4. Application Scenarios' 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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 8]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
[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
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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 9]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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, "<--" 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:
Zhenbin Li, et al. Expires April 25, 2013 [Page 10]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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
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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 11]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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 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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 12]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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 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
Zhenbin Li, et al. Expires April 25, 2013 [Page 13]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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
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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 14]
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 forwarding entries can be created
in the node ABR1 and ABR2:
Zhenbin Li, et al. Expires April 25, 2013 [Page 15]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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
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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 16]
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 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
Zhenbin Li, et al. Expires April 25, 2013 [Page 17]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
4.6. 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.
For MRT FRR, the deployment can be seen as two independent
topologies. For 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. Noted that, if the MPLS TE paths
are unidirectional, the proxy node should present all the nodes not
in the same side, which side the tunnels' ingress LSR belongs to.
[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 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
Zhenbin Li, et al. Expires April 25, 2013 [Page 18]
Internet-Draft App of LDP MT for Unicast MRT FRR October 2012
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. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
There is no security issue introduced by this specification.
7. Acknowledgements
8. 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., Ning, S., and K.
Raza, "LDP Extensions for Multi Topology Routing",
draft-ietf-mpls-ldp-multi-topology-05 (work in progress),
October 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.
Zhenbin Li, et al. Expires April 25, 2013 [Page 19]
Internet-Draft App of LDP MT for Unicast MRT FRR October 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
Quintin Zhao
Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
US
Email: quintin.zhao@huawei.com
Zhenbin Li, et al. Expires April 25, 2013 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-22 15:17:22 |