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