draft-ietf-mpls-seamless-mpls-03.txt   draft-ietf-mpls-seamless-mpls-04.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: November 14, 2013 France Telecom Expires: January 17, 2014 Orange
C. Filsfils C. Filsfils
M. Konstantynowicz, Ed. M. Konstantynowicz, Ed.
Cisco Systems Cisco Systems
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
May 13, 2013 July 16, 2013
Seamless MPLS Architecture Seamless MPLS Architecture
draft-ietf-mpls-seamless-mpls-03 draft-ietf-mpls-seamless-mpls-04
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 November 14, 2013. This Internet-Draft will expire on January 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 39 skipping to change at page 2, line 39
2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9
2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15
4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15
4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16
4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 16
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . 18 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 18
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 18
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 19
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20
5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 20
5.1.8. Network Availability . . . . . . . . . . . . . . . . 22 5.1.8. Network Availability . . . . . . . . . . . . . . . . 21
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 21
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 22
5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent
Convergence . . . . . . . . . . . . . . . . . . . 24 Convergence . . . . . . . . . . . . . . . . . . . 22
5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 23
5.1.8.5. Assessing loss of connectivity upon any failure . 25 5.1.8.5. Assessing loss of connectivity upon any failure . 24
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29
5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 29
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 30
5.2.1. Control and Data Plane State for Deployment Scenario 5.2.1. Control and Data Plane State for Deployment Scenario
#1 . . . . . . . . . . . . . . . . . . . . . . . . . 31 #1 . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 30
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33
5.2.1.5. Numerical application for use case #1 . . . . . . 34 5.2.1.5. Numerical application for use case #1 . . . . . . 33
5.2.1.6. Numerical application for use case #2 . . . . . . 35 5.2.1.6. Numerical application for use case #2 . . . . . . 34
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8.1. Access Network Security . . . . . . . . . . . . . . . . . 37 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
8.3. Control Plane Security . . . . . . . . . . . . . . . . . 38 9.2. Informative References . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 38
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.
Seamless MPLS extends the core domain and integrates aggregation and Seamless MPLS extends the core domain and integrates aggregation and
access domains into a single MPLS domain ("Seamless MPLS"). This access domains into a single MPLS domain ("Seamless MPLS"). This
enables a very flexible deployment of an end to end service delivery. enables a very flexible deployment of an end to end service delivery.
In order to obtain a highly scalable architecture Seamless MPLS takes In order to obtain a highly scalable architecture Seamless MPLS takes
into account that typical access devices (DSLAMs, MSAN) are lacking into account that typical access devices (DSLAMs, MSAN) are lacking
some advanced MPLS features, and may have more scalability some advanced MPLS features, and may have more scalability
limitations. Hence access devices are kept as simple as possible. limitations. Hence access devices are kept as simple as possible.
skipping to change at page 5, line 32 skipping to change at page 5, line 27
o Use Case: Describes a typical network including service creation o Use Case: Describes a typical network including service creation
points in order to describe the requirments, typical numbers etc. points in order to describe the requirments, typical numbers etc.
which need to be taken into account when applying the Seamless which need to be taken into account when applying the Seamless
MPLS architecture. MPLS architecture.
2. Motivation 2. Motivation
MPLS is deployed in core and aggregation network for several years MPLS is deployed in core and aggregation network for several years
and provides a mature and stable basis for large networks. In and provides a mature and stable basis for large networks. In
addition MPLS is already used in access networks, e.g. such as addition MPLS is already used in access networks, e.g. such as mobile
mobile or DSL backhaul. Today MPLS as technology is being used on or DSL backhaul. Today MPLS as technology is being used on two
two different layers: different layers:
o the Transport Layer and o the Transport Layer and
o the Service Layer (e.g. for MPLS VPNs) o the Service Layer (e.g. for MPLS VPNs)
In both cases the protocols and the encapsulation are identical but In both cases the protocols and the encapsulation are identical but
the use of MPLS is different especially concerning the signalling, the use of MPLS is different especially concerning the signalling,
the control plane, the provisioning, the scalability and the the control plane, the provisioning, the scalability and the
frequency of updates. On the service layer only service specific frequency of updates. On the service layer only service specific
information is exchanged; every service can potentially deploy it's information is exchanged; every service can potentially deploy it's
own architecture and individual protocols. The services are running own architecture and individual protocols. The services are running
on top of the transport layer. Nevertheless those deployments are on top of the transport layer. Nevertheless those deployments are
usually isolated, focussed on a single use case and not integrated usually isolated, focussed on a single use case and not integrated
into an end-to-end manner. into an end-to-end manner.
skipping to change at page 6, line 32 skipping to change at page 6, line 27
restrict the number of options to implement and/or scales for restrict the number of options to implement and/or scales for
vendors, reduce interoperability and debugging issues for SP). vendors, reduce interoperability and debugging issues for SP).
Many aggregation networks are already deploying MPLS but are limited Many aggregation networks are already deploying MPLS but are limited
to the use of MPLS per aggregation area. Those MPLS based to the use of MPLS per aggregation area. Those MPLS based
aggregation domains are connected to a core network running MPLS as aggregation domains are connected to a core network running MPLS as
well. Nevertheless most of the services are not limited to an well. Nevertheless most of the services are not limited to an
aggregation domain but running between several aggregation domains aggregation domain but running between several aggregation domains
crossing the core network. In the past it was necessary to provide crossing the core network. In the past it was necessary to provide
connectivity between the different domains and the core on a per connectivity between the different domains and the core on a per
service level and not based on MPLS (e.g. by deploying native IP- service level and not based on MPLS (e.g. by deploying native IP-
Routing or Ethernet based technologies between aggregation and core). Routing or Ethernet based technologies between aggregation and core).
In most cases service specific configurations on the border nodes In most cases service specific configurations on the border nodes
between core and aggregation were required. New services led to between core and aggregation were required. New services led to
additional configurations and changes in the provisioning tools (see additional configurations and changes in the provisioning tools (see
Figure 1). Figure 1).
With Seamless MPLS there are no technology boundaries and no topology With Seamless MPLS there are no technology boundaries and no topology
boundaries for the services. Network (or region) boundaries are for boundaries for the services. Network (or region) boundaries are for
scaling and manageability, and do not affect the service layer, since scaling and manageability, and do not affect the service layer, since
the Transport Pseudowire that carries packets from the AN to the SN the Transport Pseudowire that carries packets from the AN to the SN
skipping to change at page 8, line 10 skipping to change at page 8, line 4
######################### | ######################### |
# +--+ AGN11 +---+ AGN21 + +------+ # +--+ AGN11 +---+ AGN21 + +------+
# / | | /| |\ | | +--------+ # / | | /| |\ | | +--------+
+--#-+/ +-------+\/ +-------+ \| | | remote | +--#-+/ +-------+\/ +-------+ \| | | remote |
| AN | /\ + CORE +---......--+ AN | | AN | /\ + CORE +---......--+ AN |
+--#-+\ +-------+ \+-------+ /| | ####### | +--#-+\ +-------+ \+-------+ /| | ####### |
# \ | | | |/################### +--------+ # \ | | | |/################### +--------+
# +--+ AGN12 +---+ AGN22 +##+------+ P2P Business Service # +--+ AGN12 +---+ AGN22 +##+------+ P2P Business Service
############################## ##############################
PW2 +-------+ +-------+ PW2 +-------+ +-------+
Figure 2: Use Case #1: Service Creation Figure 2: Use Case #1: Service Creation
Figure 2 shows the different service creation points and the Figure 2 shows the different service creation points and the
corresponding pseudowires between the access nodes and the service corresponding pseudowires between the access nodes and the service
creation points. The use case does not show all PWs (e.g. not the creation points. The use case does not show all PWs (e.g. not the
PWs needed to support redundancy) in order to keep the figure simple. PWs needed to support redundancy) in order to keep the figure simple.
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 is located on an Service Node connected to the AGN2x. The PW (PW1)
(PW1) originated at the AN and terminates at the AGN2. A second originated at the AN and terminates at the AGN2. A second PW is
PW is deployed in the case where redundancy is needed on the AN deployed in the case where redundancy is needed on the AN (the
(the figure shows redundancy but this might not be the case for figure shows redundancy but this might not be the case for all ANs
all ANs in this Use Case). Additonal PWs can be deployed as well in this Use Case). Additonal PWs can be deployed as well in case
in case more than a single service creation is needed for the more than a single service creation is needed for the residential
residential service (e.g. one service creation point for Internet service (e.g. one service creation point for Internet access and a
access and a second service creation point for IPTV services). 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 10 skipping to change at page 9, line 4
/ | | /| | | | | | / | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+ +----+/ +-------+\/ +-------+ +------+ /+------+
| 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 ISIS L2 LDP
<-Access-><--Aggregation Domain--><---------Core---------> <-Access-><--Aggregation Domain--><---------Core--------->
Figure 3: Use Case #1: Redundancy Figure 3: Use Case #1: Redundancy
Figure 3 shows the redundancy at the access and aggregation network Figure 3 shows the redundancy at the access and aggregation network
deploying a two stage aggregation network (AGN1x/AGN2x). deploying a two stage aggregation network (AGN1x/AGN2x).
Nevertheless redundancy is not a MUST in this use case. It is also Nevertheless redundancy is not a must in this use case. It is also
possible to use non redundant connection between the ANs and AGN1 possible to use non redundant connection between the ANs and AGN1
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
skipping to change at page 11, line 47 skipping to change at page 11, line 44
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
2.3.2. Typical Numbers 2.3.2. Typical Numbers
Table 2 shows typical numbers which are expected for Use Case #2 for Table 2 shows typical numbers which are expected for Use Case #2 for
the purpose of establishing the transport LSPs. They do not take the purpose of establishing the transport LSPs. They do not take
into account the services built in addition. (e.g. 6PE will require into account the services built in addition. (e.g. 6PE will require
additional IPv6 routes). additional IPv6 routes).
+-------------------+---------------+ +-------------------+---------------+
| Parameter | Typical Value | | Parameter | Typical Value |
+-------------------+---------------+ +-------------------+---------------+
| IGP Control Plane | 2 | | IGP Control Plane | 2 |
| IP FIB | 2 | | IP FIB | 2 |
| LDP Control Plane | 1000 | | LDP Control Plane | 1000 |
| LDP FIB | 1000 | | LDP FIB | 1000 |
+-------------------+---------------+ +-------------------+---------------+
skipping to change at page 12, line 34 skipping to change at page 12, line 30
o Scalability: The network SHALL be scalable to the minimum of o Scalability: The network SHALL be scalable to the minimum of
100.000 nodes. 100.000 nodes.
o Fast convergence (sub second resilience) SHALL be supported. Fast o Fast convergence (sub second resilience) SHALL be supported. Fast
reroute (LFA) SHOULD be supported. reroute (LFA) SHOULD be supported.
o Flexibility: The Seamless MPLS architecture SHALL be applied to a o Flexibility: The Seamless MPLS architecture SHALL be applied to a
wide variety of existing MPLS deployments. It SHALL use a wide variety of existing MPLS deployments. It SHALL use a
flexible approach deploying building blocks with the possiblity to flexible approach deploying building blocks with the possiblity to
use certain features only if those features are needed (e.g. dual use certain features only if those features are needed (e.g. dual
homing ANs or fast reroute mechanisms). homing ANs or fast reroute mechanisms).
o Service independence: Service and transport layer SHALL be o Service independence: Service and transport layer SHALL be
decoupled. The architecture SHALL remove the need for service decoupled. The architecture SHALL remove the need for service
specific configurations on intermediate nodes. specific configurations on intermediate nodes.
o Native Multicast support: P2MP MPLS LSPs SHOULD be supported by o Native Multicast support: P2MP MPLS LSPs SHOULD be supported by
the Seamless MPLS architecture. the Seamless MPLS architecture.
o Interoperable end to end OAM mechanisms SHALL be implemented o Interoperable end to end OAM mechanisms SHALL be implemented
skipping to change at page 16, line 25 skipping to change at page 16, line 16
The inter-domain routing is responsible for establishing connectivity The inter-domain routing is responsible for establishing connectivity
between and across all MPLS domains. The inter-domain routing SHOULD between and across all MPLS domains. The inter-domain routing SHOULD
establish a routing and forwarding hierarchy in order to achieve the establish a routing and forwarding hierarchy in order to achieve the
scaling goals of seamless MPLS. Note that the IP aggregation usually scaling goals of seamless MPLS. Note that the IP aggregation usually
performed between region (IGP areas/AS) in IP routing does not work performed between region (IGP areas/AS) in IP routing does not work
for MPLS as MPLS is not capable of aggregating FEC (because MPLS for MPLS as MPLS is not capable of aggregating FEC (because MPLS
forwarding use an exact match lookup, while IP uses longest match). forwarding use an exact match lookup, while IP uses longest match).
Therefore it is RECOMMENDED to utilize protocols that support Therefore it is RECOMMENDED to utilize protocols that support
indirect next-hops (like BGP with MPLS labels "labled BGP/SAFI4" indirect next-hops ( e.g. using BGP to carry MPLS label information
[RFC3107]). [RFC3107] ).
4.6. Access 4.6. Access
Compared to the aggregation and core parts of the Seamless MPLS Compared to the aggregation and core parts of the Seamless MPLS
network the access part is special in two respects: network the access part is special in two respects:
o The number of ndes in the access is at least one order of o The number of ndes in the access is at least one order of
magnitude higher than in any other part of the network. magnitude higher than in any other part of the network.
o Because of the large quantity of access nodes, the cost of these o Because of the large quantity of access nodes, the cost of these
nodes is extremly relevant for the overall costs of the entire nodes is extremly 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 evalulating different seamless MPLS be kept in mind when evalulating 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.
5. Deployment Scenarios 5. Deployment Scenarios
skipping to change at page 17, line 26 skipping to change at page 17, line 16
This deployment scenario describes one way to implement a seamless This deployment scenario describes one way to implement a seamless
MPLS architecture. Specific to this implementation is the choice of MPLS architecture. Specific to this implementation is the choice of
intra- and inter-domain routing and label distribution protocols, as intra- and inter-domain routing and label distribution protocols, as
well as the details of the interworking of these protocols to achieve well as the details of the interworking of these protocols to achieve
the overall scalable hierarchical architecture. the overall scalable hierarchical architecture.
5.1.2. General Network Topology 5.1.2. General Network Topology
There are multiple aggregation domains (in the order of up to 100) There are multiple aggregation domains (in the order of up to 100)
connected to the core in a star topology, i.e. aggregation domains connected to the core in a star topology, i.e. aggregation domains
are never connected among themselves, but only to the core. The core are never connected among themselves, but only to the core. The core
has its own domain. has its own domain.
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
| | | | | | | | | | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | | / | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+ +----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/ | | AN | /\ \/ |
+----+\ +-------+ \+-------+ +------+/\ +------+ +----+\ +-------+ \+-------+ +------+/\ +------+
skipping to change at page 17, line 50 skipping to change at page 17, line 40
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
static route ISIS L1 LDP ISIS L2 LDP static route ISIS L1 LDP ISIS L2 LDP
<-Access-><--Aggregation Domain--><---------Core---------> <-Access-><--Aggregation Domain--><---------Core--------->
Figure 5: Deployment Scenario #1 Figure 5: Deployment Scenario #1
As shown in Figure 5, the access nodes (AN) are connected to the As shown in Figure 5, 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 18, line 37 skipping to change at page 18, line 26
for MPLS label distribution is used. for MPLS label distribution is used.
These MPLS domains are mapped to ISIS areas as follows: Aggregation These MPLS domains are mapped to ISIS areas as follows: Aggregation
domains are mapped to ISIS L1 areas. The core is configured as ISIS domains are mapped to ISIS L1 areas. The core is configured as ISIS
L2. The border routers connecting aggregation and core are ISIS L1L2 L2. The border routers connecting aggregation and core are ISIS L1L2
and are referred to as ABRs. From a technical and operational point and are referred to as ABRs. From a technical and operational point
of view these ABRs are part of the core, althought they also belong of view these ABRs are part of the core, althought they also belong
to the respective aggregation domain purely from a routing protocol to the respective aggregation domain purely from a routing protocol
point of view. point of view.
For the interdomain-routing BGP with MPLS labels is deployed ("labled For the inter-domain routing BGP with MPLS labels is
BGP/SAFI4" [RFC3107]). deployed[RFC3107].
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.
skipping to change at page 19, line 25 skipping to change at page 19, line 12
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
the AGN1 it is connected to. Appropriate techniques SHOULD be the AGN1 it is connected to. Appropriate techniques SHOULD be
deployed to make sure that a given default route is invalidated when deployed to make sure that a given default route is invalidated when
the link to an AGN1 or that node itself fails. Examples of such the link to an AGN1 or that node itself fails. Examples of such
techniques include monitoring the pysical link state for loss of techniques include monitoring the pysical link state for loss of
light/loss of frame, or using Ethernet link OAM or BFD light/loss of frame, or using Ethernet link OAM or BFD [RFC5881].
[I-D.ietf-bfd-v4v6-1hop].
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.
skipping to change at page 20, line 7 skipping to change at page 19, line 36
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.
5.1.5.1. LDP Downstream-on-Demand (DoD) 5.1.5.1. LDP Downstream-on-Demand (DoD)
LDP downstream-on-demand mode is specified in [RFC5036]. Although it LDP downstream-on-demand mode is specified in [RFC5036]. In this
was originally intended to be used with ATM switch hardware, there is mode the upstream LSR will explicitly ask the downstream LSR for a
nothing from a protocol perspective preventing its use in a regular label binding for a particular FEC when needed.
MPLS frame-based environment. In this mode the upstream LSR will
explicitly ask the downstream LSR for a label binding for a
particular FEC when needed.
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.
For LDP DoD the AGN1 MUST also ask the AN for label bindings for More detailed description of LDP DoD use cases for MPLS access and
specific FECs. FECs are necessary for all pseudowire destinations at list of required LDP DoD procedures in the context of Seamless MPLS
the AN. Most preferable this pseudowire destination is the LSR-ID of design is included in [I-D.ietf-mpls-ldp-dod].
the AN. Depending on the AN implementation and architecture multiple
pseudowire destination addresses and associated FECs could be needed.
The conclusion of this results to the following requirement:
o The AGN1 MUST ask the AN for label bindings for all potential
pseudowire destination addresses on the AN. Because the AGN (at
least in many cases) does not take part in the pseudowire
signaling an independent way of receiving the AN FEC is necessary
on the AGN. These potential pseudowire destinations MUST be known
on the AGN1, by configuration or otherwise. These are typically
the loopback addresses of the AN, to which a static route has been
configured anyway on the AGN1, as explained above. In addition to
these static routes, the AGN1 SHOULD be configured statically to
request MPLS label bindings for these loopback addresses via LDP
DoD.
o Optionally an automatism that asks for a FEC for the LSR-ID COULD
be implemented. A configuration switch that disables this option
must be implemented. The label is necessary. The way of
initiating the DoD-signaling of the label could be done with both
methods (configuration/automatism).
o The AN knows by configuration to which destination a pseudowire is
set up. The AN is always the endpoint of the pseudowire. Before
signalling a pseudowire the AN MUST ask (via LDP DoD) the AGN for
a FEC. Because of this an independent preconfiguration is not
necessary on the AN.
o The following are the triggers for ANs to request a label:
o
* When a control session (targeted LDP) to a target has to be
established
* When a service label has been received by a control session
(e.g. pseudo wire label)
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 22, line 5 skipping to change at page 20, line 44
there will be in the order of 100.000 routes in labeled BGP when there will be in the order of 100.000 routes in labeled BGP when
approaching the stated scalability goal. Note that this only affects approaching the stated scalability goal. Note that this only affects
the BGP RIB size and does not necessarily imply that any node needs the BGP RIB size and does not necessarily imply that any node needs
to actually have active forwarding state (LFIB) in the same order of to actually have active forwarding state (LFIB) in the same order of
magnitude. In fact, as will be discussed in the scalability magnitude. In fact, as will be discussed in the scalability
analysis, no single node needs to install all labeled BGP routes into analysis, no single node needs to install all labeled BGP routes into
the LFIB, but each node only needs a small percentage of the RIB as the LFIB, but each node only needs a small percentage of the RIB as
active forwarding state in the LFIB. And from a RIB point of view, active forwarding state in the LFIB. And from a RIB point of view,
BGP is known to scale to hundreds of thousands of routes. BGP is known to scale to hundreds of thousands of routes.
5.1.7. Labled iBGP next-hop handling 5.1.7. Labeled iBGP next-hop handling
The ABR nodes run labeled iBGP both to the core mesh as well as to The ABR nodes run labeled iBGP both to the core mesh as well as to
the AGN1 nodes of their respective aggregation domains. Therefore the AGN1 nodes of their respective aggregation domains. Therefore
they operate as iBGP route reflectors, reflecting labeled routes from they operate as iBGP route reflectors, reflecting labeled routes from
the aggregation into the core and vice versa. the aggregation into the core and vice versa.
When reflecting routes from the core into the aggregation domain, the When reflecting routes from the core into the aggregation domain, the
ABR SHOULD NOT change the BGP NEXT-HOP addresses (next-hop- ABR SHOULD NOT change the BGP NEXT-HOP addresses (next-hop-
unchanged). This is the usual behaviour for iBGP route reflection. unchanged). This is the usual behaviour for iBGP route reflection.
In order to make these routes resolvable to the AGN1 nodes inside the In order to make these routes resolvable to the AGN1 nodes inside the
skipping to change at page 23, line 45 skipping to change at page 22, line 36
any arcane knob). any arcane knob).
5.1.8.2. Per-Prefix LFA FRR 5.1.8.2. Per-Prefix LFA FRR
A per-prefix LFA for a destination D is a precomputed backup IGP A per-prefix LFA for a destination D is a precomputed backup IGP
nexthop for that destination. This backup IGP nexthop can be link nexthop for that destination. This backup IGP nexthop can be link
protecting or node protecting [RFC5286]. protecting or node protecting [RFC5286].
The analysis of the applicability of Per-Prefix LFA in the deployment The analysis of the applicability of Per-Prefix LFA in the deployment
model 1 of Seamless MPLS architecture is straightforward thanks to model 1 of Seamless MPLS architecture is straightforward thanks to
[I-D.filsfils-rtgwg-lfa-applicability]. [RFC6571].
In deployment model 1, each aggregation network either follows the In deployment model 1, each aggregation network either follows the
triangle or full-mesh topology. Further more, the backbone region triangle or full-mesh topology. Further more, the backbone region
implements a dual-plane. As a consequence, the failure of any link implements a dual-plane. As a consequence, the failure of any link
or node within an aggregation domain is protected by LFA FRR (sub- or node within an aggregation domain is protected by LFA FRR (sub-
50msec) for all impacted IGP prefixes, whether intra-area or inter- 50msec) for all impacted IGP prefixes, whether intra-area or inter-
area. No uloop may form as a result of these failures area. No uloop may form as a result of these failures [RFC6571].
[I-D.filsfils-rtgwg-lfa-applicability].
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 [RFC6571]. It certainly is in the context of deployment
in the context of deployment case study 1 as the designer enforced case study 1 as the designer enforced triangle and full-mesh
triangle and full-mesh topologies in the aggregation network as well topologies in the aggregation network as well as a dual-plane core
as a dual-plane core 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 [BGP-PIC] extends the hierarchical
dataplane with the concept of a BGP Path-List. A BGP path-list may 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. be abstracted as a set of primary multipath nhops and a backup nhop.
When the primary set is empty, packets destined to the BGP When the primary set is empty, packets destined to the BGP
skipping to change at page 24, line 50 skipping to change at page 23, line 33
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
backup path in the FIB. BGP egress node FRR relies on a transit LSR backup path in the FIB. BGP egress node FRR relies on a transit LSR
( Point of Local Repair, PLR ) adjacent to the failed protected BGP ( Point of Local Repair, PLR ) adjacent to the failed protected BGP
router to detect the failure and re-route the traffic to the backup router to detect the failure and re-route the traffic to the backup
BGP router. Number of BGP egress node FRR schemes are being BGP router. Number of BGP egress node FRR schemes are being
investigated: [PE-FRR], [ABR-FRR], investigated: [PE-FRR], [ABR-FRR],
[I-D.draft-minto-2547-egress-node-fast-protection-00], [I-D.minto-2547-egress-node-fast-protection],
[I-D.draft-minto-2547-egress-node-fast-protection-00], [I-D.bashandy-bgp-edge-node-frr],
[I-D.draft-minto-2547-egress-node-fast-protection-00]. [I-D.bashandy-idr-bgp-repair-label], [I-D.bashandy-mpls-ldp-bgp-frr],
[I-D.bashandy-bgp-frr-mirror-table],
[I-D.bashandy-bgp-frr-vector-label],
[I-D.bashandy-isis-bgp-edge-node-frr].
Differences between these schemes relate to the way backup and Differences between these schemes relate to the way backup and
protected BGP routers get associated, how the protected router's BGP protected BGP routers get associated, how the protected router's BGP
state is signalled to the backup BGP router(s) and if any other state state is signalled to the backup BGP router(s) and if any other state
is required on protected, backup and PLR routers. The schemes also is required on protected, backup and PLR routers. The schemes also
differ in compatibility with IPFRR and TEFRR schemes to enable PLR to differ in compatibility with IP-FRR and TE-FRR schemes to enable PLR
switch traffic towards the backup BGP router in case of protected BGP to switch traffic towards the backup BGP router in case of protected
router failure. BGP router failure.
In the Seamless MPLS design, BGP egress node FRR schemes can protect In the Seamless MPLS design, BGP egress node FRR schemes can protect
against the failures of PE, AGN and ABR nodes with no requirements on against the failures of PE, AGN and ABR nodes with no requirements on
ingress routers. ingress routers.
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 in the Seamless MPLS connectivity (LoC) upon each possible failure in the Seamless MPLS
design in the deployment scenario #1. design in the deployment scenario #1.
skipping to change at page 26, line 32 skipping to change at page 25, line 20
of impacted important IGP routes in a seamless architecture is much of impacted important IGP routes in a seamless architecture is much
smaller than 2960 routes. 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 [RFC6571] for LFA
[I-D.filsfils-rtgwg-lfa-applicability] for LFA applicability. applicability.
As explained in [I-D.filsfils-rtgwg-lfa-applicability], another As explained in [RFC6571], another alternative to provide <50msec in
alternative to provide <50msec in this case consists in using an this case consists in using an MPLS-TE full-mesh and MPLS-TE FRR.
MPLS-TE full-mesh and MPLS-TE FRR. This is required when the This is required when the designer is not able or does not want to
designer is not able or does not want to optimize the topology for optimize the topology for LFA applicability and he wants to achieve
LFA applicability and he wants to achieve <50msec protection. <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 routes in a seamless the number of impacted important IGP routes in a seamless
architecture is much smaller than 2960 routes. 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
skipping to change at page 29, line 32 skipping to change at page 28, line 29
requirement for operational simplicity. requirement for operational simplicity.
In a network with 10k of IGP/BGP nodes and 100k of MPLS-enabled In a network with 10k of IGP/BGP nodes and 100k of MPLS-enabled
nodes, it is extremely important to provide a simple operational nodes, it is extremely important to provide a simple operational
process. process.
LFA FRR plays a key role in providing simplicity as it is an LFA FRR plays a key role in providing simplicity as it is an
automated behavior which does not require any configuration or automated behavior which does not require any configuration or
interoperability testing. interoperability testing.
More specifically, [I-D.filsfils-rtgwg-lfa-applicability] plays a key More specifically, [RFC6571] plays a key role in the Seamless MPLS
role in the Seamless MPLS architecture as it describes simple design architecture as it describes simple design guidelines which
guidelines which determiniscally ensure LFA coverage for any link and determiniscally ensure LFA coverage for any link and node in the
node in the aggregation regions of the network. This is key as it aggregation regions of the network. This is key as it provides for a
provides for a simple <50msec protection for the vast majority of the simple <50msec protection for the vast majority of the node and link
node and link failures (>90% of the IGP/BGP3107 footprint at least). 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 remote LFA on (1) augmenting native LFA coverage with remote LFA
[I-D.draft-ietf-rtgwg-remote-lfa-00], or (2) augmenting native LFA [I-D.draft-ietf-rtgwg-remote-lfa], or (2) augmenting native LFA
coverage with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP coverage with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP
convergence. The first option provides an automatic and fairly convergence. The first option provides an automatic and fairly
simple sub-50msec protection as LFA without introducing any simple sub-50msec protection as LFA without introducing any
additional protocols. The second option provides the same sub-50msec additional protocols. The second option provides the same sub-50msec
protection as LFA, but introduces additional RSVP LSPs. The thrid protection as LFA, but introduces additional RSVP LSPs. The thrid
option optimizes for sub-50msec protection, but implies a more option optimizes for sub-50msec protection, but implies a more
complex operational model. The fourth option optimizes for simple complex operational model. The fourth option optimizes for simple
operation but only provides <1 sec protection. Up to each designer operation but only provides <1 sec protection. Up to each designer
to arbitrate between these three options versus the possibility to to arbitrate between these three options versus the possibility to
engineer the topology for native LFA protection. engineer the topology for native LFA protection.
skipping to change at page 31, line 37 skipping to change at page 30, line 37
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 Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC
which are outside of their routing domain. Those 100 remote FEC which are outside of their routing domain. Those 100 remote FEC
are the same for all Access Nodes of a given AGN. 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
skipping to change at page 34, line 28 skipping to change at page 33, line 28
In the aggregation areas, IGP and LDP are affected by the number of In the aggregation areas, IGP and LDP are affected by the number of
core nodes and the number of AGN and AN in their area. They are not core nodes and the number of AGN and AN in their area. They are not
affected by the total number of AGN or AN in the seamless MPLS affected by the total number of AGN or AN in the seamless MPLS
domain. domain.
No FIB of any node is required to handle the total number of AGN or No FIB of any node is required to handle the total number of AGN or
AN in the seamless MPLS domain. In other word, the number of AGN and AN in the seamless MPLS domain. In other word, the number of AGN and
AN in the seamless MPLS domain is not limited, if the number of areas AN in the seamless MPLS domain is not limited, if the number of areas
can grow accordingly. The main limitation is the MPLS connectivity can grow accordingly. The main limitation is the MPLS connectivity
requirements on the AN, i.e. mainly the number of LSP needed on the requirements on the AN, i.e. mainly the number of LSP needed on the
AN. Another limitation may be the number of different LSP needed by AN. Another limitation may be the number of different LSP needed by
AN attached or behind an AGN. However, given foreseen deployments AN attached or behind an AGN. However, given foreseen deployments
and current AGN capabilities, this is not expected to be a and current AGN capabilities, this is not expected to be a
limitation. limitation.
In the control plane, BGP will typically handle all AN routes. This In the control plane, BGP will typically handle all AN routes. This
is significant but target deployments are well under current is significant but target deployments are well under current
equipments capacities. In addition, if required, additional equipments capacities. In addition, if required, additional
techniques could be used to improve this scalability, based on the techniques could be used to improve this scalability, based on the
experience gained with scaling BGP/MPLS VPN (e.g. route partitioning experience gained with scaling BGP/MPLS VPN (e.g. route partitioning
between RR planes, route filtering (static or dynamic with ORF or between RR planes, route filtering (static or dynamic with ORF or
route refresh) between AN and on AGN to improve AGN scalability. route refresh) between AN and on AGN to 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
skipping to change at page 36, line 23 skipping to change at page 35, line 23
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, Kireeti Kompella, Yakov Rekhter, Mark Tinka and 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 does not include any requests to IANA.
All drafts are required to have an IANA considerations section (see
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
section contains an explicit statement that this is the case (as
above). If there are no requirements for IANA, the section will be
removed during conversion into an RFC by the RFC Editor.
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 the LDP specification RFC5036 measures are considered as described in Security Framework for MPLS
[RFC5036] including ensuring authenticity and integrity of LDP and GMPLS networks [RFC5920], in the LDP specification RFC5036
messages, as well as protection against spoofing and Denial of [RFC5036] and in [I-D.ietf-karp-routing-tcp-analysis]including
Service attacks. Some deployments may require increased measures of ensuring authenticity and integrity of LDP messages, as well as
network security if a subset of Access Nodes are placed in locations protection against spoofing and Denial of Service attacks. Some
with lower levels of physical security e.g. street cabinets ( common deployments may require increased measures of network security if a
practice for VDSL access ). In such cases it is the responsibility subset of Access Nodes are placed in locations with lower levels of
of the system designer to take into account the physical security physical security e.g. street cabinets ( common practice for VDSL
measures ( environmental design, mechanical or electronic access access ). In such cases it is the responsibility of the system
control, intrusion detection ), as well as monitoring and auditing designer to take into account the physical security measures (
measures (configuration and Operating System changes, reloads, routes environmental design, mechanical or electronic access control,
advertisements ). But even with all this in mind, the designer still intrusion detection ), as well as monitoring and auditing measures
should consider network security risks and adequate measures arising (configuration and Operating System changes, reloads, routes
from the lower level of physical security of those locations. advertisements ).
8.1. Access Network Security
A detailed description for Access Network Security in Seamless MPLS
can be found in the LDP Downstream on Demand document
[I-D.ietf-mpls-ldp-dod].
8.2. Data Plane Security
Data plane security risks applicable to the access MPLS network are
listed below (a non-exhaustive list):
a. packets from a specific access node flow to an altered transport
layer or service layer destination.
b. packets belonging to undefined services flow to and from the
access network.
c. unlabelled packets destined to remote network nodes.
Following mechanisms should be considered to address listed data
plane security risks:
1. addressing (a) - Access and ABR LSRs SHOULD NOT accept labeled
packets over a particular data link, unless from the Access or
ABR LSR perspective this data link is known to attach to a
trusted system based on employed authentication mechanism(s), and
the top label has been distributed to the upstream neighbour by
the receiving Access or ABR LSR.
2. addressing (a) - ABR LSR MAY restrict network reachability for
access devices to a subset of remote network LSR, based on
authentication or other network security technologies employed
towards Access LSRs. Restricted reachability can be enforced on
the ABR LSR using local routing policies, and can be distributed
towards the core MPLS network using routing policies associated
with access MPLS FECs.
3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP)
are not accepted from unreliable routing peers. Detection of
unreliable routing peers is achieved by engaging routing protocol
detection and alarm mechanisms, and is out of scope of this
document.
4. addressing (a) and (b) - no successful attacks have been mounted
on the control plane and has been detected.
5. addressing (c) - ABR LSR MAY restrict IP network reachability to
and from the access LSR.
8.3. Control Plane Security
Similarly to Inter-AS MPLS/VPN deployments RFC4364 [RFC4364], the
data plane security depends on the security of the control plane. To
ensure control plane security access LDP DoD connections MUST only be
made with LDP peers that are considered trusted from the local LSR
perspective, meaning they are reachable over a data link that is
known to attach to a trusted system based on employed authentication
mechanism(s) on the local LSR. The TCP/IP MD5 authentication option
RFC5925 [RFC5925] should be used with LDP as described in LDP
specification RFC5036 [RFC5036]. If TCP/IP MD5 authentication is
considered not secure enough, the designer may consider using a more
elaborate and advanced TCP Authentication Option (TCP-AO RFC5925
[RFC5925]) for LDP session authentication. Access IGP (if used) and
any routing protocols used in access network for signalling service
routes SHOULD also be secured in a similar manner. For increased
level of authentication in the control plane security for a subset of
access locations with lower physical security, designer could also
consider using:
o different crypto keys for use in authentication procedures for
these locations.
o stricter network protection mechanisms including DoS protection, Security aspects specific to the MPLS access network based on LDP DoD
interface and session flap dampening. in the context of Seamless MPLS design are described in the security
section of [I-D.ietf-mpls-ldp-dod].
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] , , , , "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.
[BGP-PIC] , "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.bashandy-bgp-edge-node-frr]
, . Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP
FRR Protection against Edge Node Failure", draft-bashandy-
bgp-edge-node-frr-03 (work in progress), July 2012.
[I-D.draft-bashandy-bgp-frr-mirror-table-00] [I-D.bashandy-bgp-frr-mirror-table]
, . Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR
Protection against Edge Node Failure Using Table Mirroring
with Context Labels", draft-bashandy-bgp-frr-mirror-
table-00 (work in progress), October 2012.
[I-D.draft-ietf-rtgwg-remote-lfa-00] [I-D.bashandy-bgp-frr-vector-label]
, . Bashandy, A., Kumar, N., and M. Konstantynowicz, "BGP FRR
Protection against Edge Node Failure Using Vector Labels",
draft-bashandy-bgp-frr-vector-label-00 (work in progress),
July 2012.
[I-D.draft-minto-2547-egress-node-fast-protection-00] [I-D.bashandy-idr-bgp-repair-label]
, . Bashandy, A., Pithawala, B., and J. Heitz, "Scalable,
Loop-Free BGP FRR using Repair Label", draft-bashandy-idr-
bgp-repair-label-04 (work in progress), May 2012.
[I-D.filsfils-rtgwg-lfa-applicability] [I-D.bashandy-isis-bgp-edge-node-frr]
Filsfils, C., Francois, P., Shand, M., Decraene, B., Bashandy, A., "IS-IS Extension for BGP FRR Protection
Uttaro, J., Leymann, N., and M. Horneffer, "LFA against Edge Node Failure", draft-bashandy-isis-bgp-edge-
applicability in SP networks", draft-filsfils-rtgwg-lfa- node-frr-01 (work in progress), September 2012.
applicability-00 (work in progress), March 2010.
[I-D.ietf-bfd-v4v6-1hop] [I-D.bashandy-mpls-ldp-bgp-frr]
Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node
Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp-
January 2010. bgp-frr-00 (work in progress), March 2012.
[I-D.draft-ietf-rtgwg-remote-lfa]
, .
[I-D.ietf-karp-routing-tcp-analysis]
, .
[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-06 (work Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work
in progress), May 2013. in progress), July 2013.
[I-D.kothari-henderickx-l2vpn-vpls-multihoming]
Kothari, B., Kompella, K., Henderickx, W., and F. Balus,
"BGP based Multi-homing in Virtual Private LAN Service",
draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work
in progress), July 2009.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", draft-narten-iana-
considerations-rfc2434bis-09 (work in progress), March
2008.
[I-D.raggarwa-mac-vpn]
Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and
F. Balus, "BGP MPLS Based MAC VPN", draft-raggarwa-mac-
vpn-01 (work in progress), June 2010.
[I-D.sajassi-l2vpn-rvpls-bgp] [I-D.minto-2547-egress-node-fast-protection]
Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and Jeganathan, J. and H. Gredler, "2547 egress PE Fast
S. Boutros, "Routed VPLS using BGP", draft-sajassi-l2vpn- Failure Protection", draft-minto-2547-egress-node-fast-
rvpls-bgp-01 (work in progress), July 2010. protection-01 (work in progress), October 2012.
[PE-FRR] Le Roux, J.L., Decraene, B., and Z. Ahmad, "Fast Reroute [PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in
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.T., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
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
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,
F., and F. Ansari, "Overview of IP Multicast in a Multi-
Protocol Label Switching (MPLS) Environment", RFC 3353,
August 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
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.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
Multicast Encapsulations", RFC 5332, August 2008. (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5920] , .
Authentication Option", RFC 5925, June 2010.
Authors' Addresses [RFC6571] , .
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
Email: n.leymann@telekom.de Email: n.leymann@telekom.de
Bruno Decraene Bruno Decraene
France Telecom Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9 92794
FR FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Brussels Brussels
Belgium Belgium
 End of changes. 62 change blocks. 
315 lines changed or deleted 168 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/