draft-ietf-mpls-multipath-use-02.txt   draft-ietf-mpls-multipath-use-03.txt 
MPLS C. Villamizar, Ed. MPLS C. Villamizar, Ed.
Internet-Draft Outer Cape Cod Network Internet-Draft Outer Cape Cod Network Consulting
Intended status: Informational Consulting Intended status: Informational November 13, 2013
Expires: April 12, 2014 October 9, 2013 Expires: May 17, 2014
Use of Multipath with MPLS and MPLS-TP Use of Multipath with MPLS and MPLS-TP
draft-ietf-mpls-multipath-use-02 draft-ietf-mpls-multipath-use-03
Abstract Abstract
Many MPLS implementations have supported multipath techniques and Many MPLS implementations have supported multipath techniques and
many MPLS deployments have used multipath techniques, particularly in many MPLS deployments have used multipath techniques, particularly in
very high bandwidth applications, such as provider IP/MPLS core very high bandwidth applications, such as provider IP/MPLS core
networks. MPLS-TP has strongly discouraged the use of multipath networks. MPLS-TP has strongly discouraged the use of multipath
techniques. Some degradation of MPLS-TP OAM performance cannot be techniques. Some degradation of MPLS-TP OAM performance cannot be
avoided when operating over many types of multipath implementations. avoided when operating over many types of multipath implementations.
Using MPLS Entropy label, MPLS LSPs can be carried over multipath Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be
links while also providing a fully MPLS-TP compliant server layer for carried over multipath links while also providing a fully MPLS-TP
MPLS-TP LSPs. This document describes the means of supporting MPLS compliant server layer for MPLS-TP LSPs. This document describes the
as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server means of supporting MPLS as a server layer for MPLS-TP. The use of
layer for MPLS LSPs is also discussed. MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.
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 12, 2014. This Internet-Draft will expire on May 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . . 5 3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . 4
3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . . 5 3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . 4
3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 6 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 6
4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . . 9 4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Today the requirement to handle large aggregations of traffic, can be Today the requirement to handle large aggregations of traffic, can be
met by a number of techniques which we will collectively call met by a number of techniques which we will collectively call
multipath. Multipath applied to parallel links between the same set multipath. Multipath applied to parallel links between the same set
of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link
bundling [RFC4201], or other aggregation techniques some of which bundling [RFC4201], or other aggregation techniques some of which
could be vendor specific. Multipath applied to diverse paths rather could be vendor specific. Multipath applied to diverse paths rather
than parallel links includes Equal Cost MultiPath (ECMP) as applied than parallel links includes Equal Cost MultiPath (ECMP) as applied
to OSPF, ISIS, or BGP, and equal cost LSPs. Some vendors support to OSPF, IS-IS, or BGP, and equal cost Label Switched Paths (LSPs).
load split across equal cost MPLS LSPs where the load is split Some vendors support load split across equal cost MPLS LSPs where the
proportionally to the reserved bandwidth of the set of LSPs. load is split proportionally to the reserved bandwidth of the set of
LSPs.
RFC 5654 requirement 33 requires the capability to carry a client RFC 5654 requirement 33 requires the capability to carry a client
MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654].
This is possible in all cases with one exception. When an MPLS LSP This is possible in all cases with one exception. When an MPLS LSP
exceeds the capacity of any single component link it MAY be carried exceeds the capacity of any single component link it MAY be carried
by a network using multipath techniques, but MAY NOT be carried by a by a network using multipath techniques, but MAY NOT be carried by a
single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation
imposed by MPLS-TP OAM fate sharing constraints and MPLS-TP LM OAM imposed by MPLS-TP Operations, Administration, and Maintenance (OAM)
packet ordering constraints (see Section 3.1). fate sharing constraints and MPLS-TP LM OAM packet ordering
constraints (see Section 3.1).
The term composite link is more general than terms such as link The term composite link is more general than terms such as link
aggregation (which is specific to Ethernet) or ECMP (which implies aggregation (which is specific to Ethernet) or ECMP (which implies
equal cost paths within a routing protocol). The use of the term equal cost paths within a routing protocol). The use of the term
composite link here is consistent with the broad definition in composite link here is consistent with the broad definition in
[ITU-T.G.800]. Multipath is very similar to composite link as [ITU-T.G.800]. Multipath is very similar to composite link as
defined by ITU-T, but specifically excludes inverse multiplexing. defined by ITU-T, but specifically excludes inverse multiplexing.
2. Definitions 2. Definitions
skipping to change at page 4, line 20 skipping to change at page 3, line 43
publication of RFC4201, for brevity this special case has been publication of RFC4201, for brevity this special case has been
referred to as the "all-ones component". referred to as the "all-ones component".
Equal Cost Multipath (ECMP) Equal Cost Multipath (ECMP)
Equal Cost Multipath (ECMP) is a specific form of multipath in Equal Cost Multipath (ECMP) is a specific form of multipath in
which the costs of the links or paths must be equal in a given which the costs of the links or paths must be equal in a given
routing protocol. The load may be split equally across all routing protocol. The load may be split equally across all
available links (or available paths), or the load may be split available links (or available paths), or the load may be split
proportionally to the capacity of each link (or path). proportionally to the capacity of each link (or path).
Loop Free Alternate Paths Loop Free Alternate Paths (LFA)
"Loop-free alternate paths" (LFA) are defined in RFC 5714, "Loop-free alternate paths" (LFA) are defined in RFC 5714,
Section 5.2 [RFC5714] as follows. "Such a path exists when a Section 5.2 [RFC5714] as follows. "Such a path exists when a
direct neighbor of the router adjacent to the failure has a path direct neighbor of the router adjacent to the failure has a path
to the destination that can be guaranteed not to traverse the to the destination that can be guaranteed not to traverse the
failure." Further detail can be found in [RFC5286]. LFA as failure." Further detail can be found in [RFC5286]. LFA as
defined for IPFRR can be used to load balance by relaxing the defined for IPFRR can be used to load balance by relaxing the
equal cost criteria of ECMP, though IPFRR defined LFA for use in equal cost criteria of ECMP, though IPFRR defined LFA for use in
selecting protection paths. When used with IP, proportional selecting protection paths. When used with IP, proportional
split is generally not used. LFA use in load balancing is split is generally not used. LFA use in load balancing is
implemented by some vendors though it may be rare or non-existent implemented by some vendors though it may be rare or non-existent
in deployments. in deployments.
Link Aggregation Link Aggregation
The term "link aggregation" generally refers to Ethernet Link The term "link aggregation" generally refers to Ethernet Link
Aggregation [IEEE-802.1AX] as defined by the IEEE. Ethernet Link Aggregation [IEEE-802.1AX] as defined by the IEEE. Ethernet Link
Aggregation defines a Link Aggregation Control Protocol (LACP) Aggregation defines a Link Aggregation Control Protocol (LACP)
which coordinates inclusion of LAG members in the LAG. which coordinates inclusion of Link Aggregation Group (LAG)
members in the LAG.
Link Aggregation Group (LAG) Link Aggregation Group (LAG)
A group of physical Ethernet interfaces that are treated as a A group of physical Ethernet interfaces that are treated as a
logical link when using Ethernet Link Aggregation is referred to logical link when using Ethernet Link Aggregation is referred to
as a Link Aggregation Group (LAG). as a Link Aggregation Group (LAG).
LAG Member LAG Member
Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to
an individual link in a LAG as a LAG member. A LAG member is a an individual link in a LAG as a LAG member. A LAG member is a
component link. An Ethernet LAG is a composite link. IEEE does component link. An Ethernet LAG is a composite link. IEEE does
skipping to change at page 7, line 7 skipping to change at page 6, line 33
the alternate paths cannot be accounted for. the alternate paths cannot be accounted for.
3.2. Methods of Supporting MPLS-TP client LSPs over MPLS 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS
Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP
server layer where the MPLS LSPs are making use of multipath, server layer where the MPLS LSPs are making use of multipath,
requires special treatment of the MPLS-TP LSPs such that those LSPs requires special treatment of the MPLS-TP LSPs such that those LSPs
meet MPLS-TP forwarding requirements (see Section 3.1). This implies meet MPLS-TP forwarding requirements (see Section 3.1). This implies
the following brief set of requirements. the following brief set of requirements.
MP#1 It MUST be possible for a midpoint MPLS-TP LSR which is serving MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching
as ingress to a server layer MPLS LSP to identify MPLS-TP LSPs, Router (LSR) which is serving as ingress to a server layer MPLS
so that MPLS-TP forwarding requirements can be applied, or to LSP to identify MPLS-TP LSPs, so that MPLS-TP forwarding
otherwise accommodate the MPLS-TP forwarding requirements. requirements can be applied, or to otherwise accommodate the
MPLS-TP forwarding requirements.
MP#2 The ability to completely exclude MPLS-TP LSPs from the MP#2 The ability to completely exclude MPLS-TP LSPs from the
multipath hash and load split SHOULD be supported. If the multipath hash and load split SHOULD be supported. If the
selected component link no longer meets requirements, an LSP is selected component link no longer meets requirements, an LSP is
considered down which may trigger protection and/or may require considered down which may trigger protection and/or may require
that the ingress LSR select a new path and signal a new LSP. that the ingress LSR select a new path and signal a new LSP.
MP#3 It SHOULD be possible to insure that MPLS-TP LSPs will not be MP#3 It SHOULD be possible to insure that MPLS-TP LSPs will not be
moved to another component link as a result of a composite link moved to another component link as a result of a composite link
load rebalancing operation. If the selected component link no load rebalancing operation. If the selected component link no
longer meets requirements, another component link may be longer meets requirements, another component link may be
selected, however a change in path should not occur solely for selected, however a change in path should not occur solely for
load balancing. load balancing.
MP#4 Where an RSVP-TE control plane is used, it MUST be possible for MP#4 Where an Resource Reservation Protocol - Traffic Engineering
an ingress LSR which is setting up an MPLS-TP or an MPLS LSP to (RSVP-TE) control plane is used, it MUST be possible for an
determine at path selection time whether a link or Forwarding ingress LSR which is setting up an MPLS-TP or an MPLS LSP to
Adjacency (FA, see [RFC4206]) within the topology can support determine at path selection time whether a link or Forwarding
the MPLS-TP requirements of the LSP. Adjacency (FA, see [RFC4206]) within the topology can support the
MPLS-TP requirements of the LSP.
The reason for requirement MP#1 may not be obvious. A MPLS-TP LSP The reason for requirement MP#1 may not be obvious. A MPLS-TP LSP
may be aggregated along with other client LSPs by a midpoint LSR into may be aggregated along with other client LSPs by a midpoint LSR into
a very large MPLS server layer LSP, as would be the case in a core a very large MPLS server layer LSP, as would be the case in a core
node to core node MPLS LSP between major cities. In this case the node to core node MPLS LSP between major cities. In this case the
ingress of the MPLS LSP, being a midpoint LSR for a set of client ingress of the MPLS LSP, being a midpoint LSR for a set of client
LSP, has no signaling mechanism that can be used to determine if any LSP, has no signaling mechanism that can be used to determine if any
specific client LSP contained within it is MPLS or MPLS-TP. specific client LSP contained within it is MPLS or MPLS-TP.
Multipath load splitting can be avoided for MPLS-TP LSP if at the Multipath load splitting can be avoided for MPLS-TP LSP if at the
MPLS server layer LSP ingress LSR an Entropy Label Indicator (ELI) MPLS server layer LSP ingress LSR an Entropy Label Indicator (ELI)
skipping to change at page 8, line 8 skipping to change at page 7, line 37
There is currently no signaling mechanism defined to support There is currently no signaling mechanism defined to support
requirement MP#1, though that does not preclude a new extension being requirement MP#1, though that does not preclude a new extension being
defined later. In the absence of a signaling extension, MPLS-TP can defined later. In the absence of a signaling extension, MPLS-TP can
be identified through some form of configuration, such as be identified through some form of configuration, such as
configuration which provides an MPLS-TP compatible server layer to configuration which provides an MPLS-TP compatible server layer to
all LSP arriving on a specific interface or originating from a all LSP arriving on a specific interface or originating from a
specific set of ingress LSR. specific set of ingress LSR.
Alternately, the need for requirement MP#1 can be eliminated if every Alternately, the need for requirement MP#1 can be eliminated if every
MPLS-TP LSP can be created by the MPLS-TP ingress makes use of an MPLS-TP LSP created by an MPLS-TP ingress makes use of an Entropy
Entropy Label Indicator (ELI) and Entropy Label (EL) below the Label Indicator (ELI) and Entropy Label (EL) below the MPLS-TP label
MPLS-TP label [RFC6790]. This would require that all MPLS-TP LSR in [RFC6790]. This would require that all MPLS-TP LSR in a deployment
a deployment support Entropy Label, which may render it impractical support Entropy Label, which may render it impractical in many
in many deployments. deployments.
Some hardware which exists today can support requirement MP#2. Some hardware which exists today can support requirement MP#2.
Signaling in the absence of MPLS Entropy Label can make use of link Signaling in the absence of MPLS Entropy Label can make use of link
bundling with the path pinned to a specific component for MPLS-TP LSP bundling with the path pinned to a specific component for MPLS-TP LSP
and link bundling using the all-ones component for MPLS LSP. This and link bundling using the all-ones component for MPLS LSP. This
prevents MPLS-TP LSP from being carried within MPLS LSP but does prevents MPLS-TP LSP from being carried within MPLS LSP but does
allow the co-existance of MPLS-TP and very large MPLS LSP. allow the co-existance of MPLS-TP and very large MPLS LSP.
MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP
if an Entropy Label Indicator (ELI) and Entropy Label (EL) is pushed if an Entropy Label Indicator (ELI) and Entropy Label (EL) is pushed
below the server layer LSP label(s) in the label stack, just above below the server layer LSP label(s) in the label stack, just above
the MPLS-TP LSP label entry [RFC6790]. The value of EL can be the MPLS-TP LSP label entry [RFC6790]. The value of EL can be
randomly selected at the client MPLS-TP LSP setup time and the same randomly selected at the client MPLS-TP LSP setup time and the same
EL value used for all packets of that MPLS-TP LSP. This allows EL value used for all packets of that MPLS-TP LSP. This allows MPLS-
MPLS-TP LSP to be carried as client LSP within MPLS LSP and satisfies TP LSP to be carried as client LSP within MPLS LSP and satisfies
MPLS-TP forwarding requirements but requires that MPLS LSR be able to MPLS-TP forwarding requirements but requires that MPLS LSR be able to
identify MPLS-TP LSP (requirement MP#1). identify MPLS-TP LSP (requirement MP#1).
MPLS-TP traffic can be protected from degraded performance due to an MPLS-TP traffic can be protected from degraded performance due to an
imperfect load split if the MPLS-TP traffic is given queuing priority imperfect load split if the MPLS-TP traffic is given queuing priority
(using strict priority and policing or shaping at ingress or locally (using strict priority and policing or shaping at ingress or locally
or weighted queuing locally). This can be accomplished using the or weighted queuing locally). This can be accomplished using the
Traffic Class field and Diffserv treatment of traffic Traffic Class field and Diffserv treatment of traffic
[RFC5462][RFC2475]. In the event of congestion due to load [RFC5462][RFC2475]. In the event of congestion due to load
imbalance, only non-prioritized traffic will suffer as long as there imbalance, only non-prioritized traffic will suffer as long as there
skipping to change at page 9, line 15 skipping to change at page 8, line 43
LSP must be the top level LSP, except as noted above. LSP must be the top level LSP, except as noted above.
If MPLS-TP LSP can be moved among component links, then the Link If MPLS-TP LSP can be moved among component links, then the Link
Bundle all-ones component link can be used or server layer MPLS LSPs Bundle all-ones component link can be used or server layer MPLS LSPs
can be used with no restrictions on the server layer MPLS use of can be used with no restrictions on the server layer MPLS use of
multipath except that Entropy Label must be supported along the multipath except that Entropy Label must be supported along the
entire path. An Entropy Label must be used to insure that all of the entire path. An Entropy Label must be used to insure that all of the
MPLS-TP payload and OAM traffic are carried on the same component, MPLS-TP payload and OAM traffic are carried on the same component,
except during very infrequent transitions due to load balancing. except during very infrequent transitions due to load balancing.
Since the Entropy Label Indicator and Entropy Label are always placed Since the Entropy Label Indicator and Entropy Label are always placed
above the GAL in the stack, the presense of GAL will not affect the above the Generic Associated Channel Label (GAL) in the stack, the
selection of a component link as long as the LSR does not hash on the presense of GAL will not affect the selection of a component link as
label stack entries below the Entropy Label. long as the LSR does not hash on the label stack entries below the
Entropy Label.
An MPLS-TP LSP may not traverse multipath links on the path where An MPLS-TP LSP may not traverse multipath links on the path where
MPLS-TP forwarding requirements cannot be met. Such links include MPLS-TP forwarding requirements cannot be met. Such links include
any using pre-RFC6790 Ethernet Link Aggregation, pre-RFC6790 Link any using pre-RFC6790 Ethernet Link Aggregation, pre-RFC6790 Link
Bundling using the all-ones component link, or other form of Bundling using the all-ones component link, or other form of
multipath not supporting termination of the entropy search at the EL multipath not supporting termination of the entropy search at the EL
label as called for in [RFC6790]. An MPLS-TP LSP must not traverse a label as called for in [RFC6790]. An MPLS-TP LSP must not traverse a
server layer MPLS LSP which traverses any form of multipath not server layer MPLS LSP which traverses any form of multipath not
supporting termination of the entropy search at the EL label. For supporting termination of the entropy search at the EL label. For
this to occur, the MPLS-TP ingress LSR must be aware of these links. this to occur, the MPLS-TP ingress LSR must be aware of these links.
This is the reason for requirement MP#4. This is the reason for requirement MP#4.
Requirement MP#4 can be supported using administrative attributes. Requirement MP#4 can be supported using administrative attributes.
Administrative attributes are defined in [RFC3209]. Some Administrative attributes are defined in [RFC3209]. Some
configuration is required to support this. configuration is required to support this.
4. MPLS-TP as a Server Layer for MPLS 4. MPLS-TP as a Server Layer for MPLS
Carrying MPLS LSP which are larger than a component link over a Carrying MPLS LSP which are larger than a component link over a MPLS-
MPLS-TP server layer requires that the large MPLS client layer LSP be TP server layer requires that the large MPLS client layer LSP be
accommodated by multiple MPLS-TP server layer LSPs. MPLS multipath accommodated by multiple MPLS-TP server layer LSPs. MPLS multipath
can be used in the client layer MPLS. can be used in the client layer MPLS.
Creating multiple MPLS-TP server layer LSP places a greater Incoming Creating multiple MPLS-TP server layer LSP places a greater Incoming
Label Map (ILM) scaling burden on the LSR. High bandwidth MPLS cores Label Map (ILM) scaling burden on the LSR. High bandwidth MPLS cores
with a smaller amount of nodes have the greatest tendency to require with a smaller amount of nodes have the greatest tendency to require
LSP in excess of component links, therefore the reduction in number LSP in excess of component links, therefore the reduction in number
of nodes offsets the impact of increasing the number of server layer of nodes offsets the impact of increasing the number of server layer
LSP in parallel. Today, only in cases where deployed LSR ILM are LSP in parallel. Today, only in cases where deployed LSR ILM are
small would this be an issue. small would this be an issue.
The most significant disadvantage of MPLS-TP as a Server Layer for The most significant disadvantage of MPLS-TP as a Server Layer for
MPLS is that the use MPLS-TP server layer LSP reduces the efficiency MPLS is that the use MPLS-TP server layer LSP reduces the efficiency
of carrying the MPLS client layer. The service which provides by far of carrying the MPLS client layer. The service which provides by far
the largest offered load in provider networks is Internet, for which the largest offered load in provider networks is Internet, for which
the LSP capacity reservations are predictions of expected load. Many the LSP capacity reservations are predictions of expected load. Many
of these MPLS LSP may be smaller than component link capacity. Using of these MPLS LSP may be smaller than component link capacity. Using
MPLS-TP as a server layer results in bin packing problems for these MPLS-TP as a server layer results in bin packing problems for these
smaller LSP. For those LSP that are larger than component link smaller LSP. For those LSP that are larger than component link
capacity, their capacity are not increments of convenient capacity capacity, their capacity are not integer multiples of convenient
increments such as 10Gb/s. Using MPLS-TP as an underlying server capacity increments such as 10Gb/s. Using MPLS-TP as an underlying
layer greatly reduces the ability of the client layer MPLS LSP to server layer greatly reduces the ability of the client layer MPLS LSP
share capacity. For example, when one MPLS LSP is underutilizing its to share capacity. For example, when one MPLS LSP is underutilizing
predicted capacity, the fixed allocation of MPLS-TP to component its predicted capacity, the fixed allocation of MPLS-TP to component
links may not allow another LSP to exceed its predicted capacity. links may not allow another LSP to exceed its predicted capacity.
Using MPLS-TP as a server layer may result in less efficient use of Using MPLS-TP as a server layer may result in less efficient use of
resources and may result in a less cost effective network. resources and may result in a less cost effective network.
No additional requirements beyond MPLS-TP as it is now currently No additional requirements beyond MPLS-TP as it is now currently
defined are required to support MPLS-TP as a Server Layer for MPLS. defined are required to support MPLS-TP as a Server Layer for MPLS.
It is therefore viable but has some undesirable characteristics It is therefore viable but has some undesirable characteristics
discussed above. discussed above.
5. Acknowledgements 5. Acknowledgements
skipping to change at page 10, line 47 skipping to change at page 10, line 28
This is an informational document which describes usage of MPLS and This is an informational document which describes usage of MPLS and
MPLS-TP. No new protocol extensions or forwarding behavior are MPLS-TP. No new protocol extensions or forwarding behavior are
specified. Ethernet Link Aggregation and MPLS Link Bundling are specified. Ethernet Link Aggregation and MPLS Link Bundling are
widely implemented and deployed. widely implemented and deployed.
Entropy Label is not yet widely implemented and deployed, but both Entropy Label is not yet widely implemented and deployed, but both
implementation and deployment are expected soon. At least a few implementation and deployment are expected soon. At least a few
existing high end commodity packet processing chips are capable of existing high end commodity packet processing chips are capable of
supporting Entropy Label. It would be helpful if a few LSR suppliers supporting Entropy Label. It would be helpful if a few LSR suppliers
would state their intentions to support RFC 6790 on the mpls mailing would state their intentions to support RFC 6790 on the MPLS mailing
list. list.
Dynamic multipath (multipath load split adjustment in response to Dynamic multipath (multipath load split adjustment in response to
observed load) is referred to but not a requirement of the usage observed load) is referred to but not a requirement of the usage
recommendations made in this document. Dynamic multipath has been recommendations made in this document. Dynamic multipath has been
implemented and deployed, however (afaik) the only core LSR vendor implemented and deployed, however (afaik) the only core LSR vendor
supporting dynamic multipath is no longer in the router business supporting dynamic multipath is no longer in the router business
(Avici Systems). At least a few existing high end commodity packet (Avici Systems). At least a few existing high end commodity packet
processing chips are capable of supporting dynamic multipath. processing chips are capable of supporting dynamic multipath.
skipping to change at page 12, line 47 skipping to change at page 12, line 23
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
RFC 5714, January 2010. 5714, January 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013. Framework", RFC 6941, April 2013.
Author's Address Author's Address
 End of changes. 21 change blocks. 
70 lines changed or deleted 76 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/