draft-ietf-mpls-seamless-mpls-06.txt   draft-ietf-mpls-seamless-mpls-07.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: August 18, 2014 Orange Expires: December 30, 2014 Orange
C. Filsfils C. Filsfils
M. Konstantynowicz, Ed. M. Konstantynowicz, Ed.
Cisco Systems Cisco Systems
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
February 14, 2014 June 28, 2014
Seamless MPLS Architecture Seamless MPLS Architecture
draft-ietf-mpls-seamless-mpls-06 draft-ietf-mpls-seamless-mpls-07
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 August 18, 2014. This Internet-Draft will expire on December 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 49 skipping to change at page 2, line 49
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15
4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16
4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 17 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 17
4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 4.7. Signalling and Label Distribution . . . . . . . . . . . . 17
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 19
5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 19
5.1.2. General Network Topology . . . . . . . . . . . . . . 18 5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 19
5.1.3. Hierarchy based on recursive BGP labeled route lookup 19 5.1.2. General Network Topology . . . . . . . . . . . . . . 19
5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 19 5.1.3. Hierarchy based on recursive BGP labeled route lookup 20
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 21
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 21
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 21
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 22
5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 22 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 22
5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 23
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 5.1.8. Network Availability . . . . . . . . . . . . . . . . 24
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 24
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 25
5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent
Convergence . . . . . . . . . . . . . . . . . . . 24 Convergence . . . . . . . . . . . . . . . . . . . 25
5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 26
5.1.8.5. Assessing loss of connectivity upon any failure . 25 5.1.8.5. Assessing loss of connectivity upon any failure . 26
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 30
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 31
5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 32
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 32
5.2.1. Control and Data Plane State for Deployment Scenario 5.2.1. Control and Data Plane State for Deployment Scenarios 32
#1 . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 32
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 33
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 34
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 36
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 5.2.1.5. Numerical application for use case #1 . . . . . . 36
5.2.1.5. Numerical application for use case #1 . . . . . . 35 5.2.1.6. Numerical application for use case #2 . . . . . . 37
5.2.1.6. Numerical application for use case #2 . . . . . . 35 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 9.2. Informative References . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 8, line 42 skipping to change at page 8, line 42
Node and link failures are handled by rerouting the PWs (based on Node and link failures are handled by rerouting the PWs (based on
standard mechanisms). End customers (either residential or business standard mechanisms). End customers (either residential or business
customers) are connected to the access nodes using a native customers) are connected to the access nodes using a native
technology like Ethernet. The access nodes terminates the PW(s) technology like Ethernet. The access nodes terminates the PW(s)
carrying the traffic for the end customers. The link between the carrying the traffic for the end customers. The link between the
access node (AN) and the aggregation node (AGN) is the first MPLS access node (AN) and the aggregation node (AGN) is the first MPLS
enabled link. enabled link.
Residential Services: The service creation for all residential Residential Services: The service creation for all residential
customers connected to the Access Nodes in an aggregation domain customers connected to the Access Nodes in an aggregation domain
is located on an Service Node connected to the AGN2x. The PW (PW1) is located on an Service Node connected to the AGN2x. The PW
originated at the AN and terminates at the AGN2. A second PW is (PW1) originated at the AN and terminates at the AGN2. A second
deployed in the case where redundancy is needed on the AN (the PW is deployed in the case where redundancy is needed on the AN
figure shows redundancy but this might not be the case for all ANs (the figure shows redundancy but this might not be the case for
in this Use Case). Additonal PWs can be deployed as well in case all ANs in this Use Case). Additonal PWs can be deployed as well
more than a single service creation is needed for the residential in case more than a single service creation is needed for the
service (e.g. one service creation point for Internet access and a residential service (e.g. one service creation point for Internet
second service creation point for IPTV services). access and a second service creation point for IPTV services).
Business Sercvices: For business services the use cases shows point Business Sercvices: For business services the use cases shows point
to point connections between two access nodes. PW2 originates at to point connections between two access nodes. PW2 originates at
the AN and terminates on the remote AN crossing two aggregation the AN and terminates on the remote AN crossing two aggregation
areas and the core network. If the access node needs connections areas and the core network. If the access node needs connections
to several remote ANs the corresponding number of PWs will be to several remote ANs the corresponding number of PWs will be
originated at the AN. Nevertheless taking the number of ports originated at the AN. Nevertheless taking the number of ports
available and the number of business customers on a typical access available and the number of business customers on a typical access
node the number of PWs will be relatively small. node the number of PWs will be relatively small.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is
used to aggregate traffic from several AGN1x pairs. In this use case used to aggregate traffic from several AGN1x pairs. In this use case
an aggregation domain is not limited to the use of a single pair of an aggregation domain is not limited to the use of a single pair of
AGN2x; the deployment of several AGN2 pairs within the domain is also AGN2x; the deployment of several AGN2 pairs within the domain is also
supported. As design goal for the scalability of the routing and supported. As design goal for the scalability of the routing and
forwarding within the Seamless MPLS architecture the following forwarding within the Seamless MPLS architecture the following
numbers are used: numbers are used:
o Number of Aggregation Domains: 100 o Number of Aggregation Domains: 100
o Number of Backbone Nodes: 1.000 o Number of Backbone Nodes: 1,000
o Number of Aggregation Nodes: 10.000 o Number of Aggregation Nodes: 10,000
o Number of Access Nodes: 100.000 o Number of Access Nodes: 100,000
The access nodes (AN) are dual homed to two different aggregation The access nodes (AN) are dual homed to two different aggregation
nodes (AGN11 and AGN12) using static routing entries on the AN. The nodes (AGN11 and AGN12) using static routing entries on the AN. The
ANs are always source or sink nodes for MPLS traffic but not transit ANs are always source or sink nodes for MPLS traffic but not transit
nodes. This allows a light MPLS implementation in order to reduce nodes. This allows a light MPLS implementation in order to reduce
the complexity in the AN. The aggregation network consists of two the complexity in the AN. The aggregation network consists of two
stages with redundant connections between the stages (AGN11 is stages with redundant connections between the stages (AGN11 is
connected to AGN21 and AGN22 as well as AGN12 to AGN21 and AGN22). connected to AGN21 and AGN22 as well as AGN12 to AGN21 and AGN22).
The gateway between the aggregation and core network is realized The gateway between the aggregation and core network is realized
using the Area Border Routers (ABR). From the perspective of the using the Area Border Routers (ABR). From the perspective of the
skipping to change at page 15, line 13 skipping to change at page 15, line 13
customer traffic MUST be as low as possible. customer traffic MUST be as low as possible.
3.4. Scalability 3.4. Scalability
The network must be highly scalable. Based on the use cases The network must be highly scalable. Based on the use cases
described in Sections 2.2 and 2.3, as a minimum requirement the described in Sections 2.2 and 2.3, as a minimum requirement the
following scalability figures should be met: following scalability figures should be met:
o Number of aggregation domains: 100 o Number of aggregation domains: 100
o Number of backbone nodes: 1.000 o Number of backbone nodes: 1,000
o Number of aggregation nodes: 10.000 o Number of aggregation nodes: 10,000
o Number of access nodes: 100.000 o Number of access nodes: 100,000
3.5. Stability 3.5. Stability
o The platform should be stable under certain circumstances (e.g. o The platform should be stable under certain circumstances (e.g.
missconfiguration within one area should not cause instability in missconfiguration within one area should not cause instability in
other areas). other areas).
o Differentiate between "All Loopbacks and Link addresses should be o Differentiate between "All Loopbacks and Link addresses should be
ping able from every where." Vs. "Link addresses are not ping able from every where." Vs. "Link addresses are not
necessary ping able from everywhere". necessary ping able from everywhere".
skipping to change at page 17, line 39 skipping to change at page 17, line 39
nodes is extremely relevant for the overall costs of the entire nodes is extremely relevant for the overall costs of the entire
network, i.e. acess nodes are very cost sensitive. network, i.e. acess nodes are very cost sensitive.
This makes it desirable to design the architecture such that the AN This makes it desirable to design the architecture such that the AN
functionality can be kept as simple as possible. This should always functionality can be kept as simple as possible. This should always
be kept in mind when evaluating different seamless MPLS be kept in mind when evaluating different seamless MPLS
architectures. The goal is to limit both the number of different architectures. The goal is to limit both the number of different
protocols needed on the AN as well as the scale to which each protocols needed on the AN as well as the scale to which each
protocol must perform to the absolute minimum. protocol must perform to the absolute minimum.
4.7. Signalling and Label Distribution
Following figures show IP/MPLS signaling and label distribution for
an LSP from AN2 to AN1 (192.0.2.1), detailing the signalling from AN1
to AN2 (left to right) and packet forwarding from AN2 to AN1 (right
to left). It is assumed that Penultimate Hop Popping is used.
Terminology used in the figures:
o LDP DoD: LDP Downstream on Demand
o LDP DU: LDP Downstream Unsolicited
o BGP LU: BGP Label Unicast (RFC 3107)
o BGP NH: BGP Next Hop Label LYZi: L=Label, Y= node advertising the
FEC (G for AGN, B for ABR, A for AN), Z= protocol advertising it
(B for BGP, L for LDP)
---------------------------------------------------------------------
AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2
LDP DoD -> BGP LU -> BGP LU -> LDP DoD
Next Hop Self
192.0.2.1 192.0.2.1 192.0.2.1 192.0.2.1
Labels: LAL1 LAB1 LAB2 LAL2
BGP NH: AGN1 BGP NH: ABR1
Figure 5: MPLS signalling for the AN / edge layer
---------------------------------------------------------------------
AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2
| IS-IS level 2 | IS-IS level 1 -> IS-IS level 2 |
| LDPDU - LDPDU - LDPDU - LDPDU - LDPDU - LDPDU |
FEC: AGN1 ABR1 ABR1
Label: LGL1 LGL2 LBL1 LBL2 LBL3 LBL4
Figure 6: MPLS signalling and IP routing for the core layer
---------------------------------------------------------------------
Static | IS-IS level 2 | IS-IS level 1 | IS-IS level 2 | Static
Routing Routing
192.0.2.1 -> 192.0.2/24 -> 192.0.2/20 -> 192.2/20 0/0
AGN1 ABR1 ABR1
Figure 7: IP routing for the AN / edge layer
---------------------------------------------------------------------
AN1----AGN1----AGN2----ABR1----LSR1----ABR2----AGN3----AGN4----AN2
FEC AN1: LAL1 LAB1 LAB2 LAB2 LAB2 LAB2 LAL2
FEC AGN1: LGL2 LBL1 LBL2 LBL3 LBL4
/ABR1
Figure 8: Forwarding Plane
---------------------------------------------------------------------
5. Deployment Scenarios 5. Deployment Scenarios
This section describes the deployment scenarios based on the use This section describes the deployment scenarios based on the use
cases and the generic architecture above. cases and the generic architecture above.
5.1. Deployment Scenario #1 5.1. Deployment Scenario #1
Section describing the Seamless MPLS implementation of a large Section describing the Seamless MPLS implementation of a large
european ISP. european ISP.
skipping to change at page 18, line 32 skipping to change at page 19, line 44
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | | / | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+ +----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/ | | AN | /\ \/ |
+----+\ +-------+ \+-------+ +------+/\ +------+ +----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| | \ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
static route ISIS L1 LDP ISIS L2 LDP static route ISIS L1 LDP DU ISIS L2 LDP DU
<-Access-><--Aggregation Domain--><---------Core---------> <-Access-><--Aggregation Domain--><---------Core--------->
Figure 5: Deployment Scenario #1 Figure 9: Deployment Scenario #1
As shown in Figure 5, the access nodes (AN) are connected to the As shown in Figure 9, the access nodes (AN) are connected to the
aggregation network via aggregation nodes called AGN1x, either to a aggregation network via aggregation nodes called AGN1x, either to a
single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant
uplinks to a pair of second-level aggregation nodes called AGN2x. uplinks to a pair of second-level aggregation nodes called AGN2x.
Each aggregation domain is connected to the core via exactly two Each aggregation domain is connected to the core via exactly two
border routers (ABR) on the core side. There can be multiple AGN2 border routers (ABR) on the core side. There can be multiple AGN2
pairs per aggregation domain, but only one ABR pair for each pairs per aggregation domain, but only one ABR pair for each
aggregation domain. Each of the AGN2 in an AGN2 pair connects to one aggregation domain. Each of the AGN2 in an AGN2 pair connects to one
of the ABRs in the ABR pair responsible for that aggregation domain. of the ABRs in the ABR pair responsible for that aggregation domain.
The ABRs on the core side have redundant connections to a pair of LSR The ABRs on the core side have redundant connections to a pair of LSR
routers. routers.
skipping to change at page 19, line 19 skipping to change at page 20, line 32
5.1.3. Hierarchy based on recursive BGP labeled route lookup 5.1.3. Hierarchy based on recursive BGP labeled route lookup
Inline with the explanation in section 4.5, LSP hierarchy is key to a Inline with the explanation in section 4.5, LSP hierarchy is key to a
scalable seamless MPLS architecture. scalable seamless MPLS architecture.
The LSP hierarchy in this design is achieved by: The LSP hierarchy in this design is achieved by:
o Forming separate MPLS domains for aggregation and core areas. o Forming separate MPLS domains for aggregation and core areas.
o Intra-domain LSP connectivity provided by combination of IS-IS (as o Intra-domain LSP connectivity provided by combination of IS-IS (as
the intra-domain link-state routing protocol) and LDP (used for the intra-domain link-state routing protocol) and LDP DU (used for
MPLS label distribution for intra-domain LSPs). MPLS label distribution for intra-domain LSPs).
o Inter-domain LSP connectivity provided by labeled BGP [RFC3107] o Inter-domain LSP connectivity provided by labeled BGP [RFC3107]
(used for MPLS label distribution for inter-domain LSP FECs) and (used for MPLS label distribution for inter-domain LSP FECs) and
relying on IS-IS and LDP for intra-domain LSP connectivity between relying on IS-IS and LDP DU for intra-domain LSP connectivity
the LSR labeled BGP speakers (AGNs and ABRs). Note that the MPLS between the LSR labeled BGP speakers (AGNs and ABRs). Note that
core notes are not carrying the labeled BGP routes. the MPLS core notes are not carrying the labeled BGP routes.
The aggregation and core MPLS domains are mapped to IS-IS areas as The aggregation and core MPLS domains are mapped to IS-IS areas as
follows: Aggregation domains are mapped to IS-IS L1 areas. The core follows: Aggregation domains are mapped to IS-IS L1 areas. The core
is configured as IS-IS L2. The border routers connecting aggregation is configured as IS-IS L2. The border routers connecting aggregation
and core are IS-IS L1L2 and are referred to as ABRs. From a and core are IS-IS L1L2 and are referred to as ABRs. From a
technical and operational point of view these ABRs are part of the technical and operational point of view these ABRs are part of the
core, although they also belong to the respective aggregation domain core, although they also belong to the respective aggregation domain
purely from a routing protocol point of view. purely from a routing protocol point of view.
5.1.4. Intra-Area Routing 5.1.4. Intra-Area Routing
5.1.4.1. Core 5.1.4.1. Core
The core uses ISIS L2 to distribute routing information for the The core uses ISIS L2 to distribute routing information for the
loopback addresses of all core nodes. The border routers (ABR) that loopback addresses of all core nodes. The border routers (ABR) that
connect to the aggregation domains are also part of the respective connect to the aggregation domains are also part of the respective
aggregation ISIS L1 area and hence ISIS L1L2. aggregation ISIS L1 area and hence ISIS L1L2.
LDP is used to distribute MPLS label binding information for the LDP DU is used to distribute MPLS label binding information for the
loopback addresses of all core nodes. loopback addresses of all core nodes.
5.1.4.2. Aggregation 5.1.4.2. Aggregation
The aggregation domains uses ISIS L1 as intra-domain routing The aggregation domains uses ISIS L1 as intra-domain routing
protocol. All AGN loopback addresses are carried in ISIS. protocol. All AGN loopback addresses are carried in ISIS.
As in the core, the aggregation also uses LDP to distribute MPLS As in the core, the aggregation also uses LDP DU to distribute MPLS
label bindings for the loopback addresses. label bindings for the loopback addresses.
5.1.5. Access 5.1.5. Access
Access nodes do not have their own domain or IGP area. Instead, they Access nodes do not have their own domain or IGP area. Instead, they
directly connect to the AGN1 nodes in the aggregation domain. To directly connect to the AGN1 nodes in the aggregation domain. To
keep access devices as simple as possible, ANs do not participate in keep access devices as simple as possible, ANs do not participate in
ISIS. ISIS.
Instead, each AN has two static default routes pointing to each of Instead, each AN has two static default routes pointing to each of
skipping to change at page 20, line 31 skipping to change at page 21, line 48
The AGN1 MUST have a configured static route to the loopback address The AGN1 MUST have a configured static route to the loopback address
of each of the ANs it is connected to, because it cannot learn the AN of each of the ANs it is connected to, because it cannot learn the AN
loopback address in any other way. These static routes have to be loopback address in any other way. These static routes have to be
monitored and invalidated if necessary using the same techniques as monitored and invalidated if necessary using the same techniques as
described above for the static default routes on the AN. described above for the static default routes on the AN.
The AGN1 redistributes these routes into ISIS for intra-domain The AGN1 redistributes these routes into ISIS for intra-domain
reachability of all AN loopback addresses. reachability of all AN loopback addresses.
LDP is used for MPLS label distribution between AGN1 and AN. In LDP DU is used for MPLS label distribution between AGN1 and AN. In
order to keep the AN control plane as lightweight as possible, and to order to keep the AN control plane as lightweight as possible, and to
avoid the necessity for the AN to store 100.000 MPLS label bindings avoid the necessity for the AN to store 100.000 MPLS label bindings
for each upstream AGN1 peer, LDP is deployed in downstream-on-demand for each upstream AGN1 peer, LDP is deployed in downstream-on-demand
(DoD) mode, described below. (DoD) mode, described below.
To allow the label bindings received via LDP DoD to be installed into To allow the label bindings received via LDP DoD to be installed into
the LFIB on the AN without having the specific host route to the the LFIB on the AN without having the specific host route to the
destination loopback address, but only a default route, use of the destination loopback address, but only a default route, use of the
LDP Extension for Inter-Area Label Switched Paths [RFC5283] is made. LDP Extension for Inter-Area Label Switched Paths [RFC5283] is made.
skipping to change at page 21, line 9 skipping to change at page 22, line 26
The assumption is that a given AN will only have a limited number of The assumption is that a given AN will only have a limited number of
services configured to an even more limited number of destinations, services configured to an even more limited number of destinations,
or egress LER. Instead of learning and storing all label bindings or egress LER. Instead of learning and storing all label bindings
for all possible loopback addresses within the entire Seamless MPLS for all possible loopback addresses within the entire Seamless MPLS
network, the AN will use LDP DoD to only request the label bindings network, the AN will use LDP DoD to only request the label bindings
for the FECs corresponding to the loopback addresses of those egress for the FECs corresponding to the loopback addresses of those egress
nodes to which it has services configured. nodes to which it has services configured.
More detailed description of LDP DoD use cases for MPLS access and More detailed description of LDP DoD use cases for MPLS access and
list of required LDP DoD procedures in the context of Seamless MPLS list of required LDP DoD procedures in the context of Seamless MPLS
design is included in [I-D.ietf-mpls-ldp-dod]. design is included in [RFC7032].
5.1.6. Inter-Area Routing 5.1.6. Inter-Area Routing
The inter-domain MPLS connectivity from the aggregation domains to The inter-domain MPLS connectivity from the aggregation domains to
and across the core domain is realized primarily using BGP with MPLS and across the core domain is realized primarily using BGP with MPLS
labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of
route leaking from ISIS L2 into L1 is also used. route leaking from ISIS L2 into L1 is also used.
All ABR and PE nodes in the core are part of the labeled iBGP mesh, All ABR and PE nodes in the core are part of the labeled iBGP mesh,
which can be either full mesh or based on route reflectors. These which can be either full mesh or based on route reflectors. These
skipping to change at page 24, line 19 skipping to change at page 25, line 36
network. 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 recursions between the 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 hierarchy of FIB entry B pointing to a FIB entry I is encoded as a hierarchy of FIB entry B pointing to a FIB entry I
pointing to a FIB entry 0. pointing to a FIB entry 0.
BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical BGP Prefix Independent Convergence [I-D.rtgwg-bgp-pic] extends the
dataplane with the concept of a BGP Path-List. A BGP path-list may hierarchical dataplane with the concept of a BGP Path-List. A BGP
be abstracted as a set of primary multipath nhops and a backup nhop. path-list may be abstracted as a set of primary multipath nhops and a
When the primary set is empty, packets destined to the BGP backup nhop. When the primary set is empty, packets destined to the
destinations are rerouted via the backup nhop. BGP destinations are rerouted via the backup nhop.
For complete description of BGP-PIC technology and its applicability For complete description of BGP-PIC technology and its applicability
please refer to [BGP-PIC] and [ABR-FRR]. please refer to [I-D.rtgwg-bgp-pic] and [ABR-FRR].
Hierarchical data plane and BGP-PIC are very simple technologies to Hierarchical data plane and BGP-PIC are very simple technologies to
operate. Their applicability to any topology, any routing policy and operate. Their applicability to any topology, any routing policy and
any BGP unicast address family allows router vendors to enable this any BGP unicast address family allows router vendors to enable this
behavior by default. behavior by default.
5.1.8.4. BGP Egress Node FRR 5.1.8.4. BGP Egress Node FRR
BGP egress node FRR is a Fast ReRoute solution and hence relies on BGP egress node FRR is a Fast ReRoute solution and hence relies on
local protection and the precomputation and preinstallation of the local protection and the precomputation and preinstallation of the
skipping to change at page 31, line 12 skipping to change at page 32, line 38
the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For the inner (BGP) MPLS hierarchy, namely AGN, ABR and L3VPN PEs. For
specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##]. specification see [PE-FRR], [ABR-FRR], [BGP-edge-FRR##].
Both approaches have their pros and cons, and the choice is left to Both approaches have their pros and cons, and the choice is left to
each Service Provider or deployment based on the different each Service Provider or deployment based on the different
requirements. The key point is that the seamless MPLS architecture requirements. The key point is that the seamless MPLS architecture
can handle fast restoration time, even for ABR failures. can handle 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 Scenarios
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
o #AGN the number of AGgregation Node (AGN) in the seamless MPLS o #AGN the number of AGgregation Node (AGN) in the seamless MPLS
domain domain
skipping to change at page 31, line 37 skipping to change at page 33, line 15
Let's take the following assumptions: Let's take the following assumptions:
o Aggregation equipments are equally spread across aggregation o Aggregation equipments are equally spread across aggregation
routing domains routing domains
o the number of IGP links is three times the number of IGP nodes o the number of IGP links is three times the number of IGP nodes
o the number of IGP prefixes is five times the number of IGP nodes o the number of IGP prefixes is five times the number of IGP nodes
(links prefixes + 2 loopbacks) (links prefixes + 2 loopbacks)
o Each Access Node needs to have up to 1,000 (1k) LSPs. This is o Each Access Node needs to have up to 1,000 (1k) LSPs. LSP scale
driven by the expected AN access line capacity, and a sum of LSPs requirement is driven by expected AN access line capacity and the
required for connectivity to PE routers providing edge services as sum of LSPs required for connectivity to PE routers providing edge
well as a remote ANs. 100 LSPs per AN (10% of total) are FECs services as well as a remote ANs. Number and type of services
which are outside of their routing domain. Those 100 remote FEC accessed by the AN has also an impact. Hence it is very service
are the same for all Access Nodes of a given AGN. specific. Note that if the number of remote PE/LSPs is higher
than the capacity of the AN, some route aggregation scheme can be
enabled at the service layer, e.g. using RFC7024 for IP VPN. It
is assumed that 100 LSPs per AN (10% of total) are FECs that are
outside of their routing domain. Those 100 remote FEC are the
same for all Access Nodes of a given AGN.
The following sections roughly evaluate the scalability, both in The following sections roughly evaluate the scalability, both in
absolute numbers and relatively with the number of Access Node which absolute numbers and relatively with the number of Access Node which
is the biggest scalability factor. is the biggest scalability factor.
5.2.1.2. Core Domain 5.2.1.2. Core Domain
The IGP & LDP core domain are not affected by the number of access The IGP & LDP core domain are not affected by the number of access
nodes: nodes:
IGP: IGP:
node : #Core ~ o(1) node : #Core ~ o(1)
links : 3*#Core ~ o(1) links : 3*#Core ~ o(1)
IP prefixes : 5*#Core ~ o(1) IP prefixes : 5*#Core + #Area ~ o(1)
LDP FEC: LDP FEC:
#Core ~ o(1) #Core ~ o(1)
Core TN FIBs grows linearly with the number of node in the core Core TN FIBs grows linearly with the number of node in the core
domain. In other word, they are not affected by AGN and AN nodes: domain. In other word, they are not affected by AGN and AN nodes:
Core TN: Core TN:
IP FIB : 5*#Core ~ o(1) IP FIB : 5*#Core + #Area ~ o(1)
MPLS ILM (LFIB) : #Core ~ o(1) MPLS ILM (LFIB) : #Core ~ o(1)
BGP carries all AN routes which is significant. However, all AN BGP carries all AN routes which is significant. However, all AN
routes are only needed in the control plane, possibly in a dedicated routes are only needed in the control plane, possibly in a dedicated
BGP Route Reflector (just like for BGP/MPLS VPNs) and not in the BGP Route Reflector (just like for BGP/MPLS VPNs) and not in the
forwarding plane. The number of routes (100k) is smaller than the forwarding plane. The number of routes (100k) is smaller than the
number of number of routes in the Internet (300k and rising) or in number of number of routes in the Internet (300k and rising) or in
major VPN SP (>500k and rising) so the target can be handled with major VPN SP (>500k and rising) so the target can be handled with
current implementations. In addition, AN routes are internal routes current implementations. In addition, AN routes are internal routes
skipping to change at page 32, line 48 skipping to change at page 34, line 31
NLRI : #AN ~ o(n) NLRI : #AN ~ o(n)
path : 2*#AN ~ o(2n) path : 2*#AN ~ o(2n)
ABR handles both the core and aggregations routes. They do not ABR handles both the core and aggregations routes. They do not
depend on the total number of AN nodes, but only on the number of AN depend on the total number of AN nodes, but only on the number of AN
in their aggregation domain. in their aggregation domain.
ABR: ABR:
IP FIB : 5*#Core + (5*#AGN + #AN) / #Area ~ o(#AN /#Area) IP FIB : 5*#Core + (5*#AGN + #AN) / #Area + #Area ~
o(#AN/#Area)
MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area ~ o(#AN / #Area)
5.2.1.3. Aggregation Domain 5.2.1.3. Aggregation Domain
In the aggregation domain, IGP & LDP are not affected by the number In the aggregation domain, IGP & LDP are not affected by the number
of access nodes outside of their domain. They are not affected by of access nodes outside of their domain. They are not affected by
the total number of AN nodes: the total number of AN nodes:
IGP: IGP:
node : #AGN / #Area ~ o(1) node : #AGN / #Area ~ o(1)
links : 3*#AGN / #Area ~ o(1) links : 3*#AGN / #Area ~ o(1)
IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5 IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN
/ #Area) *5/ #Area)
+ plus one aggregate per area (because the number of IP
+ + 1 loopback per core node + one aggregate per area + 5 prefixes is equal to 1 loopback per core node), plus 5
prefixes per AGN in the area + 1 prefix per AN in the area. prefixes per AGN in the area, plus 1 prefix per AN in the
area.
LDP FEC: LDP FEC:
Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) Core + (#AGN + #AN) / #Area ~ o(#AN / #Area)
+ + 1 loopback per core node + 1 loopback per AGN & AN node in + plus one aggregate per area (because the number of IP
the area. prefixes is equal to 1 loopback per core node), plus 5
prefixes per AGN in the area, plus 1 prefix per AN in the
area.
AGN FIBs grows with the number of node in the core area, in their AGN FIBs grows with the number of node in the core area, in their
aggregation area, plus the number of inter domain LSP required by the aggregation area, plus the number of inter domain LSP required by the
AN attached to them. They do not depend on the total number of AN AN attached to them. They do not depend on the total number of AN
nodes. In the BGP control plane, AGN also needs to handle all the AN nodes. In the BGP control plane, AGN also needs to handle all the AN
routes. routes.
AGN: AGN:
IP FIB : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5/ IP FIB : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5/
#Area) #Area)
MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN / MPLS ILM (LFIB) : #Core + (#AGN + #AN) / #Area + 100 ~ o(#AN /
#Area) #Area)
AN FIBs grows with its connectivity requirement. They do not depend AN FIBs grow with the connectivity requirement of the services. They
on the number of AN, AGN, SN or any others nodes. do not depend on the number of AN, AGN, SN or any others nodes.
AN: AN:
IP RIB : 1 ~ o(1) IP RIB : 1 ~ o(1)
MPLS LIB : 1k ~ o(1) MPLS LIB : 1k ~ o(1)
IP FIB : 1 ~ o(1) IP FIB : 1 ~ o(1)
MPLS ILM (LFIB) : 1k ~ o(1) MPLS ILM : 1k ~ o(1) if the AN is used in transit by other ANs
and hence is an LSR (use case #2 having chained AN)
MPLS ILM : 0 ~ o(1) if the AN is not providing transit to
others ANs (use case #1 where AN are final leaf)
MPLS NHLFE : 1k ~ o(1)
5.2.1.4. Summary 5.2.1.4. Summary
AN requirements are kept to a minimum. BGP is not required on ANs AN requirements are kept to a minimum. BGP is not required on ANs
and the size of their FIB is driven only by their own connectivity and the size of their FIB is driven only by their own connectivity
requirements. In the FIB scale analysis described in sections requirements. In the FIB scale analysis described in sections
5.2.1.x, it was assumed that any single AN will need no more than 5.2.1.x, it was assumed that any single AN will need no more than
1,000 LSPs. This assumption is based on the expected AN access line 1,000 LSPs. This assumption is based on the expected AN access line
capacity and LSPs required for connectivity to PE routers providing capacity and LSPs required for connectivity to PE routers providing
edge services as well as a sparse mesh of connectivity between ANs. edge services as well as a sparse mesh of connectivity between ANs.
skipping to change at page 35, line 11 skipping to change at page 36, line 49
(e.g. route partitioning between RR planes, route filtering (static (e.g. route partitioning between RR planes, route filtering (static
or dynamic with ORF or route refresh) between ANs and on AGN to or dynamic with ORF or route refresh) between ANs and on AGN to
improve AGN scalability. improve AGN scalability.
5.2.1.5. Numerical application for use case #1 5.2.1.5. Numerical application for use case #1
As a recap, targets for deployment scenario 1 are: As a recap, targets for deployment scenario 1 are:
o Number of Aggregation Domains 100 o Number of Aggregation Domains 100
o Number of Backbone Nodes 1.000 o Number of Backbone Nodes 1,000
o Number of AGgregation Nodes 10.000
o Number of Access Nodes 100.000 o Number of AGgregation Nodes 10,000
o Number of Access Nodes 100,000
This gives the following scaling numbers for each category of nodes: This gives the following scaling numbers for each category of nodes:
o AN IP FIB 1 o AN IP FIB 1
o AN MPLS ILM (LFIB) 1 000 o AN MPLS ILM 0
o AGN IP FIB 2 600 o AN MPLS NHLFE 1,000
o AGN MPLS ILM (LFIB) 2 200 o AGN IP FIB 2,600
o ABR IP FIB 7 600 o AGN MPLS ILM (LFIB) 2,200
o ABR MPLS ILM (LFIB) 2 100 o ABR IP FIB 6,600
o TN IP FIB 5 000 o ABR MPLS ILM (LFIB) 2,100
o TN MPLS ILM (LFIB) 1 000 o TN IP FIB 5,100
o RR BGP NLRI 100 000 o TN MPLS ILM (LFIB) 1,000
o RR BGP paths 200 000 o RR BGP NLRI 100,000
o RR BGP paths 200,000
5.2.1.6. Numerical application for use case #2 5.2.1.6. Numerical application for use case #2
As a recap, targets for deployment scenario 1 are: As a recap, targets for deployment scenario 1 are:
o Number of Aggregation Domains 30 o Number of Aggregation Domains 30
o Number of Backbone Nodes 150 o Number of Backbone Nodes 150
o Number of AGgregation Nodes 1.500 o Number of AGgregation Nodes 1,500
o Number of Access Nodes 40.000 o Number of Access Nodes 40,000
This gives the following scaling numbers for each category of nodes: This gives the following scaling numbers for each category of nodes:
o AN IP FIB 1 o AN IP FIB 1
o AN MPLS ILM (LFIB) 1 000 o AN MPLS ILM 1,000
o AGN IP FIB 1 700 o AN MPLS NHLFE 1,000
o AGN MPLS ILM (LFIB) 1 800 o AGN IP FIB 1,763
o AGN MPLS ILM 1,633
o ABR IP FIB 3 700 o ABR IP FIB 2,363
o ABR MPLS ILM (LFIB) 1 600 o ABR MPLS ILM 1,533
o TN IP FIB 750 o TN IP FIB 780
o TN MPLS ILM (LFIB) 150 o TN MPLS ILM 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, Robert Raszuk, Thomas Beckhaus, Wilfried Maas, thank Wim Henderickx, Robert Raszuk, Thomas Beckhaus, Wilfried Maas,
Roger Wenner, Kireeti Kompella, Yakov Rekhter, Mark Tinka and Simon Roger Wenner, George Swallow, Kireeti Kompella, Yakov Rekhter, Mark
DeLord for their suggestions and review. Tinka, Curtis Villamizar and Simon DeLord for their suggestions and
review.
7. IANA Considerations 7. IANA Considerations
This memo does not include any requests to IANA. This memo does not include any requests to IANA.
8. Security Considerations 8. Security Considerations
The Seamless MPLS Architecture is subject to similar security threats The Seamless MPLS Architecture is subject to similar security threats
as any MPLS LDP deployment. It is recommended that baseline security as any MPLS LDP deployment. It is recommended that baseline security
measures are considered as described in Security Framework for MPLS measures are considered as described in Security Framework for MPLS
and GMPLS networks [RFC5920], in the LDP specification RFC5036 and GMPLS networks [RFC5920], in the LDP specification RFC5036
[RFC5036] and in [I-D.ietf-karp-routing-tcp-analysis]including [RFC5036] and in [RFC6952]including ensuring authenticity and
ensuring authenticity and integrity of LDP messages, as well as integrity of LDP messages, as well as protection against spoofing and
protection against spoofing and Denial of Service attacks. Some Denial of Service attacks. Some deployments may require increased
deployments may require increased measures of network security if a measures of network security if a subset of Access Nodes are placed
subset of Access Nodes are placed in locations with lower levels of in locations with lower levels of physical security e.g. street
physical security e.g. street cabinets ( common practice for VDSL cabinets ( common practice for VDSL access ). In such cases it is
access ). In such cases it is the responsibility of the system the responsibility of the system designer to take into account the
designer to take into account the physical security measures ( physical security measures ( environmental design, mechanical or
environmental design, mechanical or electronic access control, electronic access control, intrusion detection ), as well as
intrusion detection ), as well as monitoring and auditing measures monitoring and auditing measures (configuration and Operating System
(configuration and Operating System changes, reloads, routes changes, reloads, routes advertisements ).
advertisements ).
Security aspects specific to the MPLS access network based on LDP DoD Security aspects specific to the MPLS access network based on LDP DoD
in the context of Seamless MPLS design are described in the security in the context of Seamless MPLS design are described in the security
section of [I-D.ietf-mpls-ldp-dod]. section of [RFC7032].
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
[ABR-FRR] 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] , , , and , "Archieving sub-second IGP convergence in [ACM01] Francois, P., Filsfils, C., Evans, J., and O. Bonaventure,
large IP networks, ACM SIGCOMM Computer Communication "Archiving sub-second IGP convergence in large IP
Review, v.35 n.3", July 2005. networks, ACM SIGCOMM Computer Communication Review, v.35
n.3", July 2005.
[BGP-PIC] "BGP PIC, Technical Report", November 2007.
[I-D.bashandy-bgp-edge-node-frr] [I-D.bashandy-bgp-edge-node-frr]
Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP
FRR Protection against Edge Node Failure", draft-bashandy- FRR Protection against Edge Node Failure", draft-bashandy-
bgp-edge-node-frr-03 (work in progress), July 2012. bgp-edge-node-frr-03 (work in progress), July 2012.
[I-D.bashandy-bgp-frr-mirror-table] [I-D.bashandy-bgp-frr-mirror-table]
Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR
Protection against Edge Node Failure Using Table Mirroring Protection against Edge Node Failure Using Table Mirroring
with Context Labels", draft-bashandy-bgp-frr-mirror- with Context Labels", draft-bashandy-bgp-frr-mirror-
skipping to change at page 38, line 15 skipping to change at page 40, line 5
[I-D.bashandy-isis-bgp-edge-node-frr] [I-D.bashandy-isis-bgp-edge-node-frr]
Bashandy, A., "IS-IS Extension for BGP FRR Protection Bashandy, A., "IS-IS Extension for BGP FRR Protection
against Edge Node Failure", draft-bashandy-isis-bgp-edge- against Edge Node Failure", draft-bashandy-isis-bgp-edge-
node-frr-01 (work in progress), September 2012. node-frr-01 (work in progress), September 2012.
[I-D.bashandy-mpls-ldp-bgp-frr] [I-D.bashandy-mpls-ldp-bgp-frr]
Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node
Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp- Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp-
bgp-frr-00 (work in progress), March 2012. bgp-frr-00 (work in progress), March 2012.
[I-D.ietf-karp-routing-tcp-analysis]
.
[I-D.ietf-mpls-ldp-dod]
Beckhaus, T., Decraene, B., Tiruveedhula, K.,
Konstantynowicz, M., and L. Martini, "LDP Downstream-on-
Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work
in progress), July 2013.
[I-D.ietf-rtgwg-bgp-pic]
.
[I-D.ietf-rtgwg-remote-lfa] [I-D.ietf-rtgwg-remote-lfa]
. Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06
(work in progress), May 2014.
[I-D.minto-2547-egress-node-fast-protection] [I-D.minto-2547-egress-node-fast-protection]
Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress
PE Fast Failure Protection", draft-minto-2547-egress-node- PE Fast Failure Protection", draft-minto-2547-egress-node-
fast-protection-02 (work in progress), July 2013. fast-protection-02 (work in progress), July 2013.
[I-D.rtgwg-bgp-pic]
Bashandy, A., Filsfils, C., and P. Mohapatra, "Abstract",
draft-rtgwg-bgp-pic-02 (work in progress), October 2013.
[PE-FRR] 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", .
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
skipping to change at page 39, line 12 skipping to change at page 40, line 43
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
2010. 2010.
[RFC5920] . [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6571] . [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, June 2012.
[RFC7032] . [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
[RFC7032] Beckhaus, T., Decraene, B., Tiruveedhula, K.,
Konstantynowicz, M., and L. Martini, "LDP Downstream-on-
Demand in Seamless MPLS", RFC 7032, October 2013.
Authors' Addresses Authors' Addresses
Nicolai Leymann (editor) Nicolai Leymann (editor)
Deutsche Telekom AG Deutsche Telekom AG
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
DE DE
Phone: +49 30 8353-92761 Phone: +49 30 8353-92761
 End of changes. 67 change blocks. 
153 lines changed or deleted 239 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/