draft-ietf-mpls-seamless-mpls-01.txt | draft-ietf-mpls-seamless-mpls-02.txt | |||
---|---|---|---|---|
MPLS Working Group N. Leymann, Ed. | MPLS Working Group N. Leymann, Ed. | |||
Internet-Draft Deutsche Telekom AG | Internet-Draft Deutsche Telekom AG | |||
Intended status: Informational B. Decraene | Intended status: Informational B. Decraene | |||
Expires: September 13, 2012 France Telecom | Expires: April 25, 2013 France Telecom | |||
C. Filsfils | C. Filsfils | |||
M. Konstantynowicz | M. Konstantynowicz | |||
Cisco Systems | Cisco Systems | |||
D. Steinberg | D. Steinberg | |||
Steinberg Consulting | Steinberg Consulting | |||
March 12, 2012 | October 22, 2012 | |||
Seamless MPLS Architecture | Seamless MPLS Architecture | |||
draft-ietf-mpls-seamless-mpls-01 | draft-ietf-mpls-seamless-mpls-02 | |||
Abstract | Abstract | |||
This documents describes an architecture which can be used to extend | This documents describes an architecture which can be used to extend | |||
MPLS networks to integrate access and aggregation networks into a | MPLS networks to integrate access and aggregation networks into a | |||
single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is | single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is | |||
based on existing and well known protocols. It provides a highly | based on existing and well known protocols. It provides a highly | |||
flexible and a scalable architecture and the possibility to integrate | flexible and a scalable architecture and the possibility to integrate | |||
100.000 of nodes. The separation of the service and transport plane | 100.000 of nodes. The separation of the service and transport plane | |||
is one of the key elements; Seamless MPLS provides end to end service | is one of the key elements; Seamless MPLS provides end to end service | |||
skipping to change at page 1, line 49 | skipping to change at page 1, line 49 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 13, 2012. | This Internet-Draft will expire on April 25, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 13 | skipping to change at page 3, line 13 | |||
5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 17 | 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
5.1.2. General Network Topology . . . . . . . . . . . . . . . 17 | 5.1.2. General Network Topology . . . . . . . . . . . . . . . 17 | |||
5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 | 5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 | |||
5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . . 19 | 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . . 19 | |||
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 | 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 | |||
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 20 | 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 20 | |||
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 21 | 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 21 | |||
5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22 | 5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22 | |||
5.1.8. Network Availability and Simplicity . . . . . . . . . 23 | 5.1.8. Network Availability . . . . . . . . . . . . . . . . . 23 | |||
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 | 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 | |||
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 24 | 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 24 | |||
5.1.8.3. Hierarchical Dataplane and BGP Prefix | 5.1.8.3. Hierarchical Dataplane and BGP Prefix | |||
Independent Convergence . . . . . . . . . . . . . 24 | Independent Convergence . . . . . . . . . . . . . 24 | |||
5.1.8.4. Local Protection using Anycast BGP . . . . . . . . 25 | 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 25 | |||
5.1.8.5. Assessing loss of connectivity upon any failure . 30 | 5.1.8.5. Assessing loss of connectivity upon any failure . 25 | |||
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 35 | 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 | |||
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 36 | 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 30 | |||
5.1.9. Next-Hop Redundancy . . . . . . . . . . . . . . . . . 36 | 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 | |||
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 37 | 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 31 | |||
5.2.1. Control and Data Plane State for Deployment | 5.2.1. Control and Data Plane State for Deployment | |||
Scenario #1 . . . . . . . . . . . . . . . . . . . . . 37 | Scenario #1 . . . . . . . . . . . . . . . . . . . . . 31 | |||
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 37 | 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 31 | |||
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 38 | 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 32 | |||
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 39 | 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 33 | |||
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 40 | 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 | |||
5.2.1.5. Numerical application for use case #1 . . . . . . 41 | 5.2.1.5. Numerical application for use case #1 . . . . . . 35 | |||
5.2.1.6. Numerical application for use case #2 . . . . . . 41 | 5.2.1.6. Numerical application for use case #2 . . . . . . 35 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | |||
8.1. Access Network Security . . . . . . . . . . . . . . . . . 43 | 8.1. Access Network Security . . . . . . . . . . . . . . . . . 37 | |||
8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 43 | 8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37 | |||
8.3. Control Plane Security . . . . . . . . . . . . . . . . . . 44 | 8.3. Control Plane Security . . . . . . . . . . . . . . . . . . 38 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 45 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 39 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
1. Introduction | 1. Introduction | |||
MPLS as a mature and well known technology is widely deployed in | MPLS as a mature and well known technology is widely deployed in | |||
today's core and aggregation/metro area networks. Many metro area | today's core and aggregation/metro area networks. Many metro area | |||
networks are already based on MPLS delivering Ethernet services to | networks are already based on MPLS delivering Ethernet services to | |||
residential and business customers. Until now those deployments are | residential and business customers. Until now those deployments are | |||
usually done in different domains; e.g. core and metro area networks | usually done in different domains; e.g. core and metro area networks | |||
are handled as separate MPLS domains. | are handled as separate MPLS domains. | |||
skipping to change at page 23, line 10 | skipping to change at page 23, line 10 | |||
the overall seamless MPLS architecture since it creates the required | the overall seamless MPLS architecture since it creates the required | |||
hierarchy and enables the hiding of all aggregation and access | hierarchy and enables the hiding of all aggregation and access | |||
addresses behind the ABRs from an IGP point of view. Leaking of | addresses behind the ABRs from an IGP point of view. Leaking of | |||
aggregation ISIS L1 loopback addresses into ISIS L2 is not necessary | aggregation ISIS L1 loopback addresses into ISIS L2 is not necessary | |||
and MUST NOT be allowed. | and MUST NOT be allowed. | |||
The resulting hierarchical inter-domain MPLS routing structure is | The resulting hierarchical inter-domain MPLS routing structure is | |||
similar to the one described in [RFC4364] section 10c, only that we | similar to the one described in [RFC4364] section 10c, only that we | |||
use one AS with route reflection instead of using multiple ASes. | use one AS with route reflection instead of using multiple ASes. | |||
5.1.8. Network Availability and Simplicity | 5.1.8. Network Availability | |||
The seamless mpls architecture illustrated in deployment case study 1 | The seamless mpls architecture guarantees a sub-second loss of | |||
guarantees a sub-second loss of connectivity upon any link or node | connectivity upon any link or node failures. Furthermore, in the | |||
failures. Furthermore, in the vast majority of cases, the loss of | vast majority of cases, the loss of connectivity is limited to sub- | |||
connectivity is limited to sub-50msec. | 50msec. | |||
These network availability properties are provided without any | These network availability properties are provided without any | |||
degradation on scale and simplicity. This is a key achievement of | degradation on scale and simplicity. This is a key achievement of | |||
the design. | the design. | |||
In the remainder of this section, we first introduce the different | In the remainder of this section, we first introduce the different | |||
network availability technologies and then review their applicability | network availability technologies and then review their applicability | |||
for each possible failure scenario. | for each possible failure scenario. | |||
5.1.8.1. IGP Convergence | 5.1.8.1. IGP Convergence | |||
skipping to change at page 24, line 32 | skipping to change at page 24, line 32 | |||
Per-Prefix LFA FRR is generally assessed as a simple technology for | Per-Prefix LFA FRR is generally assessed as a simple technology for | |||
the operator [I-D.filsfils-rtgwg-lfa-applicability]. It certainly is | the operator [I-D.filsfils-rtgwg-lfa-applicability]. It certainly is | |||
in the context of deployment case study 1 as the designer enforced | in the context of deployment case study 1 as the designer enforced | |||
triangle and full-mesh topologies in the aggregation network as well | triangle and full-mesh topologies in the aggregation network as well | |||
as a dual-plane core network. | as a dual-plane core network. | |||
5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent Convergence | 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent Convergence | |||
In a hierarchical dataplane, the FIB used by the packet processing | In a hierarchical dataplane, the FIB used by the packet processing | |||
engine reflects the recursions between routes. For example, a BGP | engine reflects recursions between the routes. For example, a BGP | |||
route B recursing on IGP route I whose best path is via interface O | route B recursing on IGP route I whose best path is via interface O | |||
is encoded as a FIB entry B pointing to a FIB entry I pointing to a | is encoded as a hierarchy of FIB entry B pointing to a FIB entry I | |||
FIB entry 0. | pointing to a FIB entry 0. | |||
Hierarchical FIB [BGPPIC] extends the hierarchical dataplane with the | ||||
concept of a BGP Path-List. A BGP path-list may be abstracted as a | ||||
set of primary multipath nhops and a backup nhop. When the primary | ||||
set is empty, packets destined to the BGP destinations are rerouted | ||||
via the backup nhop. | ||||
With hierarchical FIB and hierarchical dataplane, a FIB entry | ||||
representing a BGP route points to a FIB entry representing a BGP | ||||
Path-List. This entry may either point again to another BGP Path | ||||
list entry (BGP over BGP recursion) or more likely points to a FIB | ||||
entry representing an IGP route. | ||||
A BGP Path-list may be computed automatically by the router and does | ||||
not require any operator involvement. Specifically, the automated | ||||
computation adapts to any routing policy (this is key to understand | ||||
the simplicity of hierarchical FIB and the ability to enable it as a | ||||
default router behavior). There is no constraint at all on the | ||||
operator design. Any policy is supported (multipath, primary/backup | ||||
between neighboring domains or via alternate domains). | ||||
The BGP backup nhop is computed in advance of any failure (ie. a | ||||
second bestpath computation after excluding the primary nhops). | ||||
Hierarchical dataplane and hierarchical FIB provide two important | ||||
routing availability properties. | ||||
First, upon IGP convergence, recursive BGP routes immediately benefit | ||||
from the updated IGP paths thanks to the dataplane indirection. This | ||||
is key as most of the traffic is destined to BGP routes, not to IGP | ||||
routes. | ||||
Second, upon loss of the primary BGP nhop, the dataplane can | ||||
immediately reroute the packets towards the pre-computed backup nhop. | ||||
This redirection is said to be prefix independent as the only entries | ||||
that need to be modified are the BGP path-lists. These entries are | ||||
shared across all the BGP prefixes with the same primary and backup | ||||
next-hops. This scale independence is key. In the context of | ||||
deployment model 1, while there might be 100k BGP routes, we only | ||||
expect on the order of 200 BGP path-lists. Assuming 10usec in-place | ||||
modification per BGP path-list, we see that the router can enable the | ||||
backup path for 100k BGP destinations in less than 2msec (less than | ||||
200 * 10usec). | ||||
The detection of the loss of the primary BGP nhop (and hence the need | ||||
to enable the pre-computed backup BGP nhop) can be local (a local | ||||
link failing between an edge device and a single-hop eBGP peer) or | ||||
involves an IGP convergence (a remote border router goes down). | ||||
These hierarchical FIB properties benefit to any BGP routes: | ||||
Internet, L3VPN, 3107, IPv4 or IPv6. Future evolution of VPLS will | ||||
also benefit from such properties [I-D.raggarwa-mac-vpn], | ||||
[I-D.sajassi-l2vpn-rvpls-bgp] | ||||
Hierarchical forwarding and hierarchical FIB are very simple | ||||
technology to operate. Their ability to adapt to any topology, any | ||||
routing policy and any BGP address family allows router vendors to | ||||
enable this behavior by default. | ||||
5.1.8.4. Local Protection using Anycast BGP | ||||
5.1.8.4.1. Anycast BGP applied to ABR node failure | ||||
In this section we described a mechanism that provides local | ||||
protection for area border router (ABR) failures. To illustrate this | ||||
mechanism consider an example shown in Figure 6. | ||||
+-------+ | ||||
| | | ||||
vl0+ ABR 1 | | ||||
/| | | ||||
+----------+ +-------+ / +-------+ | ||||
| | | |/ | ||||
| PE / LER +-..-+ PLR | | ||||
| | | |\ | ||||
+----------+ +-------+ \ +-------+ | ||||
\| | | ||||
vl0+ ABR 2 | | ||||
| | | ||||
+-------+ | ||||
+-------+ +-------+ +-------+ | ||||
| LDP-L +-----+ LDP-L +-----+ LDP-L | | ||||
+-------+ +-------+ +-------+ | ||||
| BGP-L +-------------------+ BGP-L | | ||||
+-------+ +-------+ | ||||
--------------- traffic ----------------> | ||||
<----- routing + label distribution ----- | ||||
Figure 6: Routing and Traffic Flow | ||||
The core router adjacent to ABR1 and ABR2 acts as a point of local | ||||
repair (PLR). When the PLR detects ABR1 failure, the PLR re-routes | ||||
to ABR2 the traffic that the PLR used to forward to ABR1, with ABR2 | ||||
providing the subsequent forwarding for this traffic. To accomplish | ||||
this ABR1, ABR2, and the PLR employ the following procedures. | ||||
ABR1, in addition to its own loopback, is provisioned with another IP | ||||
address (vl0). This IP address is used to identify the forwarding | ||||
state/context on ABR1 that is the subject to the local protection | ||||
mechanism outlined in this section. We refer to this IP address, | ||||
vl0, as the "context identifier". ABR1 advertises its context | ||||
identifier in ISIS and LDP. As ABR1 re-advertises to its core peers | ||||
the BGP routes it receives from its peers in the aggregation | ||||
domain(s), ABR1 sets the BGP Next Hop on these routes to its context | ||||
identifier (this creates an association between the forwarding state/ | ||||
context created by these routes and the context identifier). | ||||
ABR2, acting as a protector for ABR1, is configured with the ABR1's | ||||
context identifier. ABR2 advertises this context identifier into LDP | ||||
and ISIS. The LDP advertisement is done with no PHP and a non-null | ||||
label, and the ISIS advertisement is done with a very high metric. | ||||
As a result, the PLR would have an LFA route/LSP to this context | ||||
identifier with ABR2 as the next hop. When the PLR detects ABR1's | ||||
failure, the LFA procedures on the PLR would result in sending to | ||||
ABR2 the traffic that the PLR used to forward to ABR1. Moreover, | ||||
since ABR2 advertises into LDP a non-null label for the ABR1's | ||||
context identifier, this label would enable ABR2 to identify such | ||||
traffic (as we'll see further down the ability to identify such | ||||
traffic is essential in order for ABR2 to correctly forward this | ||||
traffic). | ||||
+-----------------+-----------+-----------+ | ||||
| FEC 10.0.1.1/32 | Label 200 | NH AGN2-1 | | ||||
+-----------------+-----------+-----------+ | ||||
| FEC 10.0.1.2/32 | Label 233 | NH AGN2-1 | ABR1 | ||||
+-----------------+-----------+-----------+ | ||||
| FEC 10.0.1.3/32 | Label 313 | NH AGN2-1 | | ||||
+-----------------+-----------+-----------+ | ||||
+------+ +-------+ | ||||
| | | | +------------------+ | ||||
vl0+ ABR1 +----+ AGN21 +----+ AGN11:10.0.1.1/32| | ||||
/| | | |\ /+------------------+ | ||||
/ +------+\ /+-------+ \/ | ||||
+----+ +-----+/ \/ \ /\ +------------------+ | ||||
| PE +---+ PLR | /\ X X+ AGN12:10.0.1.2/32| | ||||
+----+ +-----+\ / \ / \/ +------------------+ | ||||
\ +------+ +-------+ /\ | ||||
\| | | |/ \+------------------+ | ||||
vl0+ ABR2 +----+ AGN22 +----+ AGN13:10.0.1.3/32| | ||||
| | | | +------------------+ | ||||
+------+ +-------+ | ||||
+----------------------------------------+ | ||||
| native forwarding context | | ||||
+-----------------+-----------+----------+ | ||||
| FEC 10.0.1.1/32 | Label 100 | NH AGN21 | | ||||
+-----------------+-----------+----------+ | ||||
| FEC 10.0.1.2/32 | Label 107 | NH AGN21 | ABR2 | ||||
+-----------------+-----------+----------+ | ||||
| FEC 10.0.1.3/32 | Label 152 | NH AGN21 | | ||||
+-----------------+-----------+----------+ | ||||
| | | | ||||
V V V | ||||
+----------------------------------------+ | ||||
| backup forwarding context | | ||||
+-----------------+-----------+----------+ | ||||
| FEC 10.0.1.1/32 | Label 200 | NH AGN21 | | ||||
+-----------------+-----------+----------+ | ||||
| FEC 10.0.1.2/32 | Label 233 | NH AGN21 | ABR2 | ||||
+-----------------+-----------+----------+ | ||||
| FEC 10.0.1.3/32 | Label 313 | NH AGN21 | | ||||
+-----------------+-----------+----------+ | ||||
(ABR2 acting as backup for ABR1) | ||||
Figure 7: ABR Failure Scenarios | ||||
ABR2, acting as a protector for the forwarding context of ABR1, has | ||||
to have the <FEC->label> mapping for the FECs present in that | ||||
forwarding context, and should use this mapping to create the | ||||
forwarding state it would use when forwarding the traffic received | ||||
from the PLR. Figure 7 shows the <FEC->label> mapping on ABR1 and | ||||
ABR2. Note that the backup forwarding context on ABR2 is a mirror | ||||
image of the forwarding context on ABR1. This backup forwarding | ||||
context is populated using the routes that have been re-advertised by | ||||
ABR1 to its core peers (as ABR2 is a BGP core peer of ABR1). The | ||||
label that ABR2 advertises into LDP for ABR1's context identifier | ||||
points to the backup context. This way, ABR2 forwards all the | ||||
traffic received with this label using not its native forwarding | ||||
context, but the backup forwarding context. | ||||
Note that whether the PLR could rely on the basic LFA to re-route to | ||||
ABR2 the traffic that the PLR used to forward to ABR1 depends on the | ||||
LFA coverage. Since the basic LFA does not guarantee 100% coverage | ||||
in all topologies, relying on basic LFA may not be sufficient, in | ||||
which case the basic LFA would need to be augmented to provide 100% | ||||
coverage. | ||||
The procedures outlined above provide local protection upon ABR node | ||||
failure. By virtue of being local protection, the actions required | ||||
to restore connectivity upon the failure detection are fully | ||||
localized to the router closest to the failure - the router directly | ||||
connected to the failed ABR. This enables to deliver under 50msec | ||||
connectivity recovery time in the presence of ABR failure. These | ||||
actions do not depend on propagating failure information in ISIS, | ||||
thus providing connectivity recovery time that is independent of the | ||||
ISIS routing convergence time. In contrast, a combination of | ||||
hierarchical FIB organization and ISIS routing convergence, being a | ||||
global protection mechanism, does rely on the ISIS routing | ||||
convergence time, as the prefix-independent switch-over on the pre- | ||||
computed backup next hop occurs upon IGP convergence (deletion of the | ||||
IGP route to the remote ABR), and thus would have several 100s msec | ||||
connectivity recovery time. | ||||
5.1.8.4.2. Extensions to support ABR's connected to different | ||||
aggregation regions | ||||
Note that for the purpose of identifying the forwarding context | BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical | |||
ABR1's forwarding state could be partitioned, with each partition | dataplane with the concept of a BGP Path-List. A BGP path-list may | |||
being assigned its own IP address (its own context identifier). ABR1 | be abstracted as a set of primary multipath nhops and a backup nhop. | |||
would advertise all these identifiers into ISIS and LDP. This may be | When the primary set is empty, packets destined to the BGP | |||
useful in the scenario where ABR1 is connected to more than one | destinations are rerouted via the backup nhop. | |||
aggregation domain (more than one L1 area), in which case each | ||||
context identifier would identify the ABR1's forwarding state | ||||
associated with a single aggregation domain. | ||||
One could further refine the above scheme by implementing protector | For complete description of BGP-PIC technology and its applicability | |||
functionality that would allow a single protector to protect multiple | please refer to [BGP-PIC]. | |||
forwarding contexts, with each forwarding context being associated | ||||
with all the forwarding state maintained by a given (protected) ABR. | ||||
Such functionality could be implemented either on a separate router, | ||||
or could be co-located with an existing ABR. Details of this are | ||||
outside the scope of this document. | ||||
5.1.8.4.3. Anycast BGP applied to a L3VPN PE | Hierarchical data plane and BGP-PIC are very simple technologies to | |||
operate. Their applicability to any topology, any routing policy and | ||||
any BGP unicast address family allows router vendors to enable this | ||||
behavior by default. | ||||
BGP Anycast is also used to protect against L3VPN PE failures. In | 5.1.8.4. BGP Egress Node FRR | |||
general a given VPN site can be multi-homed (connected to several | ||||
L3VPN PEs). Moreover, multi-homed sites may be non-congruent with | ||||
each other - different multi-homed sites connected to a given PE may | ||||
have their other connection(s) to different other PEs. BGP Anycast | ||||
scheme, utilizing the construct of Protector PE, provides forwarding | ||||
context protection for multiple egress PEs in the presence of non- | ||||
congruent multi-homed sites. | ||||
Protector PE function is enhanced from the basic BGP Anycast 1:1 | BGP egress node FRR is a Fast ReRoute solution and hence relies on | |||
mirroring procedures described for ABR protection, by supporting | local protection and the precomputation and preinstallation of the | |||
multiple backup forwarding contexts, one per protected egress PE. | backup path in the FIB. BGP egress node FRR relies on a transit LSR | |||
Each backup forwarding context on the Protector PE is identified by | ( Point of Local Repair, PLR ) adjacent to the failed protected BGP | |||
the context identifier of the associated protected egress PE. | router to detect the failure and re-route the traffic to the backup | |||
BGP router. Number of BGP egress node FRR schemes are being | ||||
investigated: [PE-FRR], [ABR-FRR], | ||||
[I-D.draft-minto-2547-egress-node-fast-protection-00], | ||||
[I-D.draft-minto-2547-egress-node-fast-protection-00], | ||||
[I-D.draft-minto-2547-egress-node-fast-protection-00]. | ||||
Protector PE advertises these context identifiers into IGP with a | Differences between these schemes relate to the way backup and | |||
large metric and into LDP with no PHP and a non-null label. This | protected BGP routers get associated, how the protected router's BGP | |||
results in PLR of each egress PE having an LFA route/LSP (or bypass | state is signalled to the backup BGP router(s) and if any other state | |||
LSP if no native LFA coverage for specific topology) to the | is required on protected, backup and PLR routers. The schemes also | |||
associated context identifier with Protector PE as the next hop. | differ in compatibility with IPFRR and TEFRR schemes to enable PLR to | |||
Protector PE creates a backup forwarding context per protected egress | switch traffic towards the backup BGP router in case of protected BGP | |||
PE based on BGP advertisements from this egress PE and other egress | router failure. | |||
PEs with the same multi-homed customer networks. | ||||
Similarly to the ABR case described earlier, in case of specific | In the Seamless MPLS design, BGP egress node FRR schemes can protect | |||
protected egress PE failure, PLR will follow standard LFA procedure | against the failures of PE, AGN and ABR nodes with no requirements on | |||
(or local protection to bypass LSP) and forward affected flows to | ingress routers. | |||
Protector PE. Those flows will arrive to Protector PE on the LSP | ||||
associated with the context identifier for the failed egress PE, the | ||||
backup forwarding context will be identified by this LSP, and flows | ||||
will be switched to alternative egress PE(s). | ||||
5.1.8.5. Assessing loss of connectivity upon any failure | 5.1.8.5. Assessing loss of connectivity upon any failure | |||
We select two typical traffic flows and analyze the loss of | We select two typical traffic flows and analyze the loss of | |||
connectivity (LoC) upon each possible failure. | connectivity (LoC) upon each possible failure in the Seamless MPLS | |||
design in the deployment scenario #1. | ||||
Flow F1 starts from an AN1 in a left aggregation region and ends | o Flow F1 starts from an AN1 in a left aggregation region and ends | |||
on an AN2 in a right aggregation region. Each AN is dual-homed to | on an AN2 in a right aggregation region. Each AN is dual-homed to | |||
two AGN's. | two AGN's. | |||
Flow F2 starts from an L3VPN PE1 in the core and ends at an L3VPN | o Flow F2 starts from a CE1 homed on L3VPN PE1 connected to the core | |||
PE2 in the core. | LSRs and ends at CE2 dual-homed to L3VPN PE2 and PE3, both | |||
connected to the core LSRs. | ||||
Note that due to the symmetric network topology in case study 1, uni- | Note that due to the symmetric network topology in case study 1, uni- | |||
directional flows F1' and F2', associated with F1 and F2 and | directional flows F1' and F2', associated with F1 and F2 and | |||
forwarded in the reversed direction (AN2 to AN1 right-to-left and PE2 | forwarded in the reversed direction (AN2 to AN1 right-to-left and PE2 | |||
to PE1, respectively), take advantage of the same failure restoration | to PE1, respectively), take advantage of the same failure restoration | |||
mechanisms as F1 and F2. . | mechanisms as F1 and F2. | |||
5.1.8.5.1. AN1-AGN link failure or AGN node failure | 5.1.8.5.1. AN1-AGN link failure or AGN node failure | |||
F1 is impacted but LoC <50msec is possible assuming fast BFD | F1 is impacted but LoC <50msec is possible assuming fast BFD | |||
detection and fast-switchover implementation on the AN. F2 is not | detection and fast-switchover implementation on the AN. F2 is not | |||
impacted. | impacted. | |||
5.1.8.5.2. Link or node failure within the left aggregation region | 5.1.8.5.2. Link or node failure within the left aggregation region | |||
F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will | F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will | |||
skipping to change at page 31, line 52 | skipping to change at page 26, line 39 | |||
flow F1. | flow F1. | |||
Note: remember that the left region receives the routes to all the | Note: remember that the left region receives the routes to all the | |||
remote ABR's and that the labelled BGP routes are reflected from the | remote ABR's and that the labelled BGP routes are reflected from the | |||
core to the left region with next-hop unchanged. This ensures that | core to the left region with next-hop unchanged. This ensures that | |||
the loss of the (local) ABR between the left region and the core is | the loss of the (local) ABR between the left region and the core is | |||
seen as an IGP route impact and hence can be addressed by LFA. | seen as an IGP route impact and hence can be addressed by LFA. | |||
Note: if LFA is not available (other topology then case study one) or | Note: if LFA is not available (other topology then case study one) or | |||
if LFA is not enabled, then the LoC would be < second as the number | if LFA is not enabled, then the LoC would be < second as the number | |||
of impacted important IGP route in a seamless architecture is much | of impacted important IGP routes in a seamless architecture is much | |||
smaller than 2960. | smaller than 2960 routes. | |||
F2 is not impacted. | F2 is not impacted. | |||
5.1.8.5.4. Link or node failure within the core region | 5.1.8.5.4. Link or node failure within the core region | |||
F1 and F2 are impacted but LoC <50msec thanks to LFA FRR. | F1 and F2 are impacted but LoC <50msec thanks to LFA FRR. | |||
This is specific to the particular core topology used in deployment | This is specific to the particular core topology used in deployment | |||
case study 1. The core topology has been optimized | case study 1. The core topology has been optimized | |||
[I-D.filsfils-rtgwg-lfa-applicability] for LFA applicability. | [I-D.filsfils-rtgwg-lfa-applicability] for LFA applicability. | |||
As explained in [I-D.filsfils-rtgwg-lfa-applicability], another | As explained in [I-D.filsfils-rtgwg-lfa-applicability], another | |||
alternative to provide <50msec in this case consists in using an | alternative to provide <50msec in this case consists in using an | |||
MPLS-TE full-mesh and MPLS-TE FRR. This is required when the | MPLS-TE full-mesh and MPLS-TE FRR. This is required when the | |||
designer is not able or does not want to optimize the topology for | designer is not able or does not want to optimize the topology for | |||
LFA applicability and he wants to achieve <50msec protection. | LFA applicability and he wants to achieve <50msec protection. | |||
Alternatively, simple IGP convergence would ensure a LoC < second as | Alternatively, simple IGP convergence would ensure a LoC < second as | |||
the number of impacted important IGP route in a seamless architecture | the number of impacted important IGP routes in a seamless | |||
is much smaller than 2960. | architecture is much smaller than 2960 routes. | |||
5.1.8.5.5. PE2 failure | 5.1.8.5.5. PE2 failure | |||
F1 is not impacted. | F1 is not impacted. | |||
F2 is impacted and the LoC is sub-300msec thanks to IGP convergence | F2 is impacted and the LoC is sub-300msec thanks to IGP convergence | |||
and hierarchical FIB. | and BGP PIC. | |||
The detection of the primary nhop failure (PE2 down) is performed by | The detection of the primary nhop failure (PE2 down) is performed by | |||
a single-area IGP convergence. | a single-area IGP convergence. | |||
In this specific case, the convergence should be much faster than | In this specific case, the convergence should be much faster than | |||
<sec as very few prefixes are impacted upon an edge node failure. | <sec as very few prefixes are impacted upon an edge node failure. | |||
Reusing the introduction on IGP convergence presented in an earlier | Reusing the introduction on IGP convergence presented in an earlier | |||
section and assuming 2 important impacted prefixes (two loopbacks per | section and assuming 2 important impacted prefixes (two loopbacks per | |||
edge node), one would expect that PE2's failure is detected in | edge node), one would expect that PE2's failure is detected in | |||
260msec + 2*0.250msec. | 260msec + 2*0.250msec. | |||
In a hierarchical FIB organization on the ingress PE, once the loss | If BGP PIC is used on the ingress PE ( PE1 ) then the LoC is the same | |||
of an egress PE is detected, all the impacted BGP Path-Lists | as for IGP convergence. The LoC for BGP/L3VPN traffic upon PE2 | |||
associated with that egress PE need to be updated, and the impacted | failure is thus expected to be <300msec. | |||
traffic gets re-routed to the pre-computed backup PEs. The time it | ||||
takes to complete this operation is not constant, but is proportional | ||||
to the number of unique BGP Path-Lists affected by the egress PE | ||||
failure. Number of such affected BGP Path-Lists is equal to the | ||||
number of "non-congruent" multi-homed sites connected to the egress | ||||
PE, where the number of non-congruent sites is defined as the number | ||||
of other PEs that these sites are connected to (note that in defining | ||||
the term "non-congruent" we refer to sites, rather than to CEs, as a | ||||
given multi-homed site can use multiple CEs). Furthermore, per CE | ||||
BGP policies (e.g. single-path vs. multi-path) may further increase | ||||
number of BGP Path-Lists involved. | ||||
The LoC for BGP/BPN traffic upon PE2 failure is thus expected to be | ||||
<300msec. | ||||
Provided that all the deployment considerations have been met, LoC is | Provided that all the deployment considerations have been met, LoC is | |||
sub-50msec with BGP Anycast. | sub-50msec with BGP egress node FRR. | |||
5.1.8.5.6. PE2's PE-CE link failure | 5.1.8.5.6. PE2's PE-CE link failure | |||
F1 is not impacted. | F1 is not impacted. | |||
F2 is impacted and the LoC is sub-50msec thanks to local interface | F2 is impacted and the LoC is sub-50msec thanks to local interface | |||
failure detection and local forwarding to the backup PE. Forwarding | failure detection and local forwarding to the backup PE. Forwarding | |||
to the backup PE is achieved with hierarchical FIB or local-repair of | to the backup PE is achieved with hierarchical data plane and local- | |||
BGP egress link providing fast re-route to the backup BGP nhop PE. | repair of BGP egress link providing fast re-route to the backup BGP | |||
nhop PE. | ||||
5.1.8.5.7. ABR node failure between right region and the core | 5.1.8.5.7. ABR node failure between right region and the core | |||
F2 is not impacted. | F2 is not impacted. | |||
F1 is impacted. We analyze the LoC for F1 for both hierarchical FIB | F1 is impacted. We analyze the LoC for F1 for both BGP PIC and BGP | |||
and BGP anycast. | egress node FRR. | |||
LoC is sub-600msec thanks to hierarchical FIB. | LoC is sub-600msec thanks to BGP PIC. | |||
The detection of the primary nhop failure (ABR down) is performed by | The detection of the primary nhop failure (ABR down) is performed by | |||
a multi-area IGP convergence. | a multi-area IGP convergence. | |||
First, the two (local) ABR's between the left and core regions must | First, the two (local) ABR's between the left and core regions must | |||
complete the core IGP convergence. The analysis is similar to the | complete the core IGP convergence. The analysis is similar to the | |||
loss of PE2. We would thus expect that the core convergence | loss of PE2. We would thus expect that the core convergence | |||
completes in ~260msec. | completes in ~260msec. | |||
Second, the IGP convergence in the left region will cause all AGN1 | Second, the IGP convergence in the left region will cause all AGN1 | |||
routers to detect the loss of the remote ABR. This second IGP | routers to detect the loss of the remote ABR. This second IGP | |||
convergence is very similar to the first one (2 important prefixes to | convergence is very similar to the first one (2 important prefixes to | |||
remove) and hence should also complete in ~260msec. | remove) and hence should also complete in ~260msec. | |||
Once an AGN1 has detected the loss of the remote ABR, thanks to | Once an AGN1 has detected the loss of the remote ABR, thanks to the | |||
hierarchical FIB organization, in-place modification of shared BGP | BGP PIC, in-place modification of shared BGP path-list and pre- | |||
path-list and pre-computation of BGP backup nhop, the AGN1 reroutes | computation of BGP backup nhop, the AGN1 reroutes flow F1 via the | |||
flow F1 via the alternate remote ABR in a few msec's. | alternate remote ABR in a few msec's [##BGP-PIC]. | |||
As a consequence, the LoC for F1 upon remote ABR failure is thus | As a consequence, the LoC for F1 upon remote ABR failure is thus | |||
expected to be <600msec. | expected to be <600msec. | |||
Provided that all the deployment considerations have been met, LoC is | Provided that all the deployment considerations have been met, LoC is | |||
sub-50msec with BGP Anycast. | sub-50msec with BGP egress node FRR. | |||
5.1.8.5.8. Link or node failure within the right aggregation region | 5.1.8.5.8. Link or node failure within the right aggregation region | |||
F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will | F1 is impacted but LoC <50msec thanks to LFA FRR. No uloop will | |||
occur during the IGP convergence following the LFA protection. | occur during the IGP convergence following the LFA protection. | |||
Note: if LFA is not available (other topology then case study one) or | Note: if LFA is not available (other topology then case study one) or | |||
if LFA is not enabled, then the LoC would be < second as the number | if LFA is not enabled, then the LoC would be < second as the number | |||
of impacted important IGP route in a seamless architecture is much | of impacted important IGP route in a seamless architecture is much | |||
smaller than 2960. | smaller than 2960. | |||
skipping to change at page 35, line 37 | skipping to change at page 30, line 7 | |||
interoperability testing. | interoperability testing. | |||
More specifically, [I-D.filsfils-rtgwg-lfa-applicability] plays a key | More specifically, [I-D.filsfils-rtgwg-lfa-applicability] plays a key | |||
role in the Seamless MPLS architecture as it describes simple design | role in the Seamless MPLS architecture as it describes simple design | |||
guidelines which determiniscally ensure LFA coverage for any link and | guidelines which determiniscally ensure LFA coverage for any link and | |||
node in the aggregation regions of the network. This is key as it | node in the aggregation regions of the network. This is key as it | |||
provides for a simple <50msec protection for the vast majority of the | provides for a simple <50msec protection for the vast majority of the | |||
node and link failures (>90% of the IGP/BGP3107 footprint at least). | node and link failures (>90% of the IGP/BGP3107 footprint at least). | |||
If the guidelines cannot be met, then either the designer will rely | If the guidelines cannot be met, then either the designer will rely | |||
on (1) augmenting native LFA coverage with RSVP, or (2) a full-mesh | on (1) augmenting native LFA coverage with remote LFA | |||
TE FRR model, or (3) IGP convergence. The first option provides the | [I-D.draft-ietf-rtgwg-remote-lfa-00], or (2) augmenting native LFA | |||
same sub-50msec protection as LFA, but introduces additional RSVP | coverage with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP | |||
LSPs. The second option optimizes for sub-50msec protection, but | convergence. The first option provides an automatic and fairly | |||
implies a more complex operational model. The third option optimizes | simple sub-50msec protection as LFA without introducing any | |||
for simple operation but only provides <sec protection. Up to each | additional protocols. The second option provides the same sub-50msec | |||
designer to arbitrate between these three options versus the | protection as LFA, but introduces additional RSVP LSPs. The thrid | |||
possibility to engineer the topology for native LFA protection. | option optimizes for sub-50msec protection, but implies a more | |||
complex operational model. The fourth option optimizes for simple | ||||
operation but only provides <1 sec protection. Up to each designer | ||||
to arbitrate between these three options versus the possibility to | ||||
engineer the topology for native LFA protection. | ||||
A similar choice involves the protection against ABR node failure and | A similar choice involves protection against ABR node failure and | |||
L3VPN PE node failure. The designer can either use hierarchical FIB | L3VPN PE node failure. The designer can either use BGP PIC or BGP | |||
or Anycast BGP. Up to each designer to asssess the trade-off between | egress node FRR. Up to each designer to asssess the trade-off | |||
the valuation of sub-50msec instead of sub-1sec versus additional | between the valuation of sub-50msec instead of sub-1sec versus | |||
operational considerations related to Anycast BGP. | additional operational considerations related to BGP egress node FRR. | |||
5.1.8.7. Conclusion | 5.1.8.7. Conclusion | |||
The Seamless MPLS architecture illustrated in deployment case study 1 | The Seamless MPLS architecture illustrated in deployment case study 1 | |||
guarantees sub-50msec for majority of link and node failures by using | guarantees sub-50msec for majority of link and node failures by using | |||
LFA FRR, except ABR and L3PE node failures, and PE-CE link failure. | LFA FRR, except ABR and L3PE node failures, and PE-CE link failure. | |||
L3VPN PE-CE link failure can be protected with sub-50msec | L3VPN PE-CE link failure can be protected with sub-50msec | |||
restoration, by using hierarchical FIB or local-repair fast-reroute | restoration, by using hierarchical data plane and local-repair fast- | |||
to the backup BGP nhop PE. | reroute to the backup BGP nhop PE. | |||
ABR and L3PE node failure can be protected with sub-50msec | ABR and L3PE node failure can be protected with sub-50msec | |||
restoration, by using BGP Anycast. | restoration, by using BGP egress node FRR. | |||
Alternatively, ABR and L3PE node failure can be protected with sub- | Alternatively, ABR and L3PE node failure can be protected with sub- | |||
1sec restoration, by using hierarchical-FIB. | 1sec restoration using BGP PIC. | |||
5.1.9. Next-Hop Redundancy | 5.1.9. BGP Next-Hop Redundancy | |||
An aggregation domain is connected to the core network using two | An aggregation domain is connected to the core network using two | |||
redundant area boarder routers, and MPLS hierarchy is applied on | redundant area boarder routers, and MPLS hierarchy is applied on | |||
these ABRs. MPLS hierarchy helps scale the FIB but introduces | these ABRs. MPLS hierarchy helps scale the FIB but introduces | |||
additional complexity for the rerouting in case of ABR failure. | additional complexity for the rerouting in case of ABR failure. | |||
Indeed ABR failure requires a BGP converge to update the inner MPLS | Indeed ABR failure requires a BGP converge to update the inner MPLS | |||
hierarchy, in addition to the IGP converge to update the outer MPLS | hierarchy, in addition to the IGP converge to update the outer MPLS | |||
hierarchy. This is also expected to take more time as BGP | hierarchy. This is also expected to take more time as BGP | |||
convergence is performed after the IGP convergence and because the | convergence is performed after the IGP convergence and because the | |||
number of prefixes to update in the FIB can be significant. This is | number of prefixes to update in the FIB can be significant. This is | |||
a drawback but the architecture allow for two "local" solutions which | clearly a drawback, but the architecture allows for two "local | |||
restore the traffic before the BGP convergence takes place. | protection" solutions which restore the traffic before the BGP | |||
convergence takes place. | ||||
One called hierarchical FIB edge, would be required on all edge LSR | ||||
involved in the inner (BGP) MPLS hierarchy. Namely all routers | ||||
except the AN which are not involved in the inner MPLS hierarchy. It | ||||
involves pre-computing and pre-installing in the FIB the BGP backup | ||||
path. Such back up path are activated when the IGP advertise the | ||||
failure of the primary path. | ||||
One called egress fast reroute, would be required on the egress LSR | ||||
involved in the inner (BGP) MPLS hierarchy, namely TN and AGN | ||||
connected to ABR. It involves: | ||||
using a anycast loopback address shared by both nominal and back | BGP PIC would be required on all edge LSR involved in the inner (BGP) | |||
up ABR, advertised by both ABR in the IGP and advertised as BGP | MPLS hierarchy. Namely all routers except the AN which are not | |||
Next Hop by the nominal ABR; | involved in the inner MPLS hierarchy. It involves pre-computing and | |||
pre-installing in the FIB the BGP backup path. Such back up path are | ||||
activated when the IGP advertise the failure of the primary path. | ||||
For specification see [BGP-PIC1, 2##]. | ||||
activating IP FRR LFA on the (penultimate) hops, acting as PLR for | BGP egress node FRR would be required on the egress LSR involved in | |||
the anycast loopback; | the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For | |||
using on the backup egress nodes (ABR2) an additional contextual | specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##]. | |||
MPLS FIB populated by the labels upstream allocated by the nominal | ||||
egress node (ABR1). | ||||
Details can be found in [PEFRR] and [ABRFRR], and in the appendix of | Both approaches have their pros and cons, and the choice is left to | |||
this draft. Both solutions have their pro and con, and the choice is | each Service Provider or deployment based on the different | |||
left to each Service Provider or deployment based on the different | requirements. The key point is that the seamless MPLS architecture | |||
requirements. The point is that the seamless MPLS architecture can | can handle fast restoration time, even for ABR failures. | |||
handles fast restoration time, even for ABR failures. | ||||
5.2. Scalability Analysis | 5.2. Scalability Analysis | |||
5.2.1. Control and Data Plane State for Deployment Scenario #1 | 5.2.1. Control and Data Plane State for Deployment Scenario #1 | |||
5.2.1.1. Introduction | 5.2.1.1. Introduction | |||
Let's call: | Let's call: | |||
o #AN the number of Access Node (AN) in the seamless MPLS domain | o #AN the number of Access Node (AN) in the seamless MPLS domain | |||
skipping to change at page 42, line 28 | skipping to change at page 36, line 35 | |||
o TN MPLS LFIB 150 | o TN MPLS LFIB 150 | |||
o RR BGP NLRI 40 000 | o RR BGP NLRI 40 000 | |||
o RR BGP paths 80 000 | o RR BGP paths 80 000 | |||
6. Acknowledgements | 6. Acknowledgements | |||
Many people contributed to this document. The authors would like to | Many people contributed to this document. The authors would like to | |||
thank Wim Henderickx, Clarence Filsfils, Thomas Beckhaus, Wilfried | thank Wim Henderickx, Robert Raszuk, Thomas Beckhaus, Wilfried Maas, | |||
Maas, Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and | Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and Simon | |||
Simon DeLord for their suggestions and review. | DeLord for their suggestions and review. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
All drafts are required to have an IANA considerations section (see | All drafts are required to have an IANA considerations section (see | |||
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] | the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] | |||
for a guide). If the draft does not require IANA to do anything, the | for a guide). If the draft does not require IANA to do anything, the | |||
section contains an explicit statement that this is the case (as | section contains an explicit statement that this is the case (as | |||
above). If there are no requirements for IANA, the section will be | above). If there are no requirements for IANA, the section will be | |||
skipping to change at page 44, line 44 | skipping to change at page 39, line 4 | |||
access locations with lower physical security, designer could also | access locations with lower physical security, designer could also | |||
consider using: | consider using: | |||
o different crypto keys for use in authentication procedures for | o different crypto keys for use in authentication procedures for | |||
these locations. | these locations. | |||
o stricter network protection mechanisms including DoS protection, | o stricter network protection mechanisms including DoS protection, | |||
interface and session flap dampening. | interface and session flap dampening. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
9.2. Informative References | 9.2. Informative References | |||
[ABRFRR] Rekhter, Y., "Local Protection for LSP tail-end node | [ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node | |||
failure, MPLS World Congress 2009". | failure, MPLS World Congress 2009". | |||
[ACM01] "Archieving sub-second IGP convergence in large IP | [ACM01] "Archieving sub-second IGP convergence in large IP | |||
networks, ACM SIGCOMM Computer Communication Review, v.35 | networks, ACM SIGCOMM Computer Communication Review, v.35 | |||
n.3", July 2005. | n.3", July 2005. | |||
[BGPPIC] "BGP PIC, Technical Report", November 2007. | [BGP-PIC] "BGP PIC, Technical Report", November 2007. | |||
[I-D.draft-bashandy-bgp-edge-node-frr-03] | ||||
"". | ||||
[I-D.draft-bashandy-bgp-frr-mirror-table-00] | ||||
"". | ||||
[I-D.draft-ietf-rtgwg-remote-lfa-00] | ||||
"". | ||||
[I-D.draft-minto-2547-egress-node-fast-protection-00] | ||||
"". | ||||
[I-D.filsfils-rtgwg-lfa-applicability] | [I-D.filsfils-rtgwg-lfa-applicability] | |||
Filsfils, C., Francois, P., Shand, M., Decraene, B., | Filsfils, C., Francois, P., Shand, M., Decraene, B., | |||
Uttaro, J., Leymann, N., and M. Horneffer, "LFA | Uttaro, J., Leymann, N., and M. Horneffer, "LFA | |||
applicability in SP networks", | applicability in SP networks", | |||
draft-filsfils-rtgwg-lfa-applicability-00 (work in | draft-filsfils-rtgwg-lfa-applicability-00 (work in | |||
progress), March 2010. | progress), March 2010. | |||
[I-D.ietf-bfd-v4v6-1hop] | [I-D.ietf-bfd-v4v6-1hop] | |||
Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single | Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single | |||
Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), | Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), | |||
January 2010. | January 2010. | |||
[I-D.ietf-mpls-ldp-dod] | [I-D.ietf-mpls-ldp-dod] | |||
Beckhaus, T., Decraene, B., Tiruveedhula, K., | Beckhaus, T., Decraene, B., Tiruveedhula, K., | |||
Konstantynowicz, M., and L. Martini, "LDP Downstream-on- | Konstantynowicz, M., and L. Martini, "LDP Downstream-on- | |||
Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-00 (work | Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-03 (work | |||
in progress), January 2012. | in progress), August 2012. | |||
[I-D.kothari-henderickx-l2vpn-vpls-multihoming] | [I-D.kothari-henderickx-l2vpn-vpls-multihoming] | |||
Kothari, B., Kompella, K., Henderickx, W., and F. Balus, | Kothari, B., Kompella, K., Henderickx, W., and F. Balus, | |||
"BGP based Multi-homing in Virtual Private LAN Service", | "BGP based Multi-homing in Virtual Private LAN Service", | |||
draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work | draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work | |||
in progress), July 2009. | in progress), July 2009. | |||
[I-D.narten-iana-considerations-rfc2434bis] | [I-D.narten-iana-considerations-rfc2434bis] | |||
Narten, T. and H. Alvestrand, "Guidelines for Writing an | Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", | IANA Considerations Section in RFCs", | |||
skipping to change at page 46, line 8 | skipping to change at page 40, line 25 | |||
Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and | Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and | |||
F. Balus, "BGP MPLS Based MAC VPN", | F. Balus, "BGP MPLS Based MAC VPN", | |||
draft-raggarwa-mac-vpn-01 (work in progress), June 2010. | draft-raggarwa-mac-vpn-01 (work in progress), June 2010. | |||
[I-D.sajassi-l2vpn-rvpls-bgp] | [I-D.sajassi-l2vpn-rvpls-bgp] | |||
Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and | Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and | |||
S. Boutros, "Routed VPLS using BGP", | S. Boutros, "Routed VPLS using BGP", | |||
draft-sajassi-l2vpn-rvpls-bgp-01 (work in progress), | draft-sajassi-l2vpn-rvpls-bgp-01 (work in progress), | |||
July 2010. | July 2010. | |||
[PEFRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in | [PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in | |||
MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS | MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS | |||
2006 Conference". | 2006 Conference". | |||
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, | [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, | |||
June 1999. | June 1999. | |||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", RFC 3031, January 2001. | Label Switching Architecture", RFC 3031, January 2001. | |||
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in | [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in | |||
skipping to change at page 48, line 7 | skipping to change at page 42, line 17 | |||
Brussels, | Brussels, | |||
Belgium | Belgium | |||
Phone: | Phone: | |||
Fax: | Fax: | |||
Email: cfilsfil@cisco.com | Email: cfilsfil@cisco.com | |||
URI: | URI: | |||
Maciek Konstantynowicz | Maciek Konstantynowicz | |||
Cisco Systems | Cisco Systems | |||
London, | ||||
United Kingdom | ||||
Phone: | Phone: | |||
Fax: | Fax: | |||
Email: maciek@cisco.com | Email: maciek@cisco.com | |||
URI: | URI: | |||
Dirk Steinberg | Dirk Steinberg | |||
Steinberg Consulting | Steinberg Consulting | |||
Ringstrasse 2 | Ringstrasse 2 | |||
Buchholz 53567 | Buchholz 53567 | |||
End of changes. 49 change blocks. | ||||
378 lines changed or deleted | 156 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |