draft-ietf-mpls-seamless-mpls-04.txt   draft-ietf-mpls-seamless-mpls-05.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: January 17, 2014 Orange Expires: July 16, 2014 Orange
C. Filsfils C. Filsfils
M. Konstantynowicz, Ed. M. Konstantynowicz, Ed.
Cisco Systems Cisco Systems
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
July 16, 2013 January 12, 2014
Seamless MPLS Architecture Seamless MPLS Architecture
draft-ietf-mpls-seamless-mpls-04 draft-ietf-mpls-seamless-mpls-05
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 January 17, 2014. This Internet-Draft will expire on July 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6 2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6
2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9 2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 12
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15
4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16
4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16
4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 16 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 16 5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . 19
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 18 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 19 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20
5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 20 5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 21
5.1.8. Network Availability . . . . . . . . . . . . . . . . 21 5.1.8. Network Availability . . . . . . . . . . . . . . . . 22
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 21 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 22
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 22 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23
5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent
Convergence . . . . . . . . . . . . . . . . . . . 22 Convergence . . . . . . . . . . . . . . . . . . . 23
5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 23 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24
5.1.8.5. Assessing loss of connectivity upon any failure . 24 5.1.8.5. Assessing loss of connectivity upon any failure . 24
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29
5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 29 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . . . . . 30 #1 . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 30 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33
5.2.1.5. Numerical application for use case #1 . . . . . . 33 5.2.1.5. Numerical application for use case #1 . . . . . . 34
5.2.1.6. Numerical application for use case #2 . . . . . . 34 5.2.1.6. Numerical application for use case #2 . . . . . . 35
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 36
9.2. Informative References . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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 6, line 12 skipping to change at page 6, line 12
points which can be virtually everywhere in the network. This points which can be virtually everywhere in the network. This
enables network and service providers with a flexible service and enables network and service providers with a flexible service and
service creation. Service creation can be done based on the existing service creation. Service creation can be done based on the existing
requirements without the needs for dedicated service creation areas requirements without the needs for dedicated service creation areas
on fixed locations. With the flexibility of Seamless MPLS the on fixed locations. With the flexibility of Seamless MPLS the
service creation can be done anywhere in the network and easily moved service creation can be done anywhere in the network and easily moved
between different locations. between different locations.
2.1. Why Seamless MPLS 2.1. Why Seamless MPLS
Multiple SP plan to deploy networks with 10k to 100k MPLS nodes. Multiple Service Providers plan to deploy networks with 10k to 100k
This is typically at least one order of magnitude higher than typical MPLS nodes, with varying levels of MPLS LSP connectivity between
deployments and may require a new architecture. Multiple options are those nodes - sparse-mesh in access, partial-mesh in aggregation and
possible and it makes sense for the industry (both vendors and SP) to full-mesh in core. This is typically at least one order of magnitude
restrict the options in order to ease the first deployments (e.g. higher than current deployments and may require a new architecture.
restrict the number of options to implement and/or scales for Multiple options are possible and it makes sense for the industry
vendors, reduce interoperability and debugging issues for SP). (both vendors and SP) to restrict the options in order to ease the
first deployments (e.g. restrict the number of options to implement
and/or scales for 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).
skipping to change at page 6, line 46 skipping to change at page 7, line 5
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
doesn't care whether it takes two hops or twenty, nor how many region doesn't care whether it takes two hops or twenty, nor how many region
boundaries it needs to cross. The network architecture is about boundaries it needs to cross. The network architecture is about
network scaling, network resilience and network manageability; the network scaling, network resilience and network manageability; the
service architecture is about optimal delivery: service scaling, service architecture is about optimal delivery: service scaling,
service resilience (via replicated SNs) and service manageability. service resilience (via replicated SNs) and service manageability.
The two are decoupled: each can be managed separately and changed The two are decoupled: each can be managed separately and changed
independently. independently.
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
| Aggregation | | Core | | Aggregation | | Aggregation | | Core | | Aggregation |
| Domain #1 +---------+ Domain +---------+ Domain #2 | | Domain #1 +---------+ Domain +---------+ Domain #2 |
| MPLS | ^ | MPLS | ^ | MPLS | | MPLS | ^ | MPLS | ^ | MPLS |
+--------------+ | +--------------+ | +--------------+ +--------------+ | +--------------+ | +--------------+
| | | |
+------ service specific ------+ +------ service specific ------+
configuration configuration
Figure 1: Service Specific Configurations Figure 1: Service Specific Configurations
One of the main motivations of Seamless MPLS is to get rid of One of the main motivations of Seamless MPLS is to get rid of service
services specific configurations between the different MPLS islands. specific configurations between the different MPLS islands. Seamless
Seamless MPLS connects all MPLS domains on the MPLS transport layer MPLS connects all MPLS domains on the MPLS transport layer providing
providing a single transport layer for all services - independent of a single transport layer for all services - independent of the
the service itself. The Seamless MPLS architecture therefore service itself. The Seamless MPLS architecture therefore decuples
decuples the service and transport layer and integrates access, the service and transport layer and integrates access, aggregation
aggregation and core into a single platform. One of the big and core into a single platform. One of the big advantages is that
advantages is that problems on the transport layer only need to be problems on the transport layer only need to be solved once (and the
solved once (and the solutions are available to all services). With solutions are available to all services). With Seamless MPLS it is
Seamless MPLS it is not necessary to use service specific not necessary to use service specific configurations on intermediate
configurations on intermediate nodes; all services can be deployed in nodes; all services can be deployed in an end to end manner.
an end to end manner.
2.2. Use Case #1 2.2. Use Case #1
2.2.1. Description 2.2.1. Description
In most cases at least residential and business services need to be In most cases at least residential and business services need to be
supported by a network. This section describes a Seamless MPLS use supported by a network. This section describes a Seamless MPLS use
case which supports such a scenario. The use case includes point to case which supports such a scenario. The use case includes point to
point services for business customers as well as typical service point services for business customers as well as typical service
creation for residential customers. creation for residential customers.
+-------------+ +-------------+
| Service | | Service |
| Creation | | Creation |
| Residential | | Residential |
| Customers | | Customers |
+------+------+ +------+------+
| |
| |
| |
PW1 +-------+ +---+---+ PW1 +-------+ +---+---+
######################### | ######################### |
# +--+ 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)
skipping to change at page 8, line 38 skipping to change at page 9, line 11
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.
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
| | | | | | | | | | | | | | | |
+--+ 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 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
skipping to change at page 10, line 19 skipping to change at page 11, line 5
Table 1: Use Case #1: Typical Numbers for Access Node Table 1: Use Case #1: Typical Numbers for Access Node
2.3. Use Case #2 2.3. Use Case #2
2.3.1. Description 2.3.1. Description
In most cases, residential, wholesales and business services need to In most cases, residential, wholesales and business services need to
be supported by the network. be supported by the network.
+-------------+ +-------------+
| Service | | Service |
| platforms | | platforms |
|(VoIP, VoD..)| |(VoIP, VoD..)|
| Residential | | Residential |
| Customers | | Customers |
+------+------+ +------+------+
| |
| |
+---+ +-----+ +--+--+ +-----+ +---+ +-----+ +--+--+ +-----+
|AN1|----+AGN11+--+AGN21+---+ ABR | |AN1|----+AGN11+--+AGN21+---+ ABR |
+---+ +--+--+ +--+--+ +--+--+ +---+ +--+--+ +--+--+ +--+--+
| | | | | |
+---+ +--+--+ | | +----+ +---+ +--+--+ | | +----+
|AN2|----+AGN12+ | | --+ PE | |AN2|----+AGN12+ | | --+ PE |
+---+ +--+--+ | | +----+ +---+ +--+--+ | | +----+
| | | | | |
. | | . | |
. | | . | |
. | | . | |
| | | | | |
+---+ +---+ +--+--+ +--+--+ +--+--+ +---+ +---+ +--+--+ +--+--+ +--+--+
|AN4+---+AN3|----+AGN1x+--+AGN22+---+ ABR | |AN4+---+AN3|----+AGN1x+--+AGN22+---+ ABR |
+---+ +---+ +-----+ +-----+ +-----+ +---+ +---+ +-----+ +-----+ +-----+
<-Access-><--Aggregation Domain--><---------Core---------> <-Access-><--Aggregation Domain--><---------Core--------->
Figure 4: Use Case #2 Figure 4: Use Case #2
The above topology (see Figure 4) is subject to evolutions, depending The above topology (see Figure 4) is subject to evolutions, depending
on AN types and capacities (in terms of number of customers and/or on AN types and capacities (in terms of number of customers and/or
aggregated bandwidth). For examples, AGN1x connection toward AGN2y aggregated bandwidth). For examples, AGN1x connection toward AGN2y
currently forms a ring but may latter evolve in a square or triangle currently forms a ring but may latter evolve in a square or triangle
topology; AGN2y nodes may not be present... topology; AGN2y nodes may not be present...
Most access nodes (AN) are single attached on one aggregation node Most access nodes (AN) are single attached on one aggregation node
skipping to change at page 17, line 20 skipping to change at page 18, line 5
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 | /\ \/ |
+----+\ +-------+ \+-------+ +------+/\ +------+ +----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| | \ | | | | | | \| |
+--+ 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 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
skipping to change at page 23, line 17 skipping to change at page 24, line 6
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
destinations are rerouted via the backup nhop. 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]. please refer to [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 28, line 38 skipping to change at page 29, line 18
More specifically, [RFC6571] plays a key role in the Seamless MPLS More specifically, [RFC6571] plays a key role in the Seamless MPLS
architecture as it describes simple design guidelines which architecture as it describes simple design guidelines which
determiniscally ensure LFA coverage for any link and node in the determiniscally ensure LFA coverage for any link and node in the
aggregation regions of the network. This is key as it provides for a aggregation regions of the network. This is key as it provides for a
simple <50msec protection for the vast majority of the node and link simple <50msec protection for the vast majority of the 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], or (2) augmenting native LFA [I-D.ietf-rtgwg-remote-lfa], or (2) augmenting native LFA coverage
coverage with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP convergence.
convergence. The first option provides an automatic and fairly The first option provides an automatic and fairly simple sub-50msec
simple sub-50msec protection as LFA without introducing any protection as LFA without introducing any additional protocols. The
additional protocols. The second option provides the same sub-50msec second option provides the same sub-50msec protection as LFA, but
protection as LFA, but introduces additional RSVP LSPs. The thrid introduces additional RSVP LSPs. The thrid option optimizes for sub-
option optimizes for sub-50msec protection, but implies a more 50msec protection, but implies a more complex operational model. The
complex operational model. The fourth option optimizes for simple fourth option optimizes for simple operation but only provides <1 sec
operation but only provides <1 sec protection. Up to each designer protection. Up to each designer to arbitrate between these three
to arbitrate between these three options versus the possibility to options versus the possibility to engineer the topology for native
engineer the topology for native LFA protection. LFA protection.
A similar choice involves protection against ABR node failure and A similar choice involves protection against ABR node failure and
L3VPN PE node failure. The designer can either use BGP PIC or BGP L3VPN PE node failure. The designer can either use BGP PIC or BGP
egress node FRR. Up to each designer to asssess the trade-off egress node FRR. Up to each designer to asssess the trade-off
between the valuation of sub-50msec instead of sub-1sec versus between the valuation of sub-50msec instead of sub-1sec versus
additional operational considerations related to BGP egress node FRR. additional operational considerations related to BGP egress node FRR.
5.1.8.7. Conclusion 5.1.8.7. Conclusion
The Seamless MPLS architecture illustrated in deployment case study 1 The Seamless MPLS architecture illustrated in deployment case study 1
skipping to change at page 36, line 13 skipping to change at page 36, line 40
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] , , , and , "Archieving sub-second IGP convergence in
networks, ACM SIGCOMM Computer Communication Review, v.35 large IP networks, ACM SIGCOMM Computer Communication
n.3", July 2005. Review, v.35 n.3", July 2005.
[BGP-PIC] , "BGP PIC, Technical Report", November 2007. [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 36, line 51 skipping to change at page 37, line 32
[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.draft-ietf-rtgwg-remote-lfa]
, .
[I-D.ietf-karp-routing-tcp-analysis] [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-09 (work Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work
in progress), July 2013. in progress), July 2013.
[I-D.ietf-rtgwg-bgp-pic]
.
[I-D.ietf-rtgwg-remote-lfa]
.
[I-D.minto-2547-egress-node-fast-protection] [I-D.minto-2547-egress-node-fast-protection]
Jeganathan, J. and H. Gredler, "2547 egress PE Fast Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress
Failure Protection", draft-minto-2547-egress-node-fast- PE Fast Failure Protection", draft-minto-2547-egress-node-
protection-01 (work in progress), October 2012. fast-protection-02 (work in progress), July 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 37, line 43 skipping to change at page 38, line 29
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] .
[RFC6571] , . [RFC6571] .
[RFC7032] .
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
Email: n.leymann@telekom.de Email: n.leymann@telekom.de
Bruno Decraene Bruno Decraene
Orange 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
 End of changes. 42 change blocks. 
164 lines changed or deleted 173 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/