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/ |