draft-ietf-mpls-te-scaling-analysis-04.txt   draft-ietf-mpls-te-scaling-analysis-05.txt 
Network Working Group S. Yasukawa Network Working Group S. Yasukawa
Internet-Draft NTT Internet-Draft NTT
Intended Status: Informational A. Farrel Intended Status: Informational A. Farrel
Created: December 2, 2008 Old Dog Consulting Created: December 14, 2008 Old Dog Consulting
Expires: June 2, 2009 O. Komolafe Expires: June 14, 2009 O. Komolafe
Cisco Systems Cisco Systems
An Analysis of Scaling Issues in MPLS-TE Core Networks An Analysis of Scaling Issues in MPLS-TE Core Networks
draft-ietf-mpls-te-scaling-analysis-04.txt draft-ietf-mpls-te-scaling-analysis-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 52 skipping to change at page 2, line 52
8.5 Issues with MP2P LSPs ........................................ 33 8.5 Issues with MP2P LSPs ........................................ 33
9. Combined Models ............................................... 34 9. Combined Models ............................................... 34
10. An Alternate Solution ........................................ 35 10. An Alternate Solution ........................................ 35
10.1 Pros and Cons of the Alternate Solution ..................... 36 10.1 Pros and Cons of the Alternate Solution ..................... 36
11. Management Considerations .................................... 37 11. Management Considerations .................................... 37
12. Security Considerations ...................................... 37 12. Security Considerations ...................................... 37
13. Recommendations .............................................. 38 13. Recommendations .............................................. 38
14. IANA Considerations .......................................... 38 14. IANA Considerations .......................................... 38
15. Acknowledgements ............................................. 38 15. Acknowledgements ............................................. 38
16. Intellectual Property Consideration .......................... 39 16. Intellectual Property Consideration .......................... 39
17. Normative References ......................................... 39 17. Normative References ......................................... 40
18. Informative References ....................................... 40 18. Informative References ....................................... 40
19. Authors' Addresses ........................................... 41 19. Authors' Addresses ........................................... 41
1. Introduction 1. Introduction
Network operators and service providers are examining scaling issues Network operators and service providers are examining scaling issues
as they look to deploy ever-larger traffic engineered Multiprotocol as they look to deploy ever-larger traffic engineered Multiprotocol
Label Switching (MPLS-TE) networks. Concerns have been raised about Label Switching (MPLS-TE) networks. Concerns have been raised about
the number of Label Switched Paths (LSPs) that need to be supported the number of Label Switched Paths (LSPs) that need to be supported
at the edge and at the core of the network. The impact on control at the edge and at the core of the network. The impact on control
skipping to change at page 4, line 26 skipping to change at page 4, line 26
of 'duplicate' LSPs. This issue is not addressed in this document. of 'duplicate' LSPs. This issue is not addressed in this document.
It should also be understood that certain deployment models where It should also be understood that certain deployment models where
separate traffic engineered LSPs are used to provide different separate traffic engineered LSPs are used to provide different
services such as layer 3 VPNs [RFC4110] or pseudowires [RFC3985], or services such as layer 3 VPNs [RFC4110] or pseudowires [RFC3985], or
different classes of service [RFC3270], may result in 'duplicate' or different classes of service [RFC3270], may result in 'duplicate' or
'parallel' LSPs running between any pair of provider edge nodes 'parallel' LSPs running between any pair of provider edge nodes
(PEs). This scaling factor is also not considered in this document, (PEs). This scaling factor is also not considered in this document,
but may be easily applied as a linear factor by the reader. but may be easily applied as a linear factor by the reader.
The operation of security mechanisms in MPLS-TE networks [MPLS-SEC]
may have an impact on the ability of the network to scale. For
example, they may increase both the size and number of control plane
messages. Additionally, they may increase the processing overhead as
control plane messages are subject to processing algorithms (such as
encryption), and security keys need to be managed. Deployers will
need to consider the trade-offs between scaling objectives and
security objectives in thier networks and should resist the
temptation to respond to a degradation of scaling performance by
turning off security techniques that have previously been deemed as
necessary. Further analysis of the effects of security measures on
scalability are not considered further in this document.
This document is designed to help service providers discover whether This document is designed to help service providers discover whether
existing protocols and implementations can support the network sizes existing protocols and implementations can support the network sizes
that they are planning. To do this, it presents an analysis of some that they are planning. To do this, it presents an analysis of some
of the scaling concerns for MPLS-TE core networks, and examines the of the scaling concerns for MPLS-TE core networks, and examines the
value of two techniques for improving scaling. This should motivate value of two techniques for improving scaling. This should motivate
the development of appropriate deployment techniques and protocol the development of appropriate deployment techniques and protocol
extensions to enable the application of MPLS-TE in large networks. extensions to enable the application of MPLS-TE in large networks.
This document only considers the question of achieving scalability This document only considers the question of achieving scalability
for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint
skipping to change at page 38, line 13 skipping to change at page 38, line 13
yet-to-be-defined signaling protocol extensions and are subject to yet-to-be-defined signaling protocol extensions and are subject to
the security provided by those extensions. Note that we are talking the security provided by those extensions. Note that we are talking
about tunneling techniques used within the network and both about tunneling techniques used within the network and both
approaches are vulnerable to the creation of bogus tunnels that approaches are vulnerable to the creation of bogus tunnels that
deliver data to an egress or consume network resources. deliver data to an egress or consume network resources.
The fact that the MP2P technique may prove harder to debug through The fact that the MP2P technique may prove harder to debug through
OAM methods than the FA LSP approach is a security concern since it OAM methods than the FA LSP approach is a security concern since it
is important to be able to detect misconnections. is important to be able to detect misconnections.
General issues of the realtionship between scaling and security are
covered in Section 1.1, but the details are beyond the scope of this
document. Readers are refered to [MPLS-SEC] for details of MPLS
security techniques.
13. Recommendations 13. Recommendations
The analysis in this document suggests that the ability to signal The analysis in this document suggests that the ability to signal
MP2P MPLS-TE LSPs is a desirable addition to the operator's MPLS-TE MP2P MPLS-TE LSPs is a desirable addition to the operator's MPLS-TE
toolkit. toolkit.
At this stage, no further recommendations are made, but it would be At this stage, no further recommendations are made, but it would be
valuable to consult more widely to discover: valuable to consult more widely to discover:
- The concerns of other service providers with respect to network - The concerns of other service providers with respect to network
skipping to change at page 38, line 49 skipping to change at page 39, line 4
adopted. adopted.
14. IANA Considerations 14. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
15. Acknowledgements 15. Acknowledgements
The authors are grateful to Jean-Louis Le Roux for discussions and The authors are grateful to Jean-Louis Le Roux for discussions and
review input. Thanks to Ben Niven-Jenkins, JP Vasseur, Loa Andersson, review input. Thanks to Ben Niven-Jenkins, JP Vasseur, Loa Andersson,
and Anders Gavler for their comments. Thanks to Dave Allen for useful Anders Gavler, and Tom Polk for their comments. Thanks to Dave Allen
discussion of the maths. for useful discussion of the math.
16. Intellectual Property Consideration 16. Intellectual Property Consideration
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. such rights.
skipping to change at page 41, line 5 skipping to change at page 41, line 5
RFC 4972, July 2007. RFC 4972, July 2007.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 5036, October 2007. B. Thomas, "LDP Specification", RFC 5036, October 2007.
[MP2P-RSVP] Yasukawa, Y., "Supporting Multipoint-to-Point Label [MP2P-RSVP] Yasukawa, Y., "Supporting Multipoint-to-Point Label
Switched Paths in Multiprotocol Label Switching Traffic Switched Paths in Multiprotocol Label Switching Traffic
Engineering", draft-yasukawa-mpls-mp2p-rsvpte, work in Engineering", draft-yasukawa-mpls-mp2p-rsvpte, work in
progress. progress.
[MPLS-SEC] Fang, L. (Ed.), "Security Framework for MPLS and GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-security-
framework, work in progress.
19. Authors' Addresses 19. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4769 Phone: +81 422 59 4769
EMail: s.yasukawa@hco.ntt.co.jp EMail: s.yasukawa@hco.ntt.co.jp
Adrian Farrel Adrian Farrel
 End of changes. 7 change blocks. 
6 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/