draft-ietf-rtgwg-cl-use-cases-05.txt   draft-ietf-rtgwg-cl-use-cases-06.txt 
RTGWG S. Ning RTGWG S. Ning
Internet-Draft Tata Communications Internet-Draft Tata Communications
Intended status: Informational A. Malis Intended status: Informational A. Malis
Expires: May 17, 2014 Consultant Expires: November 15, 2014 Consultant
D. McDysan D. McDysan
Verizon Verizon
L. Yong L. Yong
Huawei USA Huawei USA
C. Villamizar C. Villamizar
Outer Cape Cod Network Consulting Outer Cape Cod Network Consulting
November 13, 2013 May 14, 2014
Advanced Multipath Use Cases and Design Considerations Advanced Multipath Use Cases and Design Considerations
draft-ietf-rtgwg-cl-use-cases-05 draft-ietf-rtgwg-cl-use-cases-06
Abstract Abstract
Advanced Multipath is a formalization of multipath techniques Advanced Multipath is a formalization of multipath techniques
currently in use in IP and MPLS networks and a set of extensions to currently in use in IP and MPLS networks and a set of extensions to
existing multipath techniques. existing multipath techniques.
This document provides a set of use cases and design considerations This document provides a set of use cases and design considerations
for Advanced Multipath. Existing practices are described. Use cases for Advanced Multipath. Existing practices are described. Use cases
made possible through Advanced Multipath extensions are described. made possible through Advanced Multipath extensions are described.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 May 17, 2014. This Internet-Draft will expire on November 15, 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Multipath Foundation Use Cases . . . . . . . . . . . . . . . 5 4. Multipath Foundation Use Cases . . . . . . . . . . . . . . . 5
5. Advanced Multipath Use Cases . . . . . . . . . . . . . . . . 7 5. Advanced Multipath Use Cases . . . . . . . . . . . . . . . . 8
5.1. Delay Sensitive Applications . . . . . . . . . . . . . . 7 5.1. Delay Sensitive Applications . . . . . . . . . . . . . . 8
5.2. Large Volume of IP and LDP Traffic . . . . . . . . . . . 8 5.2. Large Volume of IP and LDP Traffic . . . . . . . . . . . 9
5.3. Multipath and Packet Ordering . . . . . . . . . . . . . . 9 5.3. Multipath and Packet Ordering . . . . . . . . . . . . . . 9
5.3.1. MPLS-TP in network edges only . . . . . . . . . . . . 10 5.3.1. MPLS-TP in network edges only . . . . . . . . . . . . 11
5.3.2. Multipath at core LSP ingress/egress . . . . . . . . 11 5.3.2. Multipath at core LSP ingress/egress . . . . . . . . 12
5.3.3. MPLS-TP as a MPLS client . . . . . . . . . . . . . . 12 5.3.3. MPLS-TP as a MPLS client . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Informative References . . . . . . . . . . . . . . . . . . . 13 9. Informative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. Network Operator Practices and Protocol Usage . . . 16 Appendix A. Network Operator Practices and Protocol Usage . . . 17
Appendix B. Existing Multipath Standards and Techniques . . . . 18 Appendix B. Existing Multipath Standards and Techniques . . . . 19
B.1. Common Multpath Load Spliting Techniques . . . . . . . . 19 B.1. Common Multpath Load Spliting Techniques . . . . . . . . 19
B.2. Static and Dynamic Load Balancing Multipath . . . . . . . 20 B.2. Static and Dynamic Load Balancing Multipath . . . . . . . 20
B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 20 B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 21
B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 21 B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 21
Appendix C. Characteristics of Transport in Core Networks . . . 21 Appendix C. Characteristics of Transport in Core Networks . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Advanced Multipath requirements are specified in Advanced Multipath requirements are specified in [RFC7226]. An
[I-D.ietf-rtgwg-cl-requirement]. An Advanced Multipath framework is Advanced Multipath framework is defined in
defined in [I-D.ietf-rtgwg-cl-framework]. [I-D.ietf-rtgwg-cl-framework].
Multipath techniques have been widely used in IP networks for over Multipath techniques have been widely used in IP networks for over
two decades. The use of MPLS began more than a decade ago. two decades. The use of MPLS began more than a decade ago.
Multipath has been widely used in IP/MPLS networks for over a decade Multipath has been widely used in IP/MPLS networks for over a decade
with very little protocol support dedicated to effective use of with very little protocol support dedicated to effective use of
multipath. multipath.
The state of the art in multipath prior to Advanced Multipath is The state of the art in multipath prior to Advanced Multipath is
documented in Appendix B. documented in Appendix B.
skipping to change at page 3, line 49 skipping to change at page 3, line 43
Edge Router (LER) or a Label Switch Router (LSR) as defined in Edge Router (LER) or a Label Switch Router (LSR) as defined in
[RFC3031]. [RFC3031].
The IP DSCP field [RFC2474] [RFC2475] cannot be used for flow The IP DSCP field [RFC2474] [RFC2475] cannot be used for flow
identification since L3VPN requires Diffserv transparency (see RFC identification since L3VPN requires Diffserv transparency (see RFC
4031 5.5.2 [RFC4031]), and in general network operators do not rely 4031 5.5.2 [RFC4031]), and in general network operators do not rely
on the DSCP of Internet packets. on the DSCP of Internet packets.
3. Terminology 3. Terminology
Terminology defined in [I-D.ietf-rtgwg-cl-requirement] and Terminology defined in [RFC7226] and [RFC7190] is used in this
[I-D.ietf-mpls-multipath-use] is used in this document. document.
In addition, the following terms are used: In addition, the following terms are used:
classic multipath: classic multipath:
Classic multipath refers to the most common current practice in Classic multipath refers to the most common current practice in
implementation and deployment of multipath (see Appendix B). The implementation and deployment of multipath (see Appendix B). The
most common current practice when applied to MPLS traffic makes most common current practice when applied to MPLS traffic makes
use of a hash on the MPLS label stack, and if IPv4 or IPv6 are use of a hash on the MPLS label stack, and if IPv4 or IPv6 are
indicated under the label stack, makes use of the IP source and indicated under the label stack, makes use of the IP source and
destination addresses [RFC4385] [RFC4928]. destination addresses [RFC4385] [RFC4928].
skipping to change at page 5, line 32 skipping to change at page 6, line 5
one TE-Link advertised into the IGP by the multipath end points (the one TE-Link advertised into the IGP by the multipath end points (the
LER if the multipath is MPLS based). This information is used in LER if the multipath is MPLS based). This information is used in
path computation when a full MPLS control plane is in use. path computation when a full MPLS control plane is in use.
If Advanced Multipath techniques are used, then the individual If Advanced Multipath techniques are used, then the individual
component links or groups of component links may optionally be component links or groups of component links may optionally be
advertised into the IGP as sub-TLV of the multipath FA advertisement advertised into the IGP as sub-TLV of the multipath FA advertisement
to indicate capacity available with various characteristics, such as to indicate capacity available with various characteristics, such as
a delay range. a delay range.
Management Plane Management Plane
Configuration and Measurement <------------+ Configuration and Measurement <------------+
^ | ^ |
| | | |
+-------+-+ +-+-------+ +-------+-+ +-+-------+
| | | | | | | | | | | |
CP Packets V | | V CP Packets CP Packets V | | V CP Packets
| V | | Component Link 1 | | ^ | | V | | Component Link 1 | | ^ |
| | |=|===========================|=| | | | | |=|===========================|=| | |
| +----| | Component Link 2 | |----+ | | +----| | Component Link 2 | |----+ |
| |=|===========================|=| | | |=|===========================|=| |
Aggregated LSPs | | | | | Aggregated LSPs | | | | |
~|~~~~~~>| | Component Link 3 | |~~~~>~~|~~ ~|~~~~~~>| | Component Link 3 | |~~~~>~~|~~
| |=|===========================|=| | | |=|===========================|=| |
| | | | | | | | | | | |
| LSR1 | | LSR2 | | LSR1 | | LSR2 |
+---------+ +---------+ +---------+ +---------+
! ! ! !
! ! ! !
!<-------- Multipath ---------->! !<-------- Multipath ---------->!
Figure 1: a multipath constructed with multiple physical links Figure 1: a multipath constructed with multiple physical links
between two LSR between two LSR
[I-D.ietf-rtgwg-cl-requirement] specifies that component links may [RFC7226] specifies that component links may themselves be multipath.
themselves be multipath. This is true for most implementations even This is true for most implementations even prior to the Advanced
prior to the Advanced Multipath work in Multipath work in [RFC7226]. For example, a component of a pre-
[I-D.ietf-rtgwg-cl-requirement]. For example, a component of a pre-
Advanced Multipath MPLS Link Bundle or ISIS or OSPF ECMP could be an Advanced Multipath MPLS Link Bundle or ISIS or OSPF ECMP could be an
Ethernet LAG. In some implementations many other combinations or Ethernet LAG. In some implementations many other combinations or
even arbitrary combinations could be supported. Figure 2 shows three even arbitrary combinations could be supported. Figure 2 shows three
three forms of component links which may be deployed in a network. three forms of component links which may be deployed in a network.
+-------+ 1. Physical Link +-------+ +-------+ 1. Physical Link +-------+
| |-|----------------------------------------------|-| | | |-|----------------------------------------------|-| |
| | | | | | | | | | | |
| | | +------+ +------+ | | | | | | +------+ +------+ | | |
| | | | MPLS | 2. Logical Link | MPLS | | | | | | | | MPLS | 2. Logical Link | MPLS | | | |
| |.|.... |......|.....................|......|....|.| | | |.|.... |......|.....................|......|....|.| |
| | |-----| LSR3 |---------------------| LSR4 |----| | | | | |-----| LSR3 |---------------------| LSR4 |----| | |
| | | +------+ +------+ | | | | | | +------+ +------+ | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | +------+ +------+ | | | | | | +------+ +------+ | | |
| | | |GMPLS | 3. Logical Link |GMPLS | | | | | | | |GMPLS | 3. Logical Link |GMPLS | | | |
| |.|. ...|......|.....................|......|....|.| | | |.|. ...|......|.....................|......|....|.| |
| | |-----| LSR5 |---------------------| LSR6 |----| | | | | |-----| LSR5 |---------------------| LSR6 |----| | |
| | +------+ +------+ | | | | +------+ +------+ | |
| LSR1 | | LSR2 | | LSR1 | | LSR2 |
+-------+ +-------+ +-------+ +-------+
|<---------------- Multipath --------------------->| |<---------------- Multipath --------------------->|
Figure 2: Illustration of Various Component Link Types Figure 2: Illustration of Various Component Link Types
The three forms of component link shown in Figure 2 are: The three forms of component link shown in Figure 2 are:
1. The first component link is configured with direct physical media 1. The first component link is configured with direct physical media
plus a link layer protocol. This case also includes emulated plus a link layer protocol. This case also includes emulated
physical links, for example using pseudowire emulation. physical links, for example using pseudowire emulation.
2. The second component link is a TE tunnel that traverses LSR3 and 2. The second component link is a TE tunnel that traverses LSR3 and
skipping to change at page 12, line 47 skipping to change at page 13, line 37
cost core LSR are available which support only classic link bundling cost core LSR are available which support only classic link bundling
and regardless of loss of multiplexing gain, are more cost effective and regardless of loss of multiplexing gain, are more cost effective
at carrying transit traffic than using equipment which supports IP at carrying transit traffic than using equipment which supports IP
source and destination address hashing. source and destination address hashing.
5.3.3. MPLS-TP as a MPLS client 5.3.3. MPLS-TP as a MPLS client
Accommodating MPLS-TP as a MPLS client requires the small change to Accommodating MPLS-TP as a MPLS client requires the small change to
forwarding behavior necessary to support [RFC6790] and is therefore forwarding behavior necessary to support [RFC6790] and is therefore
most applicable to major network overbuilds or new deployments. This most applicable to major network overbuilds or new deployments. This
approach is described in [I-D.ietf-mpls-multipath-use] and makes use approach is described in [RFC7190] and makes use of Entropy Labels
of Entropy Labels [RFC6790] to prevent reordering of MPLS-TP LSP or [RFC6790] to prevent reordering of MPLS-TP LSP or any other LSP which
any other LSP which requires that its traffic not be reordered for requires that its traffic not be reordered for OAM or other reasons.
OAM or other reasons.
The advantage of this approach is an ability to accommodate MPLS-TP The advantage of this approach is an ability to accommodate MPLS-TP
as a client LSP but retain the high multiplexing gain and therefore as a client LSP but retain the high multiplexing gain and therefore
efficiency and low network cost of a pure MPLS deployment. The efficiency and low network cost of a pure MPLS deployment. The
disadvantage is the need for a small change in forwarding to support disadvantage is the need for a small change in forwarding to support
[RFC6790]. [RFC6790].
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This document is a use cases document. Existing protocols are This document is a use cases document. Existing protocols are
referenced such as MPLS. Existing techniques such as MPLS link referenced such as MPLS. Existing techniques such as MPLS link
bundling and multipath techniques are referenced. These protocols bundling and multipath techniques are referenced. These protocols
and techniques are documented elsewhere and contain security and techniques are documented elsewhere and contain security
considerations which are unchanged by this document. considerations which are unchanged by this document.
This document also describes use cases for multipath and Advanced This document also describes use cases for multipath and Advanced
Multipath. Advanced Multipath requirements are defined in Multipath. Advanced Multipath requirements are defined in [RFC7226].
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-framework] [I-D.ietf-rtgwg-cl-framework] defines a framework for Advanced
defines a framework for Advanced Multipath. Advanced Multipath bears Multipath. Advanced Multipath bears many similarities to MPLS link
many similarities to MPLS link bundling and multipath techniques used bundling and multipath techniques used with MPLS. Additional
with MPLS. Additional security considerations, if any, beyond those security considerations, if any, beyond those already identified for
already identified for MPLS, MPLS link bundling and multipath MPLS, MPLS link bundling and multipath techniques, will be documented
techniques, will be documented in the framework document if specific in the framework document if specific to the overall framework of
to the overall framework of Advanced Multipath, or in protocol Advanced Multipath, or in protocol extensions if specific to a given
extensions if specific to a given protocol extension defined later to protocol extension defined later to support Advanced Multipath.
support Advanced Multipath.
8. Acknowledgments 8. Acknowledgments
In the interest of full disclosure of affiliation and in the interest In the interest of full disclosure of affiliation and in the interest
of acknowledging sponsorship, past affiliations of authors are noted. of acknowledging sponsorship, past affiliations of authors are noted.
Much of the work done by Ning So occurred while Ning was at Verizon. Much of the work done by Ning So occurred while Ning was at Verizon.
Much of the work done by Curtis Villamizar occurred while at Much of the work done by Curtis Villamizar occurred while at
Infinera. Much of the work done by Andy Malis occurred while Andy Infinera. Much of the work done by Andy Malis occurred while Andy
was at Verizon. was at Verizon.
9. Informative References 9. Informative References
[I-D.ietf-mpls-multipath-use]
Villamizar, C., "Use of Multipath with MPLS-TP and MPLS",
draft-ietf-mpls-multipath-use-00 (work in progress),
February 2013.
[I-D.ietf-rtgwg-cl-framework] [I-D.ietf-rtgwg-cl-framework]
Ning, S., McDysan, D., Osborne, E., Yong, L., and C. Ning, S., McDysan, D., Osborne, E., Yong, L., and C.
Villamizar, "Composite Link Framework in Multi Protocol Villamizar, "Advanced Multipath Framework in MPLS", draft-
Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-03 ietf-rtgwg-cl-framework-04 (work in progress), July 2013.
(work in progress), June 2013.
[I-D.ietf-rtgwg-cl-requirement]
Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
Yong, "Requirements for Advanced Multipath in MPLS
Networks", draft-ietf-rtgwg-cl-requirement-11 (work in
progress), July 2013.
[IEEE-802.1AX] [IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/ Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>. download/802.1AX-2008.pdf>.
[ITU-T.G.694.2] [ITU-T.G.694.2]
ITU-T, "Spectral grids for WDM applications: CWDM ITU-T, "Spectral grids for WDM applications: CWDM
wavelength grid ", 2003, wavelength grid", 2003,
<http://www.itu.int/rec/T-REC-G.694.2-200312-I>. <http://www.itu.int/rec/T-REC-G.694.2-200312-I>.
[RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The [RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The
PPP Multilink Protocol (MP)", RFC 1717, November 1994. PPP Multilink Protocol (MP)", RFC 1717, November 1994.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998. 1998.
skipping to change at page 16, line 27 skipping to change at page 17, line 5
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, November over an MPLS Packet Switched Network", RFC 6391, November
2011. 2011.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
[RFC7190] Villamizar, C., "Use of Multipath with MPLS and MPLS
Transport Profile (MPLS-TP)", RFC 7190, March 2014.
[RFC7226] Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
Yong, "Requirements for Advanced Multipath in MPLS
Networks", RFC 7226, May 2014.
Appendix A. Network Operator Practices and Protocol Usage Appendix A. Network Operator Practices and Protocol Usage
Often, network operators have a contractual Service Level Agreement Often, network operators have a contractual Service Level Agreement
(SLA) with customers for services that are comprised of numerical (SLA) with customers for services that are comprised of numerical
values for performance measures, principally availability, latency, values for performance measures, principally availability, latency,
delay variation. Additionally, network operators may have delay variation. Additionally, network operators may have
performance objectives for internal use by the operator. See performance objectives for internal use by the operator. See
RFC3809, Section 4.9 [RFC3809] for examples of the form of such SLA RFC3809, Section 4.9 [RFC3809] for examples of the form of such SLA
and performance objective specifications. In this document we use and performance objective specifications. In this document we use
the term Performance Objective as defined in the term Performance Objective as defined in [RFC7226]. Applications
[I-D.ietf-rtgwg-cl-requirement]. Applications and acceptable user and acceptable user experience have an important relationship to
experience have an important relationship to these performance these performance parameters.
parameters.
Consider latency as an example. In some cases, minimizing latency Consider latency as an example. In some cases, minimizing latency
relates directly to the best customer experience (for example, in relates directly to the best customer experience (for example, in
interactive applications closer is faster). In other cases, user interactive applications closer is faster). In other cases, user
experience is relatively insensitive to latency, up to a specific experience is relatively insensitive to latency, up to a specific
limit at which point user perception of quality degrades limit at which point user perception of quality degrades
significantly (e.g., interactive human voice and multimedia significantly (e.g., interactive human voice and multimedia
conferencing). A number of Performance Objectives have a bound on conferencing). A number of Performance Objectives have a bound on
point-to-point latency and as long as this bound is met the point-to-point latency and as long as this bound is met the
Performance Objective is met; decreasing the latency is not Performance Objective is met; decreasing the latency is not
skipping to change at page 19, line 37 skipping to change at page 20, line 20
be considered to be acceptable unless reordering occurs within be considered to be acceptable unless reordering occurs within
traffic containing a common unique set of label stack entries. traffic containing a common unique set of label stack entries.
Existing load splitting techniques take advantage of this property in Existing load splitting techniques take advantage of this property in
addition to looking beyond the bottom of the label stack and addition to looking beyond the bottom of the label stack and
determining if the payload is IPv4 or IPv6 to load balance traffic determining if the payload is IPv4 or IPv6 to load balance traffic
accordingly. accordingly.
MPLS-TP OAM violates the assumption that it is safe to reorder MPLS-TP OAM violates the assumption that it is safe to reorder
traffic within an LSP. If MPLS-TP OAM is to be accommodated, then traffic within an LSP. If MPLS-TP OAM is to be accommodated, then
existing multipath techniques must be modified. [RFC6790] and existing multipath techniques must be modified. [RFC6790] and
[I-D.ietf-mpls-multipath-use] provide a solution but require a small [RFC7190] provide a solution but require a small forwarding change.
forwarding change.
For example, a large aggregate of IP traffic may be subdivided into a For example, a large aggregate of IP traffic may be subdivided into a
large number of groups of flows using a hash on the IP source and large number of groups of flows using a hash on the IP source and
destination addresses. This is as described in [RFC2475] and destination addresses. This is as described in [RFC2475] and
clarified in [RFC3260]. For MPLS traffic carrying IP, a similar hash clarified in [RFC3260]. For MPLS traffic carrying IP, a similar hash
can be performed on the set of labels in the label stack. These can be performed on the set of labels in the label stack. These
techniques are both examples of means to subdivide traffic into techniques are both examples of means to subdivide traffic into
groups of flows for the purpose of load balancing traffic across groups of flows for the purpose of load balancing traffic across
aggregated link capacity. The means of identifying a group of flows aggregated link capacity. The means of identifying a group of flows
should not be confused with the definition of a flow. should not be confused with the definition of a flow.
 End of changes. 23 change blocks. 
101 lines changed or deleted 91 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/