draft-ietf-mpls-seamless-mpls-02.txt   draft-ietf-mpls-seamless-mpls-03.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: April 25, 2013 France Telecom Expires: November 14, 2013 France Telecom
C. Filsfils C. Filsfils
M. Konstantynowicz M. Konstantynowicz, Ed.
Cisco Systems Cisco Systems
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
October 22, 2012 May 13, 2013
Seamless MPLS Architecture Seamless MPLS Architecture
draft-ietf-mpls-seamless-mpls-02 draft-ietf-mpls-seamless-mpls-03
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
independent transport. Therefore it removes the need for service independent transport. Therefore it removes the need for service
specific configurations in network transport nodes (without end to specific configurations in network transport nodes (without end to
end transport MPLS, some additional services nodes/configurations end transport MPLS, some additional services nodes/configurations
would be required to glue each transport domain). This draft defines would be required to glue each transport domain). This draft defines
a routing architecture using existing standardized protocols. It a routing architecture using existing standardized protocols. It
does not invent any new protocols or defines extensions to existing does not invent any new protocols or defines extensions to existing
protocols. protocols.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 25, 2013. This Internet-Draft will expire on November 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 12 2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 15 4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15
4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 16 4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15
4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 16 4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16
4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17
5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 19 5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 18
5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18
5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19 5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19
5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 20 5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20
5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 21 5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21
5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22 5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22
5.1.8. Network Availability . . . . . . . . . . . . . . . . . 23 5.1.8. Network Availability . . . . . . . . . . . . . . . . 22
5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23 5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23
5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 24 5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23
5.1.8.3. Hierarchical Dataplane and BGP Prefix 5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent
Independent Convergence . . . . . . . . . . . . . 24 Convergence . . . . . . . . . . . . . . . . . . . 24
5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 25 5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24
5.1.8.5. Assessing loss of connectivity upon any failure . 25 5.1.8.5. Assessing loss of connectivity upon any failure . 25
5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29 5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29
5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 30 5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30
5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30 5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30
5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 31 5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31
5.2.1. Control and Data Plane State for Deployment 5.2.1. Control and Data Plane State for Deployment Scenario
Scenario #1 . . . . . . . . . . . . . . . . . . . . . 31 #1 . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 31 5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31
5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 32 5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31
5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 33 5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33
5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34 5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34
5.2.1.5. Numerical application for use case #1 . . . . . . 35 5.2.1.5. Numerical application for use case #1 . . . . . . 34
5.2.1.6. Numerical application for use case #2 . . . . . . 35 5.2.1.6. Numerical application for use case #2 . . . . . . 35
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8.1. Access Network Security . . . . . . . . . . . . . . . . . 37 8.1. Access Network Security . . . . . . . . . . . . . . . . . 37
8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37 8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37
8.3. Control Plane Security . . . . . . . . . . . . . . . . . . 38 8.3. Control Plane Security . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 9.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . . 39 9.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 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 39 skipping to change at page 5, line 32
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 mobile addition MPLS is already used in access networks, e.g. such as
or DSL backhaul. Today MPLS as technology is being used on two mobile or DSL backhaul. Today MPLS as technology is being used on
different layers: two 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 40 skipping to change at page 6, line 32
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
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
services specific configurations between the different MPLS islands. services specific configurations between the different MPLS islands.
Seamless MPLS connects all MPLS domains on the MPLS transport layer Seamless MPLS connects all MPLS domains on the MPLS transport layer
providing a single transport layer for all services - independent of providing a single transport layer for all services - independent of
the service itself. The Seamless MPLS architecture therefore the service itself. The Seamless MPLS architecture therefore
decuples the service and transport layer and integrates access, decuples the service and transport layer and integrates access,
aggregation and core into a single platform. One of the big aggregation and core into a single platform. One of the big
skipping to change at page 8, line 5 skipping to change at page 7, line 39
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)
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) originated at the AN and terminates at the AGN2. A second (PW1) originated at the AN and terminates at the AGN2. A second
PW is deployed in the case where redundancy is needed on the AN PW is deployed in the case where redundancy is needed on the AN
(the figure shows redundancy but this might not be the case for (the figure shows redundancy but this might not be the case for
all ANs in this Use Case). Additonal PWs can be deployed as well all ANs in this Use Case). Additonal PWs can be deployed as well
in case more than a single service creation is needed for the in case more than a single service creation is needed for the
residential service (e.g. one service creation point for Internet residential service (e.g. one service creation point for Internet
access and a second service creation point for IPTV services). access and a second service creation point for IPTV services).
Business Sercvices: For business services the use cases shows point Business Sercvices: For business services the use cases shows point
to point connections between two access nodes. PW2 originates at to point connections between two access nodes. PW2 originates at
the AN and terminates on the remote AN crossing two aggregation the AN and terminates on the remote AN crossing two aggregation
areas and the core network. If the access node needs connections areas and the core network. If the access node needs connections
to several remote ANs the corresponding number of PWs will be to several remote ANs the corresponding number of PWs will be
originated at the AN. Nevertheless taking the number of ports originated at the AN. Nevertheless taking the number of ports
available and the number of business customers on a typical access available and the number of business customers on a typical access
node the number of PWs will be relatively small. node the number of PWs will be relatively small.
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
| | | | | | | | | | | | | | | |
+--+ 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 12, line 24 skipping to change at page 11, line 47
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 13, line 14 skipping to change at page 12, line 34
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 17, line 15 skipping to change at page 16, line 38
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 45 skipping to change at page 17, line 26
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 | /\ \/ |
+----+\ +-------+ \+-------+ +------+/\ +------+ +----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| | \ | | | | | | \| |
+--+ 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 21, line 29 skipping to change at page 21, line 13
necessary on the AN. necessary on the AN.
o The following are the triggers for ANs to request a label: o The following are the triggers for ANs to request a label:
o o
* When a control session (targeted LDP) to a target has to be * When a control session (targeted LDP) to a target has to be
established established
* When a service label has been received by a control session * When a service label has been received by a control session
(e.g. pseudo wire label) (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 23, line 38 skipping to change at page 23, line 22
delay and a linear FIB update [ACM01]. delay and a linear FIB update [ACM01].
The initial delay could conservatively be assumed to be 260msec: The initial delay could conservatively be assumed to be 260msec:
50msec to detect failures with BFD (most failures would be detected 50msec to detect failures with BFD (most failures would be detected
faster with loss of light for example or with faster BFD timers), faster with loss of light for example or with faster BFD timers),
50msec to throttle the LSP generation, 150msec to throttle the SPF 50msec to throttle the LSP generation, 150msec to throttle the SPF
computation (making sure than all the required LSP's are received computation (making sure than all the required LSP's are received
even in case of SRLG failures) and 10msec for shortest-path-first even in case of SRLG failures) and 10msec for shortest-path-first
tree computation. tree computation.
Assuming 250usec per update (conservative), this allows for (1000- Assuming 250usec per update (conservative), this allows for
260)/0.250= 2960 prefixes update within a second following the (1000-260)/0.250= 2960 prefixes update within a second following the
outage. More precisely, this allows for 2960 important IGP prefixes outage. More precisely, this allows for 2960 important IGP prefixes
updates. Important prefixes are automatically classified by the updates. Important prefixes are automatically classified by the
router implementation through simple heuristic (/32 is more important router implementation through simple heuristic (/32 is more important
than non-/32). than non-/32).
The number of IGP important routes (loopbacks) in deployment case The number of IGP important routes (loopbacks) in deployment case
study 1 is much smaller than 2960, and hence sub-second IGP study 1 is much smaller than 2960, and hence sub-second IGP
convergence is conservative. convergence is conservative.
IGP convergence is a simple technology for the operator provided that IGP convergence is a simple technology for the operator provided that
skipping to change at page 32, line 5 skipping to change at page 31, 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 33, line 33 skipping to change at page 33, line 17
In the aggregation domain, IGP & LDP are not affected by the number In the aggregation domain, IGP & LDP are not affected by the number
of access nodes outside of their domain. They are not affected by of access nodes outside of their domain. They are not affected by
the total number of AN nodes: the total number of AN nodes:
IGP: IGP:
node : #AGN / #Area ~ o(1) node : #AGN / #Area ~ o(1)
links : 3*#AGN / #Area ~ o(1) links : 3*#AGN / #Area ~ o(1)
IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5
*5/ #Area) / #Area)
+ + 1 loopback per core node + one aggregate per area + 5 + + 1 loopback per core node + one aggregate per area + 5
prefixes per AGN in the area + 1 prefix per AN in the area. prefixes per AGN in the area + 1 prefix per AN in the area.
LDP FEC: LDP FEC:
Core + (#AGN + #AN) / #Area ~ o(#AN / #Area) Core + (#AGN + #AN) / #Area ~ o(#AN / #Area)
+ + 1 loopback per core node + 1 loopback per AGN & AN node in + + 1 loopback per core node + 1 loopback per AGN & AN node in
the area. the area.
skipping to change at page 34, line 45 skipping to change at page 34, 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 37, line 14 skipping to change at page 36, line 41
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 the LDP specification RFC5036
[RFC5036] including ensuring authenticity and integrity of LDP [RFC5036] including ensuring authenticity and integrity of LDP
messages, as well as protection against spoofing and Denial of messages, as well as protection against spoofing and Denial of
Service attacks. Some deployments may require increased measures of Service attacks. Some deployments may require increased measures of
network security if a subset of Access Nodes are placed in locations network security if a subset of Access Nodes are placed in locations
with lower levels of physical security e.g. street cabinets ( common with lower levels of physical security e.g. street cabinets ( common
practice for VDSL access ). In such cases it is the responsibility practice for VDSL access ). In such cases it is the responsibility
of the system designer to take into account the physical security of the system designer to take into account the physical security
measures ( environmental design, mechanical or electronic access measures ( environmental design, mechanical or electronic access
control, intrusion detection ), as well as monitoring and auditing control, intrusion detection ), as well as monitoring and auditing
measures (configuration and Operating System changes, reloads, routes measures (configuration and Operating System changes, reloads, routes
advertisements ). But even with all this in mind, the designer still advertisements ). But even with all this in mind, the designer still
should consider network security risks and adequate measures arising should consider network security risks and adequate measures arising
from the lower level of physical security of those locations. from the lower level of physical security of those locations.
8.1. Access Network Security 8.1. Access Network Security
skipping to change at page 39, line 4 skipping to change at page 38, line 32
access locations with lower physical security, designer could also access locations with lower physical security, designer could also
consider using: consider using:
o different crypto keys for use in authentication procedures for o different crypto keys for use in authentication procedures for
these locations. these locations.
o stricter network protection mechanisms including DoS protection, o stricter network protection mechanisms including DoS protection,
interface and session flap dampening. interface and session flap dampening.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[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.draft-bashandy-bgp-edge-node-frr-03]
"". , .
[I-D.draft-bashandy-bgp-frr-mirror-table-00] [I-D.draft-bashandy-bgp-frr-mirror-table-00]
"". , .
[I-D.draft-ietf-rtgwg-remote-lfa-00] [I-D.draft-ietf-rtgwg-remote-lfa-00]
"". , .
[I-D.draft-minto-2547-egress-node-fast-protection-00] [I-D.draft-minto-2547-egress-node-fast-protection-00]
"". , .
[I-D.filsfils-rtgwg-lfa-applicability] [I-D.filsfils-rtgwg-lfa-applicability]
Filsfils, C., Francois, P., Shand, M., Decraene, B., Filsfils, C., Francois, P., Shand, M., Decraene, B.,
Uttaro, J., Leymann, N., and M. Horneffer, "LFA Uttaro, J., Leymann, N., and M. Horneffer, "LFA
applicability in SP networks", applicability in SP networks", draft-filsfils-rtgwg-lfa-
draft-filsfils-rtgwg-lfa-applicability-00 (work in applicability-00 (work in progress), March 2010.
progress), March 2010.
[I-D.ietf-bfd-v4v6-1hop] [I-D.ietf-bfd-v4v6-1hop]
Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress), Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress),
January 2010. January 2010.
[I-D.ietf-mpls-ldp-dod] [I-D.ietf-mpls-ldp-dod]
Beckhaus, T., Decraene, B., Tiruveedhula, K., Beckhaus, T., Decraene, B., Tiruveedhula, K.,
Konstantynowicz, M., and L. Martini, "LDP Downstream-on- Konstantynowicz, M., and L. Martini, "LDP Downstream-on-
Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-03 (work Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-06 (work
in progress), August 2012. in progress), May 2013.
[I-D.kothari-henderickx-l2vpn-vpls-multihoming] [I-D.kothari-henderickx-l2vpn-vpls-multihoming]
Kothari, B., Kompella, K., Henderickx, W., and F. Balus, Kothari, B., Kompella, K., Henderickx, W., and F. Balus,
"BGP based Multi-homing in Virtual Private LAN Service", "BGP based Multi-homing in Virtual Private LAN Service",
draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work
in progress), July 2009. in progress), July 2009.
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs", draft-narten-iana-
draft-narten-iana-considerations-rfc2434bis-09 (work in considerations-rfc2434bis-09 (work in progress), March
progress), March 2008. 2008.
[I-D.raggarwa-mac-vpn] [I-D.raggarwa-mac-vpn]
Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and
F. Balus, "BGP MPLS Based MAC VPN", F. Balus, "BGP MPLS Based MAC VPN", draft-raggarwa-mac-
draft-raggarwa-mac-vpn-01 (work in progress), June 2010. vpn-01 (work in progress), June 2010.
[I-D.sajassi-l2vpn-rvpls-bgp] [I-D.sajassi-l2vpn-rvpls-bgp]
Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and
S. Boutros, "Routed VPLS using BGP", S. Boutros, "Routed VPLS using BGP", draft-sajassi-l2vpn-
draft-sajassi-l2vpn-rvpls-bgp-01 (work in progress), rvpls-bgp-01 (work in progress), July 2010.
July 2010.
[PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in [PE-FRR] Le Roux, J.L., Decraene, B., and Z. Ahmad, "Fast Reroute
MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS in MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS
2006 Conference". 2006 Conference", .
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, [RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,
F., and F. Ansari, "Overview of IP Multicast in a Multi- F., and F. Ansari, "Overview of IP Multicast in a Multi-
Protocol Label Switching (MPLS) Environment", RFC 3353, Protocol Label Switching (MPLS) Environment", RFC 3353,
August 2002. August 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552, July
July 2003. 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
May 2005. 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.
skipping to change at page 41, line 40 skipping to change at page 41, line 19
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 France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Moulineaux cedex 9, 92794 Issy Moulineaux cedex 9 92794
FR FR
Phone: Email: bruno.decraene@orange.com
Fax:
Email: bruno.decraene@orange-ftgroup.com
URI:
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Brussels, Brussels
Belgium Belgium
Phone:
Fax:
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
URI:
Maciek Konstantynowicz Maciek Konstantynowicz (editor)
Cisco Systems Cisco Systems
London, London
United Kingdom United Kingdom
Phone:
Fax:
Email: maciek@cisco.com Email: maciek@cisco.com
URI:
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Steinberg Consulting
Ringstrasse 2 Ringstrasse 2
Buchholz 53567 Buchholz 53567
DE DE
Email: dws@steinbergnet.net Email: dws@steinbergnet.net
 End of changes. 59 change blocks. 
192 lines changed or deleted 182 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/