< draft-ietf-rtgwg-cl-framework-03.txt   draft-ietf-rtgwg-cl-framework-04.txt >
RTGWG S. Ning RTGWG S. Ning
Internet-Draft Tata Communications Internet-Draft Tata Communications
Intended status: Informational D. McDysan Intended status: Informational D. McDysan
Expires: December 17, 2013 Verizon Expires: January 16, 2014 Verizon
E. Osborne E. Osborne
Cisco Cisco
L. Yong L. Yong
Huawei USA Huawei USA
C. Villamizar C. Villamizar
Outer Cape Cod Network Outer Cape Cod Network
Consulting Consulting
June 15, 2013 July 15, 2013
Composite Link Framework in Multi Protocol Label Switching (MPLS) Advanced Multipath Framework in MPLS
draft-ietf-rtgwg-cl-framework-03 draft-ietf-rtgwg-cl-framework-04
Abstract Abstract
This document specifies a framework for support of composite link in This document specifies a framework for support of Advanced Multipath
MPLS networks. A composite link consists of a group of homogenous or in MPLS networks. As defined in this framework, an Advanced
non-homogenous links that have the same forward adjacency and can be Multipath consists of a group of homogenous or non-homogenous links
considered as a single TE link or an IP link in routing. A composite that have the same forward adjacency (FA) and can be considered as a
link relies on its component links to carry the traffic over the single TE link or an IP link when advertised into IGP routing.
composite link. Applicability is described for a single pair of
MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of
layer networks connecting MPLS-capable nodes.
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 December 17, 2013. This Internet-Draft will expire on January 16, 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
skipping to change at page 2, line 24 skipping to change at page 2, line 21
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Architecture Summary . . . . . . . . . . . . . . . . . . . 4 1.2. Architecture Summary . . . . . . . . . . . . . . . . . . . 4
1.3. Conventions used in this document . . . . . . . . . . . . 5 1.3. Conventions used in this document . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Document Issues . . . . . . . . . . . . . . . . . . . . . 5 1.5. Document Issues . . . . . . . . . . . . . . . . . . . . . 5
2. Composite Link Key Characteristics . . . . . . . . . . . . . . 7 2. Advanced Multipath Key Characteristics . . . . . . . . . . . . 7
2.1. Flow Identification . . . . . . . . . . . . . . . . . . . 7 2.1. Flow Identification . . . . . . . . . . . . . . . . . . . 7
2.2. Composite Link in Control Plane . . . . . . . . . . . . . 10 2.1.1. Flow Identification Granularity . . . . . . . . . . . 8
2.3. Composite Link in Data Plane . . . . . . . . . . . . . . . 13 2.1.2. Flow Identification Summary . . . . . . . . . . . . . 9
2.1.3. Flow Identification Using Entropy Label . . . . . . . 9
2.2. Advanced Multipath in Control Plane . . . . . . . . . . . 10
2.3. Advanced Multipath in Data Plane . . . . . . . . . . . . . 13
3. Architecture Tradeoffs . . . . . . . . . . . . . . . . . . . . 14 3. Architecture Tradeoffs . . . . . . . . . . . . . . . . . . . . 14
3.1. Scalability Motivations . . . . . . . . . . . . . . . . . 14 3.1. Scalability Motivations . . . . . . . . . . . . . . . . . 14
3.2. Reducing Routing Information and Exchange . . . . . . . . 15 3.2. Reducing Routing Information and Exchange . . . . . . . . 15
3.3. Reducing Signaling Load . . . . . . . . . . . . . . . . . 16 3.3. Reducing Signaling Load . . . . . . . . . . . . . . . . . 15
3.3.1. Reducing Signaling Load using LDP . . . . . . . . . . 16 3.3.1. Reducing Signaling Load using LDP MPTP . . . . . . . . 16
3.3.2. Reducing Signaling Load using Hierarchy . . . . . . . 17 3.3.2. Reducing Signaling Load using Hierarchy . . . . . . . 16
3.3.3. Using Both LDP and RSVP-TE Hierarchy . . . . . . . . . 17 3.3.3. Using Both LDP MPTP and RSVP-TE Hierarchy . . . . . . 17
3.4. Reducing Forwarding State . . . . . . . . . . . . . . . . 17 3.4. Reducing Forwarding State . . . . . . . . . . . . . . . . 17
3.5. Avoiding Route Oscillation . . . . . . . . . . . . . . . . 18 3.5. Avoiding Route Oscillation . . . . . . . . . . . . . . . . 17
4. New Challenges . . . . . . . . . . . . . . . . . . . . . . . . 18 4. New Challenges . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Control Plane Challenges . . . . . . . . . . . . . . . . . 19 4.1. Control Plane Challenges . . . . . . . . . . . . . . . . . 19
4.1.1. Delay and Jitter Sensitive Routing . . . . . . . . . . 19 4.1.1. Delay and Jitter Sensitive Routing . . . . . . . . . . 19
4.1.2. Local Control of Traffic Distribution . . . . . . . . 20 4.1.2. Local Control of Traffic Distribution . . . . . . . . 20
4.1.3. Path Symmetry Requirements . . . . . . . . . . . . . . 20 4.1.3. Path Symmetry Requirements . . . . . . . . . . . . . . 20
4.1.4. Requirements for Contained LSP . . . . . . . . . . . . 21 4.1.4. Requirements for Contained LSP . . . . . . . . . . . . 21
4.1.5. Retaining Backwards Compatibility . . . . . . . . . . 21 4.1.5. Retaining Backwards Compatibility . . . . . . . . . . 21
4.2. Data Plane Challenges . . . . . . . . . . . . . . . . . . 22 4.2. Data Plane Challenges . . . . . . . . . . . . . . . . . . 22
4.2.1. Very Large LSP . . . . . . . . . . . . . . . . . . . . 22 4.2.1. Very Large LSP . . . . . . . . . . . . . . . . . . . . 22
4.2.2. Very Large Microflows . . . . . . . . . . . . . . . . 23 4.2.2. Very Large Microflows . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 13 skipping to change at page 3, line 13
5. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 25 5. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 25
5.1. Link Bundling . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Link Bundling . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Classic Multipath . . . . . . . . . . . . . . . . . . . . 26 5.2. Classic Multipath . . . . . . . . . . . . . . . . . . . . 26
6. Mechanisms Proposed in Other Documents . . . . . . . . . . . . 27 6. Mechanisms Proposed in Other Documents . . . . . . . . . . . . 27
6.1. Loss and Delay Measurement . . . . . . . . . . . . . . . . 27 6.1. Loss and Delay Measurement . . . . . . . . . . . . . . . . 27
6.2. Link Bundle Extensions . . . . . . . . . . . . . . . . . . 28 6.2. Link Bundle Extensions . . . . . . . . . . . . . . . . . . 28
6.3. Pseudowire Flow and MPLS Entropy Labels . . . . . . . . . 28 6.3. Pseudowire Flow and MPLS Entropy Labels . . . . . . . . . 28
6.4. Multipath Extensions . . . . . . . . . . . . . . . . . . . 29 6.4. Multipath Extensions . . . . . . . . . . . . . . . . . . . 29
7. Required Protocol Extensions and Mechanisms . . . . . . . . . 29 7. Required Protocol Extensions and Mechanisms . . . . . . . . . 29
7.1. Brief Review of Requirements . . . . . . . . . . . . . . . 29 7.1. Brief Review of Requirements . . . . . . . . . . . . . . . 29
7.2. Proposed Document Coverage . . . . . . . . . . . . . . . . 31 7.2. Proposed Document Coverage . . . . . . . . . . . . . . . . 30
7.2.1. Component Link Grouping . . . . . . . . . . . . . . . 31 7.2.1. Component Link Grouping . . . . . . . . . . . . . . . 31
7.2.2. Delay and Jitter Extensions . . . . . . . . . . . . . 31 7.2.2. Delay and Jitter Extensions . . . . . . . . . . . . . 31
7.2.3. Path Selection and Admission Control . . . . . . . . . 32 7.2.3. Path Selection and Admission Control . . . . . . . . . 32
7.2.4. Dynamic Multipath Balance . . . . . . . . . . . . . . 32 7.2.4. Dynamic Multipath Balance . . . . . . . . . . . . . . 32
7.2.5. Frequency of Load Balance . . . . . . . . . . . . . . 33 7.2.5. Frequency of Load Balance . . . . . . . . . . . . . . 33
7.2.6. Inter-Layer Communication . . . . . . . . . . . . . . 33 7.2.6. Inter-Layer Communication . . . . . . . . . . . . . . 33
7.2.7. Packet Ordering Requirements . . . . . . . . . . . . . 33 7.2.7. Packet Ordering Requirements . . . . . . . . . . . . . 33
7.2.8. Minimally Disruption Load Balance . . . . . . . . . . 34 7.2.8. Minimally Disruption Load Balance . . . . . . . . . . 34
7.2.9. Path Symmetry . . . . . . . . . . . . . . . . . . . . 34 7.2.9. Path Symmetry . . . . . . . . . . . . . . . . . . . . 34
7.2.10. Performance, Scalability, and Stability . . . . . . . 35 7.2.10. Performance, Scalability, and Stability . . . . . . . 35
7.2.11. IP and LDP Traffic . . . . . . . . . . . . . . . . . . 35 7.2.11. IP and LDP Traffic . . . . . . . . . . . . . . . . . . 35
7.2.12. LDP Extensions . . . . . . . . . . . . . . . . . . . . 35 7.2.12. LDP Extensions . . . . . . . . . . . . . . . . . . . . 35
7.2.13. Pseudowire Extensions . . . . . . . . . . . . . . . . 36 7.2.13. Pseudowire Extensions . . . . . . . . . . . . . . . . 36
7.2.14. Multi-Domain Composite Link . . . . . . . . . . . . . 36 7.2.14. Multi-Domain Advanced Multipath . . . . . . . . . . . 36
7.3. Framework Requirement Coverage by Protocol . . . . . . . . 36 7.3. Framework Requirement Coverage by Protocol . . . . . . . . 36
7.3.1. OSPF-TE and ISIS-TE Protocol Extensions . . . . . . . 37 7.3.1. OSPF-TE and ISIS-TE Protocol Extensions . . . . . . . 37
7.3.2. PW Protocol Extensions . . . . . . . . . . . . . . . . 37 7.3.2. PW Protocol Extensions . . . . . . . . . . . . . . . . 37
7.3.3. LDP Protocol Extensions . . . . . . . . . . . . . . . 37 7.3.3. LDP Protocol Extensions . . . . . . . . . . . . . . . 37
7.3.4. RSVP-TE Protocol Extensions . . . . . . . . . . . . . 37 7.3.4. RSVP-TE Protocol Extensions . . . . . . . . . . . . . 37
7.3.5. RSVP-TE Path Selection Changes . . . . . . . . . . . . 37 7.3.5. RSVP-TE Path Selection Changes . . . . . . . . . . . . 37
7.3.6. RSVP-TE Admission Control and Preemption . . . . . . . 37 7.3.6. RSVP-TE Admission Control and Preemption . . . . . . . 37
7.3.7. Flow Identification and Traffic Balance . . . . . . . 37 7.3.7. Flow Identification and Traffic Balance . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 39 11.2. Informative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
Composite Link functional requirements are specified in Advanced Multipath functional requirements are specified in
[I-D.ietf-rtgwg-cl-requirement]. Composite Link use cases are [I-D.ietf-rtgwg-cl-requirement]. Advanced Multipath use cases are
described in [I-D.ietf-rtgwg-cl-use-cases]. This document specifies described in [I-D.ietf-rtgwg-cl-use-cases]. This document specifies
a framework to meet these requirements. a framework to meet these requirements.
This document describes a composite link framework in the context of This document describes an Advanced Multipath framework in the
MPLS networks using an IGP-TE and RSVP-TE MPLS control plane with context of MPLS networks using an IGP-TE and RSVP-TE MPLS control
GMPLS extensions [RFC3209] [RFC3630] [RFC3945] [RFC5305]. plane with GMPLS extensions [RFC3209] [RFC3630] [RFC3945] [RFC5305].
Specific protocol solutions are outside the scope of this document, Specific protocol solutions are outside the scope of this document,
however a framework for the extension of existing protocols is however a framework for the extension of existing protocols is
provided. Backwards compatibility is best achieved by extending provided. Backwards compatibility is best achieved by extending
existing protocols where practical rather than inventing new existing protocols where practical rather than inventing new
protocols. The focus is on examining where existing protocol protocols. The focus is on examining where existing protocol
mechanisms fall short with respect to [I-D.ietf-rtgwg-cl-requirement] mechanisms fall short with respect to [I-D.ietf-rtgwg-cl-requirement]
and on the types of extensions that will be required to accommodate and on the types of extensions that will be required to accommodate
functionality that is called for in [I-D.ietf-rtgwg-cl-requirement]. functionality that is called for in [I-D.ietf-rtgwg-cl-requirement].
1.1. Background 1.1. Background
Classic multipath, including Ethernet Link Aggregation has been Classic multipath, including Ethernet Link Aggregation has been
widely used in today's MPLS networks [RFC4385][RFC4928]. Classic widely used in today's MPLS networks [RFC4385][RFC4928]. Classic
multipath using non-Ethernet links are often advertised using MPLS multipath using non-Ethernet links are often advertised using MPLS
Link bundling. A link bundle [RFC4201] bundles a group of Link bundling. A link bundle [RFC4201] bundles a group of
homogeneous links as a TE link to make IGP-TE information exchange homogeneous links as a TE link to make IGP-TE information exchange
and RSVP-TE signaling more scalable. A composite link allows and RSVP-TE signaling more scalable. An Advanced Multipath allows
bundling non-homogenous links together as a single logical link. The bundling non-homogenous links together as a single logical link.
motivations for using a composite link are descried in
[I-D.ietf-rtgwg-cl-requirement] and [I-D.ietf-rtgwg-cl-use-cases].
A composite link is a single logical link in MPLS network that An Advanced Multipath is a single logical link in MPLS network that
contains multiple parallel component links between two MPLS LSR. contains multiple parallel component links between two MPLS LSR.
Unlike a link bundle [RFC4201], the component links in a composite Unlike a link bundle [RFC4201], the component links in an Advanced
link can have different properties such as cost, capacity, delay, or Multipath can have different properties such as cost, capacity,
jitter. delay, or jitter.
1.2. Architecture Summary 1.2. Architecture Summary
Networks aggregate information, both in the control plane and in the Networks aggregate information, both in the control plane and in the
data plane, as a means to achieve scalability. A tradeoff exists data plane, as a means to achieve scalability. A tradeoff exists
between the needs of scalability and the needs to identify differing between the needs of scalability and the needs to identify differing
path and link characteristics and differing requirements among flows path and link characteristics and differing requirements among flows
contained within further aggregated traffic flows. These tradeoffs contained within further aggregated traffic flows. These tradeoffs
are discussed in detail in Section 3. are discussed in detail in Section 3.
Some aspects of Composite Link requirements present challenges for Some aspects of Advanced Multipath requirements present challenges
which multiple solutions may exist. In Section 4 various challenges for which multiple solutions may exist. In Section 4 various
and potential approaches are discussed. challenges and potential approaches are discussed.
A subset of the functionality called for in A subset of the functionality called for in
[I-D.ietf-rtgwg-cl-requirement] is available through MPLS Link [I-D.ietf-rtgwg-cl-requirement] is available through MPLS Link
Bundling [RFC4201]. Link bundling and other existing standards Bundling [RFC4201]. Link bundling and other existing standards
applicable to Composite Link are covered in Section 5. applicable to Advanced Multipath are covered in Section 5.
The most straightforward means of supporting Composite Link The most straightforward means of supporting Advanced Multipath
requirements is to extend MPLS protocols and protocol semantics and requirements is to extend MPLS protocols and protocol semantics and
in particular to extend link bundling. Extensions which have already in particular to extend link bundling. Extensions which have already
been proposed in other documents which are applicable to Composite been proposed in other documents which are applicable to Advanced
Link are discussed in Section 6. Multipath are discussed in Section 6.
A goal of most new protocol work within IETF is to reuse existing A goal of most new protocol work within IETF is to reuse existing
protocol encapsulations and mechanisms where they meet requirements protocol encapsulations and mechanisms where they meet requirements
and extend existing mechanisms. This approach minimizes additional and extend existing mechanisms. This approach minimizes additional
complexity while meeting requirements and tends to preserve backwards complexity while meeting requirements and tends to preserve backwards
compatibility to the extent it is practical to do so. These goals compatibility to the extent it is practical to do so. These goals
are considered in proposing a framework for further protocol are considered in proposing a framework for further protocol
extensions and mechanisms in Section 7. extensions and mechanisms in Section 7.
1.3. Conventions used in this document 1.3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.4. Terminology 1.4. Terminology
Terminology defined in [I-D.ietf-rtgwg-cl-requirement] is used in Terminology defined in [I-D.ietf-rtgwg-cl-requirement] is used in
this document. this document. The additional terms defined in
[I-D.ietf-rtgwg-cl-use-cases] are also used.
The abbreviation IGP-TE is used as a shorthand indicating either The abbreviation IGP-TE is used as a shorthand indicating either
OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. OSPF-TE [RFC3630] or ISIS-TE [RFC5305].
1.5. Document Issues 1.5. Document Issues
This subsection exists solely for the purpose of focusing the RTGWG This subsection exists solely for the purpose of focusing the RTGWG
meeting and mailing list discussions on areas within this document meeting and mailing list discussions on areas within this document
that need attention in order for the document to achieve the level of that need attention in order for the document to achieve the level of
quality necessary to advance the document through the IETF process. quality necessary to advance the document through the IETF process.
skipping to change at page 6, line 23 skipping to change at page 6, line 21
3. Any measurement of jitter (delay variation) that is used in route 3. Any measurement of jitter (delay variation) that is used in route
decision is likely to cause oscillation. Trying to optimize a decision is likely to cause oscillation. Trying to optimize a
path to reduce jitter may be a fools errand. How do we say this path to reduce jitter may be a fools errand. How do we say this
in the draft or does the existing text cover it adequately? in the draft or does the existing text cover it adequately?
4. RTGWG needs to consider the possibility of using multi-topology 4. RTGWG needs to consider the possibility of using multi-topology
IGP extensions in IP and LDP routing where the topologies reflect IGP extensions in IP and LDP routing where the topologies reflect
differing requirements (see Section 4.2.5). This idea is similar differing requirements (see Section 4.2.5). This idea is similar
to TOS routing, which has been discussed for decades but has to TOS routing, which has been discussed for decades but has
never been deployed. One possible outcome of discussion would be never been deployed. One possible outcome of discussion would be
to declare TOS routing out of scope. to declare TOS routing out of scope in the requirements document.
5. The following referenced drafts have expired: 5. The following referenced drafts have expired:
A. [I-D.ospf-cc-stlv] A. [I-D.ospf-cc-stlv]
B. [I-D.villamizar-mpls-multipath-extn] B. [I-D.villamizar-mpls-multipath-extn]
A replacement for [I-D.ospf-cc-stlv] is expected to be submitted. A replacement for [I-D.ospf-cc-stlv] is expected to be submitted.
[I-D.villamizar-mpls-multipath-extn] is expected to emerge in a [I-D.villamizar-mpls-multipath-extn] is expected to emerge in a
simplified form, removing extensions for which existing simplified form, removing extensions for which existing
workarounds are considered adequate based on feedback at a prior workarounds are considered adequate based on feedback at a prior
IETF. IETF.
6. Clarification of what we intend to do with Multi-Domain Composite 6. Clarification of what we intend to do with Multi-Domain Advanced
Link is needed in Section 7.2.14. Multipath is needed in Section 7.2.14.
7. The following topics in the requirements document are not 7. The following topics in the requirements document are not
addressed. Since they are explicitly mentioned in the addressed. Since they are explicitly mentioned in the
requirements document some mention of how they are supported is requirements document some mention of how they are supported is
needed, even if to say nothing needs to be done. If we conclude needed in this document.
any particular topic is irrelevant, maybe the topic should be
removed from the requirement document. At that point we could
add the management requirements that have come up and were
missed.
A. L3VPN RFC 4364, RFC 4797, L2VPN RFC 4664, VPWS, VPLS RFC
4761, RFC 4762 and VPMS VPMS Framework
(draft-ietf-l2vpn-vpms-frmwk-requirements) are referenced in
the requirements document "Assumptions" section. It is not
clear what additional Composite Link requirements these
references imply, if any. If no additional requirements are
implied, then these references are considered to be
informational only.
B. Migration (incremental deployment) may not be adequately A. Migration (incremental deployment) may not be adequately
covered in Section 4.1.5. It might also be necessary to say covered in Section 4.1.5. It might also be necessary to say
more here on performance, scalability, and stability as it more here on performance, scalability, and stability as it
related to migration. Comments on this from co-authors or related to migration. Comments on this from co-authors or
the WG? the WG?
C. We may need a performance section in this document to B. We may need a performance section in this document to
specifically address #DR6 (fast convergence), and #DR7 (fast specifically address #DR6 (fast convergence), and #DR7 (fast
worst case failure convergence). We do already have worst case failure convergence). We do already have
scalability discussion and make a recommendation for a scalability discussion and make a recommendation for a
separate document. At the very least the performance section separate document. At the very least the performance section
would have to say "no worse than before, except were there would have to say "no worse than before, except were there
was no alternative to make it very slightly worse" (in a bit was no alternative to make it very slightly worse" (in a bit
more detail than that). It might also be helpful to better more detail than that). It might also be helpful to better
define the nature of the performance criteria implied by #DR6 define the nature of the performance criteria implied by #DR6
and #DR7. and #DR7.
The above list of issues are to be discussed at the upcoming IETF-85 The above list has been in this document for the better part of a
meeting. Hopefully some of the issues can be resolved at the meeting year with very little discussion (or none) of the above issues on the
or on the RTGWG mailing list. RTGWG mailing list.
2. Composite Link Key Characteristics 2. Advanced Multipath Key Characteristics
[I-D.ietf-rtgwg-cl-requirement] defines external behavior of [I-D.ietf-rtgwg-cl-requirement] defines external behavior of Advanced
Composite Links. The overall framework approach involves extending Multipath. The overall framework approach involves extending
existing protocols in a backwards compatible manner and reusing existing protocols in a backwards compatible manner and reusing
ongoing work elsewhere in IETF where applicable, defining new ongoing work elsewhere in IETF where applicable, defining new
protocols or semantics only where necessary. Given the requirements, protocols or semantics only where necessary. Given the requirements,
and this approach of extending MPLS, Composite Link key and this approach of extending MPLS, Advanced Multipath key
characteristics can be described in greater detail than given characteristics can be described in greater detail than given
requirements alone. requirements alone.
2.1. Flow Identification 2.1. Flow Identification
Traffic mapping to component links is a data plane operation. Traffic mapping to component links is a data plane operation.
Control over how the mapping is done may be directly dictated or Control over how the mapping is done may be directly dictated or
constrained by the control plane or by the management plane. When constrained by the control plane or by the management plane. When
unconstrained by the control plane or management plane, distribution unconstrained by the control plane or management plane, distribution
of traffic is entirely a local matter. Regardless of constraints or of traffic is entirely a local matter. Regardless of constraints or
skipping to change at page 8, line 13 skipping to change at page 7, line 45
packets belonging to individual flows in sequence and meet QoS packets belonging to individual flows in sequence and meet QoS
criteria specified per LSP by either signaling or management criteria specified per LSP by either signaling or management
[RFC2475] [RFC3260]. [RFC2475] [RFC3260].
Key objectives of the traffic distribution are to not overload any Key objectives of the traffic distribution are to not overload any
component link, and to be be able to perform local recovery when a component link, and to be be able to perform local recovery when a
subset of component links fails. subset of component links fails.
The network operator may have other objectives such as placing a The network operator may have other objectives such as placing a
bidirectional flow or LSP on the same component link in both bidirectional flow or LSP on the same component link in both
direction, bounding delay and/or jitter, composite link energy direction, bounding delay and/or jitter, Advanced Multipath energy
saving, and etc. These new requirements are described in saving, and etc. These new requirements are described in
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-requirement].
Examples of means to identify a flow may in principle include: Examples of means to identify a flow may in principle include:
1. an LSP identified by an MPLS label, 1. an LSP identified by an MPLS label,
2. a sub-LSP [I-D.kompella-mpls-rsvp-ecmp] identified by an MPLS 2. a pseudowire (PW) [RFC3985] identified by an MPLS PW label,
label,
3. a pseudowire (PW) [RFC3985] identified by an MPLS PW label,
4. a flow or group of flows within a pseudowire (PW) [RFC6391] 3. a flow or group of flows within a pseudowire (PW) [RFC6391]
identified by an MPLS flow label, identified by an MPLS flow label,
5. a flow or flow group in an LSP [RFC6790] identified by an MPLS 4. a flow or flow group in an LSP [RFC6790] identified by an MPLS
entropy label, entropy label,
6. all traffic between a pair of IP hosts, identified by an IP 5. all traffic between a pair of IP hosts, identified by an IP
source and destination pair, source and destination pair,
7. a specific connection between a pair of IP hosts, identified by 6. a specific connection between a pair of IP hosts, identified by
an IP source and destination pair, protocol, and protocol port an IP source and destination pair, protocol, and protocol port
pair, pair,
8. a layer-2 conversation within a pseudowire (PW), where the 7. a layer-2 conversation within a pseudowire (PW), where the
identification is PW payload type specific, such as Ethernet MAC identification is PW payload type specific, such as Ethernet MAC
addresses and VLAN tags within an Ethernet PW [RFC4448]. This is addresses and VLAN tags within an Ethernet PW [RFC4448]. This is
feasible but not practical (see below). feasible but not practical (see below).
Although in principle a layer-2 conversation within a pseudowire Although in principle a layer-2 conversation within a pseudowire
(PW), may be identified by PW payload type specific information, in (PW), may be identified by PW payload type specific information, in
practice this is impractical at LSP midpoints when PW are carried. practice this is impractical at LSP midpoints when PW are carried.
The PW ingress may provide equivalent information in a PW flow label The PW ingress may provide equivalent information in a PW flow label
[RFC6391]. Therefore, in practice, item #8 above is covered by [RFC6391]. Therefore, in practice, item #8 above is covered by
[RFC6391] and may be dropped from the list. [RFC6391] and may be dropped from the list.
2.1.1. Flow Identification Granularity
An LSR must at least be capable of identifying flows based on MPLS An LSR must at least be capable of identifying flows based on MPLS
labels. Most MPLS LSP do not require that traffic carried by the LSP labels. Most MPLS LSP do not require that traffic carried by the LSP
are carried in order. MPLS-TP is a recent exception. If it is are carried in order. MPLS-TP is a recent exception. If it is
assumed that no LSP require strict packet ordering of the LSP itself assumed that no LSP require strict packet ordering of the LSP itself
(only of flows within the LSP), then the entire label stack can be (only of flows within the LSP), then the entire label stack can be
used as flow identification. If some LSP may require strict packet used as flow identification. If some LSP may require strict packet
ordering but those LSP cannot be distinguished from others, then only ordering but those LSP cannot be distinguished from others, then only
the top label can be used as a flow identifier. If only the top the top label can be used as a flow identifier. If only the top
label is used (for example, as specified by [RFC4201] when the "all- label is used (for example, as specified by [RFC4201] when the "all-
ones" component described in [RFC4201] is not used), then there may ones" component described in [RFC4201] is not used), then there may
skipping to change at page 9, line 42 skipping to change at page 9, line 27
Using only the top label supports too coarse a traffic balance. Using only the top label supports too coarse a traffic balance.
Prior to MPLS Entropy Label [RFC6790] using the full label stack was Prior to MPLS Entropy Label [RFC6790] using the full label stack was
also too coarse. Using the full label stack and IP addresses as flow also too coarse. Using the full label stack and IP addresses as flow
identification provides a sufficiently fine traffic balance, but is identification provides a sufficiently fine traffic balance, but is
capable of identifying such a high number of distinct flows, that a capable of identifying such a high number of distinct flows, that a
technique of grouping flows, such as hashing on the flow technique of grouping flows, such as hashing on the flow
identification criteria, becomes essential to reduce the stored identification criteria, becomes essential to reduce the stored
state, and is an essential scaling technique. Other means of state, and is an essential scaling technique. Other means of
grouping flows may be possible. grouping flows may be possible.
2.1.2. Flow Identification Summary
In summary: In summary:
1. Load balancing using only the MPLS label stack provides too 1. Load balancing using only the MPLS label stack provides too
coarse a granularity of load balance. coarse a granularity of load balance.
2. Tracking every flow is not scalable due to the extremely large 2. Tracking every flow is not scalable due to the extremely large
number of flows in provider networks. number of flows in provider networks.
3. Existing techniques, IP source and destination hash in 3. Existing techniques, IP source and destination hash in
particular, have proven in over two decades of experience to be particular, have proven in over two decades of experience to be
an excellent way of identifying groups of flows. an excellent way of identifying groups of flows.
4. If a better way to identify groups of flows is discovered, then 4. If a better way to identify groups of flows is discovered, then
that method can be used. that method can be used.
5. IP address hashing is not required, but use of this technique is 5. IP address hashing is not required, but use of this technique is
strongly encouraged given the technique's long history of strongly encouraged given the technique's long history of
successful deployment. successful deployment.
MPLS Entropy Label [RFC6790] provides a means of the entropy from 2.1.3. Flow Identification Using Entropy Label
information that would require deeper packet inspection, such as
inspection of IP addresses, and putting that entropy in the form of a
hashed value into the label stack. Midpoint LSR that understand the
Entropy Label Indicator can make use of only label stack information
but still obtain a fine load balance granularity.
2.2. Composite Link in Control Plane MPLS Entropy Label [RFC6790] provides a means of making use of the
entropy from information that would require deeper packet inspection,
such as inspection of IP addresses, and putting that entropy in the
form of a hashed value into the label stack. Midpoint LSR that
understand the Entropy Label Indicator can make use of only label
stack information but still obtain a fine load balance granularity.
A composite Link is advertised as a single logical interface between 2.2. Advanced Multipath in Control Plane
two connected routers, which forms forwarding adjacency (FA) between
the routers. The FA is advertised as a TE-link in a link state IGP, An Advanced Multipath is advertised as a single logical interface
using either OSPF-TE or ISIS-TE. The IGP-TE advertised interface between two connected routers, which forms forwarding adjacency (FA)
parameters for the composite link can be preconfigured by the network between the routers. The FA is advertised as a TE-link in a link
operator or be derived from its component links. Composite link state IGP, using either OSPF-TE or ISIS-TE. The IGP-TE advertised
advertisement requirements are specified in interface parameters for the Advanced Multipath can be preconfigured
by the network operator or be derived from its component links.
Advanced Multipath advertisement requirements are specified in
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-requirement].
In IGP-TE, a composite link is advertised as a single TE link between In IGP-TE, an Advanced Multipath is advertised as a single TE link
two connected routers. This is similar to a link bundle [RFC4201]. between two connected routers. This is similar to a link bundle
Link bundle applies to a set of homogenous component links. [RFC4201]. Link bundle applies to a set of homogenous component
Composite link allows homogenous and non-homogenous component links. links. Advanced Multipath allows homogenous and non-homogenous
Due to the similarity, and for backwards compatibility, extending component links. Due to the similarity, and for backwards
link bundling is viewed as both simple and as the best approach. compatibility, extending link bundling is viewed as both simple and
as the best approach.
In order for a route computation engine to calculate a proper path In order for a route computation engine to calculate a proper path
for a LSP, it is necessary for composite link to advertise the for a LSP, it is necessary for Advanced Multipath to advertise the
summarized available bandwidth as well as the maximum bandwidth that summarized available bandwidth as well as the maximum bandwidth that
can be made available for single flow (or single LSP where no finer can be made available for single flow (or single LSP where no finer
flow identification is available). If a composite link contains some flow identification is available). If an Advanced Multipath contains
non-homogeneous component links, the composite link also should some non-homogeneous component links, the Advanced Multipath also
advertise the summarized bandwidth and the maximum bandwidth for should advertise the summarized bandwidth and the maximum bandwidth
single flow per each homogeneous component link group. for single flow per each homogeneous component link group.
Both LDP [RFC5036] and RSVP-TE [RFC3209] can be used to signal a LSP Both LDP [RFC5036] and RSVP-TE [RFC3209] can be used to signal a LSP
over a composite link. LDP cannot be extended to support traffic over an Advanced Multipath. LDP cannot be extended to support
engineering capabilities [RFC3468]. traffic engineering capabilities [RFC3468].
When an LSP is signaled using RSVP-TE, the LSP MUST be placed on the When an LSP is signaled using RSVP-TE, the LSP MUST be placed on the
component link that meets the LSP criteria indicated in the signaling component link that meets the LSP criteria indicated in the signaling
message. message.
When an LSP is signaled using LDP, the LSP MUST be placed on the When an LSP is signaled using LDP, the LSP MUST be placed on the
component link that meets the LSP criteria, if such a component link component link that meets the LSP criteria, if such a component link
is available. LDP does not support traffic engineering capabilities, is available. LDP does not support traffic engineering capabilities,
imposing restrictions on LDP use of Composite Link. See imposing restrictions on LDP use of Advanced Multipath. See
Section 4.2.5 for further details. Section 4.2.5 for further details.
If the composite link solution is based on extensions to IGP-TE and If the Advanced Multipath solution is based on extensions to IGP-TE
RSVP-TE, then in order to meet requirements defined in and RSVP-TE, then in order to meet requirements defined in
[I-D.ietf-rtgwg-cl-requirement], the following derived requirements [I-D.ietf-rtgwg-cl-requirement], the following derived requirements
MUST be met. MUST be met.
1. A composite link MAY contain non-homogeneous component links. 1. An Advanced Multipath MAY contain non-homogeneous component
The route computing engine MAY select one group of component links. The route computing engine MAY select one group of
links for a LSP. The The route computing engine MUST accommodate component links for a LSP. The The route computing engine MUST
service objectives for a given LSP when selecting a group of accommodate service objectives for a given LSP when selecting a
component links for a LSP. group of component links for a LSP.
2. The routing protocol MUST make a grouping of component links 2. The routing protocol MUST make a grouping of component links
available in the TE-LSDB, such that within each group all of the available in the TE-LSDB, such that within each group all of the
component links have similar characteristics (the component links component links have similar characteristics (the component links
are homogeneous within a group). are homogeneous within a group).
3. The route computation used in RSVP-TE MUST be extended to include 3. The route computation used in RSVP-TE MUST be extended to include
only the capacity of groups within a composite link which meet only the capacity of groups within an Advanced Multipath which
LSP criteria. meet LSP criteria.
4. The signaling protocol MUST be able to indicate either the 4. The signaling protocol MUST be able to indicate either the
criteria, or which groups may be used. criteria, or which groups may be used.
5. A composite link MUST place each LSP on a component link or group 5. An Advanced Multipath MUST place each LSP on a component link or
which meets or exceeds the LSP criteria. group which meets or exceeds the LSP criteria.
Composite link capacity is aggregated capacity. LSP capacity MAY be Advanced Multipath capacity is aggregated capacity. LSP capacity MAY
larger than individual component link capacity. Any aggregated LSP be larger than individual component link capacity. Any aggregated
can determine a bounds on the largest microflow that could be carried LSP can determine a bounds on the largest microflow that could be
and this constraint can be handled as follows. carried and this constraint can be handled as follows.
1. If no information is available through signaling, management 1. If no information is available through signaling, management
plane, or configuration, the largest microflow is bound by one of plane, or configuration, the largest microflow is bound by one of
the following: the following:
A. the largest single LSP if most traffic is RSVP-TE signaled A. the largest single LSP if most traffic is RSVP-TE signaled
and further aggregated, and further aggregated,
B. the largest pseudowire if most traffic is carrying pseudowire B. the largest pseudowire if most traffic is carrying pseudowire
payloads that are aggregated within RSVP-TE LSP, payloads that are aggregated within RSVP-TE LSP,
skipping to change at page 12, line 33 skipping to change at page 12, line 20
carried by the smaller LSP is signaled, then the largest carried by the smaller LSP is signaled, then the largest
microflow expected in the containing LSP (the aggregate) is the microflow expected in the containing LSP (the aggregate) is the
maximum of the largest expected microflow for any contained LSP. maximum of the largest expected microflow for any contained LSP.
For example, RSVP-TE LSP may be large but aggregate traffic for For example, RSVP-TE LSP may be large but aggregate traffic for
which the source or sink are all 1 Gb/s or smaller interfaces which the source or sink are all 1 Gb/s or smaller interfaces
(such as in mobile applications in which cell sites backhauls are (such as in mobile applications in which cell sites backhauls are
no larger than 1 Gb/s). If this information is carried in the no larger than 1 Gb/s). If this information is carried in the
LSP originated at the cell sites, then further aggregates across LSP originated at the cell sites, then further aggregates across
a core may make use of this information. a core may make use of this information.
3. The IGP must provide the bounds on the largest microflow that a 3. The IGP must provide the bounds on the largest microflow that an
composite link can accommodate, which is the maximum capacity on Advanced Multipath can accommodate, which is the maximum capacity
a component link that can be made available by moving other on a component link that can be made available by moving other
traffic. This information is needed by the ingress LER for path traffic. This information is needed by the ingress LER for path
determination. determination.
4. A means to signal an LSP whose capacity is larger than individual 4. A means to signal an LSP whose capacity is larger than individual
component link capacity is needed [I-D.ietf-rtgwg-cl-requirement] component link capacity is needed [I-D.ietf-rtgwg-cl-requirement]
and also signal the largest microflow expected to be contained in and also signal the largest microflow expected to be contained in
the LSP. If a bounds on the largest microflow is not signaled the LSP. If a bounds on the largest microflow is not signaled
there is no means to determine if an LSP which is larger than any there is no means to determine if an LSP which is larger than any
component link can be subdivided into flows and therefore should component link can be subdivided into flows and therefore should
be accepted by admission control. be accepted by admission control.
When a bidirectional LSP request is signaled over a composite link, When a bidirectional LSP request is signaled over an Advanced
if the request indicates that the LSP must be placed on the same Multipath, if the request indicates that the LSP must be placed on
component link, the routers of the composite link MUST place the LSP the same component link, the routers of the Advanced Multipath MUST
traffic in both directions on a same component link. This is place the LSP traffic in both directions on a same component link.
particularly challenging for aggregated capacity which makes use of This is particularly challenging for aggregated capacity which makes
the label stack for traffic distribution. The two requirements are use of the label stack for traffic distribution. The two
mutually exclusive for any one LSP. No one LSP may be both larger requirements are mutually exclusive for any one LSP. No one LSP may
than any individual component link and require symmetrical paths for be both larger than any individual component link and require
every flow. Both requirements can be accommodated by the same symmetrical paths for every flow. Both requirements can be
composite link for different LSP, with any one LSP requiring no more accommodated by the same Advanced Multipath for different LSP, with
than one of these two features. any one LSP requiring no more than one of these two features.
Individual component link may fail independently. Upon component Individual component link may fail independently. Upon component
link failure, a composite link MUST support a minimally disruptive link failure, an Advanced Multipath MUST support a minimally
local repair, preempting any LSP which can no longer be supported. disruptive local repair, preempting any LSP which can no longer be
Available capacity in other component links MUST be used to carry supported. Available capacity in other component links MUST be used
impacted traffic. The available bandwidth after failure MUST be to carry impacted traffic. The available bandwidth after failure
advertised immediately to avoid looped crankback. MUST be advertised immediately to avoid looped crankback.
When a composite link is not able to transport all flows, it preempts When an Advanced Multipath is not able to transport all flows, it
some flows based upon holding priority and informs the control plane preempts some flows based upon holding priority and informs the
of these preempted flows. To minimize impact on traffic, the control plane of these preempted flows. To minimize impact on
composite link MUST support soft preemption [RFC5712]. The network traffic, the Advanced Multipath MUST support soft preemption
operator SHOULD enable soft preemption. This action ensures the [RFC5712]. The network operator SHOULD enable soft preemption. This
remaining traffic is transported properly. FR#10 requires that the action ensures the remaining traffic is transported properly. FR#10
traffic be restored. FR#12 requires that any change be minimally requires that the traffic be restored. FR#12 requires that any
disruptive. These two requirements are interpreted to include change be minimally disruptive. These two requirements are
preemption among the types of changes that must be minimally interpreted to include preemption among the types of changes that
disruptive. must be minimally disruptive.
2.3. Composite Link in Data Plane 2.3. Advanced Multipath in Data Plane
The data plane must identify groups of flows. Flow identification is The data plane must identify groups of flows. Flow identification is
covered in Section 2.1. Having identified groups of flows the groups covered in Section 2.1. Having identified groups of flows the groups
must be placed on individual component links. This step following must be placed on individual component links. This step following
flow group identification is called traffic distribution or traffic flow group identification is called traffic distribution or traffic
placement. The two steps together are known as traffic balancing or placement. The two steps together are known as traffic balancing or
load balancing. load balancing.
Traffic distribution may be determined by or constrained by control Traffic distribution may be determined by or constrained by control
plane or management plane. Traffic distribution may be changed due plane or management plane. Traffic distribution may be changed due
to component link status change, subject to constraints imposed by to component link status change, subject to constraints imposed by
either the management plane or control plane. The distribution either the management plane or control plane. The distribution
function is local to the routers in which a composite link belongs to function is local to the routers in which an Advanced Multipath
and its implementation is not specified here. belongs to and its implementation is not specified here.
When performing traffic placement, a composite link does not When performing traffic placement, an Advanced Multipath does not
differentiate multicast traffic vs. unicast traffic. differentiate multicast traffic vs. unicast traffic.
In order to maintain scalability, existing data plane forwarding In order to maintain scalability, existing data plane forwarding
retains state associated with the top label only. Using UHP (UHP is retains state associated with the top label only. Using UHP (UHP is
the absence of the more common PHP), zero of more labels may be POPed the absence of the more common PHP), zero of more labels may be POPed
and packet and byte counters incremented prior to processing what and packet and byte counters incremented prior to processing what
becomes the top label after the POP operations are completed. Flow becomes the top label after the POP operations are completed. Flow
group identification may be a parallel step in the forwarding group identification may be a parallel step in the forwarding
process. Data plane forwarding makes use of the top label to select process. Data plane forwarding makes use of the top label to select
a composite link, or a group of components within a composite link or an Advanced Multipath, or a group of components within an Advanced
for the case where an LSP is pinned (see [RFC4201]), a specific Multipath or for the case where an LSP is pinned (see [RFC4201]), a
component link. For those LSP for which the LSP selects only the specific component link. For those LSP for which the LSP selects
composite link or a group of components within a composite link, the only the Advanced Multipath or a group of components within an
load balancing makes use of the set of component links selected based Advanced Multipath, the load balancing makes use of the set of
on the top label, and makes use of the flow group identification to component links selected based on the top label, and makes use of the
select among that group. flow group identification to select among that group.
The simplest traffic placement techniques uses a modulo operation The simplest traffic placement techniques uses a modulo operation
after computing a hash. This techniques has significant after computing a hash. This techniques has significant
disadvantages. The most common traffic placement techniques uses the disadvantages. The most common traffic placement techniques uses the
a flow group identification as an index into a table. The table a flow group identification as an index into a table. The table
provides an indirection. The number of bits of hash is constrained provides an indirection. The number of bits of hash is constrained
to keep table size small. While this is not the best technique, it to keep table size small. While this is not the best technique, it
is the most common. Better techniques exist but they are outside the is the most common. Better techniques exist but they are outside the
scope of this document and some are considered proprietary. scope of this document and some are considered proprietary.
Requirements to limit frequency of load balancing can be adhered to Requirements to limit frequency of load balancing can be adhered to
by keeping track of when a flow group was last moved and imposing a by keeping track of when a flow group was last moved and imposing a
minimum period before that flow group can be moved again. This is minimum period before that flow group can be moved again. This is
straightforward for a table approach. For other approaches it may be straightforward for a table approach. For other approaches it may be
less straightforward. less straightforward.
3. Architecture Tradeoffs 3. Architecture Tradeoffs
Scalability and stability are critical considerations in protocol Scalability and stability are critical considerations in protocol
design where protocols may be used in a large network such as today's design where protocols may be used in a large network such as today's
service provider networks. Composite Link is applicable to networks service provider networks. Advanced Multipath is applicable to
which are large enough to require that traffic be split over multiple networks which are large enough to require that traffic be split over
paths. Scalability is a major consideration for networks that reach multiple paths. Scalability is a major consideration for networks
a capacity large enough to require Composite Link. that reach a capacity large enough to require Advanced Multipath.
Some of the requirements of Composite Link could potentially have a Some of the requirements of Advanced Multipath could potentially have
negative impact on scalability. This section is about architectural a negative impact on scalability. This section is about
tradeoffs, many motivated by the need to maintain scalability and architectural tradeoffs, many motivated by the need to maintain
stability, a need which is reflected in scalability and stability, a need which is reflected in
[I-D.ietf-rtgwg-cl-requirement], specifically in DR#6 and DR#7. [I-D.ietf-rtgwg-cl-requirement], specifically in DR#6 and DR#7.
3.1. Scalability Motivations 3.1. Scalability Motivations
In the interest of scalability, information is aggregated in In the interest of scalability, information is aggregated in
situations where information about a large amount of network capacity situations where information about a large amount of network capacity
or a large amount of network demand provides is adequate to meet or a large amount of network demand provides is adequate to meet
requirements. Routing information is aggregated to reduce the amount requirements. Routing information is aggregated to reduce the amount
of information exchange related to routing and to simplify route of information exchange related to routing and to simplify route
computation (see Section 3.2). computation (see Section 3.2).
skipping to change at page 16, line 41 skipping to change at page 16, line 28
increases as order(N^2 log N) as the number of nodes increases (where increases as order(N^2 log N) as the number of nodes increases (where
"^" is the power of operator and "N^2" is read "N-squared"). In "^" is the power of operator and "N^2" is read "N-squared"). In
practice at the time of writing, this imposes a limit of a few practice at the time of writing, this imposes a limit of a few
hundred nodes in a full mesh of MPLS LSP before the computational hundred nodes in a full mesh of MPLS LSP before the computational
load is sufficient to result in unacceptable convergence times. load is sufficient to result in unacceptable convergence times.
Two solutions are applied to reduce the amount of RSVP-TE signaling. Two solutions are applied to reduce the amount of RSVP-TE signaling.
Both involve subdividing the MPLS domain into a core and a set of Both involve subdividing the MPLS domain into a core and a set of
regions. regions.
3.3.1. Reducing Signaling Load using LDP 3.3.1. Reducing Signaling Load using LDP MPTP
LDP can be used for edge-to-edge LSP, using RSVP-TE to carry the LDP LDP can be used for edge-to-edge LSP, using RSVP-TE to carry the LDP
intra-core traffic and also optionally also using RSVP-TE to carry intra-core traffic and also optionally also using RSVP-TE to carry
the LDP intra-region traffic within each region. LDP does not the LDP intra-region traffic within each region. LDP does not
support traffic engineering, but does support multipoint-to-point support traffic engineering, but does support multipoint-to-point
(MPTP) LSP, which require less signaling than edge-to-edge RSVP-TE (MPTP) LSP, which require less signaling than edge-to-edge RSVP-TE
point-to-point (PTP) LSP. A drawback of this approach is the point-to-point (PTP) LSP. A drawback of this approach is the
inability to use RSVP-TE protection (FRR or GMPLS protection) against inability to use RSVP-TE protection (FRR or GMPLS protection) against
failure of the border LSR sitting at a core/region boundary. failure of the border LSR sitting at a core/region boundary.
skipping to change at page 17, line 24 skipping to change at page 17, line 10
to the core in typically only two or three places on average. to the core in typically only two or three places on average.
Using hierarchy improves scaling but has two consequences. First, Using hierarchy improves scaling but has two consequences. First,
hierarchy effectively forces the use of platform label space. When a hierarchy effectively forces the use of platform label space. When a
containing LSP is rerouted, the labels assigned to the contained LSP containing LSP is rerouted, the labels assigned to the contained LSP
cannot be changed but may arrive on a different interface. Second, cannot be changed but may arrive on a different interface. Second,
hierarchy results in much larger LSP. These LSP today are larger hierarchy results in much larger LSP. These LSP today are larger
than any single component link and therefore force the use of the than any single component link and therefore force the use of the
all-ones component in link bundles. all-ones component in link bundles.
3.3.3. Using Both LDP and RSVP-TE Hierarchy 3.3.3. Using Both LDP MPTP and RSVP-TE Hierarchy
It is also possible to use both LDP and RSVP-TE hierarchy. MPLS It is also possible to use both LDP and RSVP-TE hierarchy. MPLS
networks with a very large number of nodes may benefit from the use networks with a very large number of nodes may benefit from the use
of both LDP and RSVP-TE hierarchy. The two techniques are certainly of both LDP and RSVP-TE hierarchy. The two techniques are certainly
not mutually exclusive. not mutually exclusive.
3.4. Reducing Forwarding State 3.4. Reducing Forwarding State
Both LDP and MPLS hierarchy have the benefit of reducing the amount Both LDP and MPLS hierarchy have the benefit of reducing the amount
of forwarding state. Using the example from Section 3.3, and using of forwarding state. Using the example from Section 3.3, and using
skipping to change at page 19, line 41 skipping to change at page 19, line 27
Section 4.2). Section 4.2).
4.1. Control Plane Challenges 4.1. Control Plane Challenges
Some of the control plane requirements are particularly challenging. Some of the control plane requirements are particularly challenging.
Handling large flows which aggregate smaller flows must be Handling large flows which aggregate smaller flows must be
accomplished with minimal impact on scalability. Potentially accomplished with minimal impact on scalability. Potentially
conflicting are requirements for jitter and requirements for conflicting are requirements for jitter and requirements for
stability. Potentially conflicting are the requirements for ingress stability. Potentially conflicting are the requirements for ingress
control of a large number of parameters, and the requirements for control of a large number of parameters, and the requirements for
local control needed to achieve traffic balance across a composite local control needed to achieve traffic balance across an Advanced
link. These challenges and potential solutions are discussed in the Multipath. These challenges and potential solutions are discussed in
following sections. the following sections.
4.1.1. Delay and Jitter Sensitive Routing 4.1.1. Delay and Jitter Sensitive Routing
Delay and jitter sensitive routing are called for in Delay and jitter sensitive routing are called for in
[I-D.ietf-rtgwg-cl-requirement] in requirements FR#2, FR#7, FR#8, [I-D.ietf-rtgwg-cl-requirement] in requirements FR#2, FR#7, FR#8,
FR#9, FR#15, FR#16, FR#17, FR#18. Requirement FR#17 is particularly FR#9, FR#15, FR#16, FR#17, FR#18. Requirement FR#17 is particularly
problematic, calling for constraints on jitter. problematic, calling for constraints on jitter.
A tradeoff exists between scaling benefits of aggregating A tradeoff exists between scaling benefits of aggregating
information, and potential benefits of using a finer granularity in information, and potential benefits of using a finer granularity in
delay reporting. To maintain the scaling benefit, measured link delay reporting. To maintain the scaling benefit, measured link
delay for any given composite link SHOULD be aggregated into a small delay for any given Advanced Multipath SHOULD be aggregated into a
number of delay ranges. IGP-TE extensions MUST be provided which small number of delay ranges. IGP-TE extensions MUST be provided
advertise the available capacities for each of the selected ranges. which advertise the available capacities for each of the selected
ranges.
For path selection of delay sensitive LSP, the ingress SHOULD bias For path selection of delay sensitive LSP, the ingress SHOULD bias
link metrics based on available capacity and select a low cost path link metrics based on available capacity and select a low cost path
which meets LSP total path delay criteria. To communicate the which meets LSP total path delay criteria. To communicate the
requirements of an LSP, the ERO MUST be extended to indicate the per requirements of an LSP, the ERO MUST be extended to indicate the per
link constraints. To communicate the type of resource used, the RRO link constraints. To communicate the type of resource used, the RRO
SHOULD be extended to carry an identification of the group that is SHOULD be extended to carry an identification of the group that is
used to carry the LSP at each link bundle hop. used to carry the LSP at each link bundle hop.
4.1.2. Local Control of Traffic Distribution 4.1.2. Local Control of Traffic Distribution
skipping to change at page 20, line 41 skipping to change at page 20, line 29
A given network deployment will have to consider this set of A given network deployment will have to consider this set of
conflicting requirements and make appropriate use of local control of conflicting requirements and make appropriate use of local control of
traffic placement and ingress control of traffic placement to best traffic placement and ingress control of traffic placement to best
meet network requirements. meet network requirements.
4.1.3. Path Symmetry Requirements 4.1.3. Path Symmetry Requirements
Requirement FR#21 in [I-D.ietf-rtgwg-cl-requirement] includes a Requirement FR#21 in [I-D.ietf-rtgwg-cl-requirement] includes a
provision to bind both directions of a bidirectional LSP to the same provision to bind both directions of a bidirectional LSP to the same
component. This is easily achieved if the LSP is directly signaled component. This is easily achieved if the LSP is directly signaled
across a composite link. This is not as easily achieved if a set of across an Advanced Multipath. This is not as easily achieved if a
LSP with this requirement are signaled over a large hierarchical LSP set of LSP with this requirement are signaled over a large
which is in turn carried over a composite link. The basis for load hierarchical LSP which is in turn carried over an Advanced Multipath.
distribution in such as case is the label stack. The labels in The basis for load distribution in such as case is the label stack.
either direction are completely independent. The labels in either direction are completely independent.
This could be accommodated if the ingress, egress, and all midpoints This could be accommodated if the ingress, egress, and all midpoints
of the hierarchical LSP make use of an entropy label in the of the hierarchical LSP make use of an entropy label in the
distribution, and the ingress use a fixed value per contained LSP in distribution, and the ingress use a fixed value per contained LSP in
the entropy label. A solution for this problem may add complexity the entropy label. A solution for this problem may add complexity
with very little benefit. There is little or no true benefit of with very little benefit. There is little or no true benefit of
using symmetrical paths rather than component links of identical using symmetrical paths rather than component links of identical
characteristics. characteristics.
Traffic symmetry and large LSP capacity are a second pair of Traffic symmetry and large LSP capacity are a second pair of
skipping to change at page 22, line 47 skipping to change at page 22, line 38
4.2. Data Plane Challenges 4.2. Data Plane Challenges
Flow identification is briefly discussed in Section 2.1. Traffic Flow identification is briefly discussed in Section 2.1. Traffic
distribution is briefly discussed in Section 2.3. This section distribution is briefly discussed in Section 2.3. This section
discusses issues specific to particular requirements specified in discusses issues specific to particular requirements specified in
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-requirement].
4.2.1. Very Large LSP 4.2.1. Very Large LSP
Very large LSP may exceed the capacity of any single component of a Very large LSP may exceed the capacity of any single component of an
composite link. In some cases contained LSP may exceed the capacity Advanced Multipath. In some cases contained LSP may exceed the
of any single component. These LSP may make use of the equivalent of capacity of any single component. These LSP may make use of the
the all-ones component of a link bundle, or may use a subset of equivalent of the all-ones component of a link bundle, or may use a
components which meet the LSP requirements. subset of components which meet the LSP requirements.
Very large LSP can be accommodated as long as they can be subdivided Very large LSP can be accommodated as long as they can be subdivided
(see Section 4.2.2). A very large LSP cannot have a requirement for (see Section 4.2.2). A very large LSP cannot have a requirement for
symmetric paths unless complex protocol extensions are proposed (see symmetric paths unless complex protocol extensions are proposed (see
Section 2.2 and Section 4.1.3). Section 2.2 and Section 4.1.3).
4.2.2. Very Large Microflows 4.2.2. Very Large Microflows
Within a very large LSP there may be very large microflows. A very Within a very large LSP there may be very large microflows. A very
large microflow is one which cannot be further subdivided and large microflow is one which cannot be further subdivided and
contributes a very large amount of capacity. Flows which cannot be contributes a very large amount of capacity. Flows which cannot be
subdivided must be no larger that the capacity of any single subdivided must be no larger that the capacity of any single
component link. component link.
Current signaling provides no way to specify the largest microflow Current signaling provides no way to specify the largest microflow
that a can be supported on a given link bundle in routing that a can be supported on a given link bundle in routing
advertisements. Extensions which address this are discussed in advertisements. Extensions which address this are discussed in
Section 6.4. Absent extensions of this type, traffic containing Section 6.4. Absent extensions of this type, traffic containing
microflows that are too large for a given composite link may be microflows that are too large for a given Advanced Multipath may be
present. There is no data plane solution for this problem that would present. There is no data plane solution for this problem that would
not require reordering traffic at the composite link egress. not require reordering traffic at the Advanced Multipath egress.
Some techniques are susceptible to statistical collisions where an Some techniques are susceptible to statistical collisions where an
algorithm to distribute traffic is unable to disambiguate traffic algorithm to distribute traffic is unable to disambiguate traffic
among two or more very large microflow where their sum is in excess among two or more very large microflow where their sum is in excess
of the capacity of any single component. Hash based algorithms which of the capacity of any single component. Hash based algorithms which
use too small a hash space are particularly susceptible and require a use too small a hash space are particularly susceptible and require a
change in hash seed in the event that this were to occur. A change change in hash seed in the event that this were to occur. A change
in hash seed is highly disruptive, causing traffic reordering among in hash seed is highly disruptive, causing traffic reordering among
all traffic flows over which the hash function is applied. all traffic flows over which the hash function is applied.
skipping to change at page 24, line 13 skipping to change at page 24, line 8
as native IP. There is no architectural guarantee of this, it is as native IP. There is no architectural guarantee of this, it is
just how network operators have made use of the protocols. just how network operators have made use of the protocols.
[I-D.ietf-rtgwg-cl-requirement] requires that native IP and native [I-D.ietf-rtgwg-cl-requirement] requires that native IP and native
LDP be accommodated (DR#2 and DR#3). In some networks, a subset of LDP be accommodated (DR#2 and DR#3). In some networks, a subset of
services may be carried as native IP or carried as native LDP. Today services may be carried as native IP or carried as native LDP. Today
this may be accommodated by the network operator estimating the this may be accommodated by the network operator estimating the
contribution of IP and LDP and configuring a lower set of available contribution of IP and LDP and configuring a lower set of available
bandwidth figures on the RSVP-TE advertisements. bandwidth figures on the RSVP-TE advertisements.
The only improvement that Composite Link can offer is that of The only improvement that Advanced Multipath can offer is that of
measuring the IP and LDP traffic levels and automatically reducing measuring the IP and LDP traffic levels and automatically reducing
the available bandwidth figures on the RSVP-TE advertisements. The the available bandwidth figures on the RSVP-TE advertisements. The
measurements would have to be filtered. This is similar to a feature measurements would have to be filtered. This is similar to a feature
in existing LSR, commonly known as "autobandwidth" with a key in existing LSR, commonly known as "autobandwidth" with a key
difference. In the "autobandwidth" feature, the bandwidth request of difference. In the "autobandwidth" feature, the bandwidth request of
an RSVP-TE signaled LSP is adjusted in response to traffic an RSVP-TE signaled LSP is adjusted in response to traffic
measurements. In this case the IP or LDP traffic measurements are measurements. In this case the IP or LDP traffic measurements are
used to reduce the link bandwidth directly, without first used to reduce the link bandwidth directly, without first
encapsulating in an RSVP-TE LSP. encapsulating in an RSVP-TE LSP.
This may be a subtle and perhaps even a meaningless distinction if This may be a subtle and perhaps even a meaningless distinction if
Composite Link is used to form a Sub-Path Maintenance Element (SPME). Advanced Multipath is used to form a Sub-Path Maintenance Element
A SPME is in practice essentially an unsignaled single hop LSP with (SPME). A SPME is in practice essentially an unsignaled single hop
PHP enabled [RFC5921]. A Composite Link SPME looks very much like LSP with PHP enabled [RFC5921]. An Advanced Multipath SPME looks
classic multipath, where there is no signaling, only management plane very much like classic multipath, where there is no signaling, only
configuration creating the multipath entity (of which Ethernet Link management plane configuration creating the multipath entity (of
Aggregation is a subset). which Ethernet Link Aggregation is a subset).
4.2.5. IP and LDP Limitations 4.2.5. IP and LDP Limitations
IP does not offer traffic engineering. LDP cannot be extended to IP does not offer traffic engineering. LDP cannot be extended to
offer traffic engineering [RFC3468]. Therefore there is no traffic offer traffic engineering [RFC3468]. Therefore there is no traffic
engineered fallback to an alternate path for IP and LDP traffic if engineered fallback to an alternate path for IP and LDP traffic if
resources are not adequate for the IP and/or LDP traffic alone on a resources are not adequate for the IP and/or LDP traffic alone on a
given link in the primary path. The only option for IP and LDP would given link in the primary path. The only option for IP and LDP would
be to declare the link down. Declaring a link down due to resource be to declare the link down. Declaring a link down due to resource
exhaustion would reduce traffic to zero and eliminate the resource exhaustion would reduce traffic to zero and eliminate the resource
skipping to change at page 25, line 48 skipping to change at page 25, line 43
[RFC6107] extends the procedures for hierarchical LSP but also [RFC6107] extends the procedures for hierarchical LSP but also
extends link bundles. An LSP can be explicitly signaled to indicate extends link bundles. An LSP can be explicitly signaled to indicate
that it is an LSP to be used as a component of a link bundle. Prior that it is an LSP to be used as a component of a link bundle. Prior
to that the common practice was to simply not advertise the component to that the common practice was to simply not advertise the component
link LSP into the IGP, since only the ingress and egress of the link link LSP into the IGP, since only the ingress and egress of the link
bundle needed to be aware of their existence, which they would be bundle needed to be aware of their existence, which they would be
aware of due to the RSVP-TE signaling used in setting up the aware of due to the RSVP-TE signaling used in setting up the
component LSP. component LSP.
While link bundling can be the basis for composite links, a While link bundling can be the basis for Advanced Multipath, a
significant number of small extension needs to be added. significant number of small extension needs to be added.
1. To support link bundles of heterogeneous links, a means of 1. To support link bundles of heterogeneous links, a means of
advertising the capacity available within a group of homogeneous advertising the capacity available within a group of homogeneous
links needs to be provided. links needs to be provided.
2. Attributes need to be defined to support the following parameters 2. Attributes need to be defined to support the following parameters
for the link bundle or for a group of homogeneous links. for the link bundle or for a group of homogeneous links.
A. delay range A. delay range
skipping to change at page 26, line 35 skipping to change at page 26, line 31
3. For each of the prior extended attributes, the constraint based 3. For each of the prior extended attributes, the constraint based
routing path selection needs to be extended to reflect new routing path selection needs to be extended to reflect new
constraints based on the extended attributes. constraints based on the extended attributes.
4. For each of the prior extended attributes, LSP admission control 4. For each of the prior extended attributes, LSP admission control
needs to be extended to reflect new constraints based on the needs to be extended to reflect new constraints based on the
extended attributes. extended attributes.
5. Dynamic load balance must be provided for flows within a given 5. Dynamic load balance must be provided for flows within a given
set of links with common attributes such that NPO are not set of links with common attributes such that Performance
violated including frequency of load balance adjustment for any Objectives are not violated including frequency of load balance
given flow. adjustment for any given flow.
5.2. Classic Multipath 5.2. Classic Multipath
Classic multipath is described in [I-D.ietf-rtgwg-cl-use-cases]. Classic multipath is described in [I-D.ietf-rtgwg-cl-use-cases].
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. The most common current implementation and deployment of multipath. The most common current
practice makes use of a hash on the MPLS label stack and if IPv4 or practice makes 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 IPv6 are indicated under the label stack, makes use of the IP source
and destination addresses [RFC4385] [RFC4928]. and destination addresses [RFC4385] [RFC4928].
Classic multipath provides a highly scalable means of load balancing. Classic multipath provides a highly scalable means of load balancing.
Dynamic multipath has proven value in assuring an even loading on Dynamic multipath has proven value in assuring an even loading on
component link and an ability to adapt to change in offered load that component link and an ability to adapt to change in offered load that
occurs over periods of hundreds of milliseconds or more. Classic occurs over periods of hundreds of milliseconds or more. Classic
multipath scalability is due to the ability to effectively work with multipath scalability is due to the ability to effectively work with
an extremely large number of flows (IP host pairs) using relatively an extremely large number of flows (IP host pairs) using relatively
little resources (a data structure accessed using a hash result as a little resources (a data structure accessed using a hash result as a
key or using ranges of hash results). key or using ranges of hash results).
Classic multipath meets a small subset of Composite Link Classic multipath meets a small subset of Advanced Multipath
requirements. Due to scalability of the approach, classic multipath requirements. Due to scalability of the approach, classic multipath
seems to be an excellent candidate for extension to meet the full set seems to be an excellent candidate for extension to meet the full set
of Composite Link forwarding requirements. of Advanced Multipath forwarding requirements.
Additional detail can be found in [I-D.ietf-rtgwg-cl-use-cases]. Additional detail can be found in [I-D.ietf-rtgwg-cl-use-cases].
6. Mechanisms Proposed in Other Documents 6. Mechanisms Proposed in Other Documents
A number of documents which at the time of writing are works in A number of documents which at the time of writing are works in
progress address parts of the requirements of Composite Link, or progress address parts of the requirements of Advanced Multipath, or
assist in making some of the goals achievable. assist in making some of the goals achievable.
6.1. Loss and Delay Measurement 6.1. Loss and Delay Measurement
Procedures for measuring loss and delay are provided in [RFC6374]. Procedures for measuring loss and delay are provided in [RFC6374].
These are OAM based measurements. This work could be the basis of These are OAM based measurements. This work could be the basis of
delay measurements and delay variation measurement used for metrics delay measurements and delay variation measurement used for metrics
called for in [I-D.ietf-rtgwg-cl-requirement]. called for in [I-D.ietf-rtgwg-cl-requirement].
Currently there are three documents that address delay and delay Currently there are three documents that address delay and delay
skipping to change at page 28, line 23 skipping to change at page 28, line 18
6.2. Link Bundle Extensions 6.2. Link Bundle Extensions
A set of extension are needed to indicate a group of component links A set of extension are needed to indicate a group of component links
in the ERO or RRO, where the group is given an interface in the ERO or RRO, where the group is given an interface
identification like the bundle itself. The extensions could also be identification like the bundle itself. The extensions could also be
further extended to support specification of the all-ones component further extended to support specification of the all-ones component
link in the ERO or RRO. link in the ERO or RRO.
[I-D.ospf-cc-stlv] provides a baseline draft for extending link [I-D.ospf-cc-stlv] provides a baseline draft for extending link
bundling to advertise components. A new component TLV (C-TLV) is bundling to advertise components. A new component TLV (C-TLV) is
proposed, which must reference a Composite Link Link TLV. proposed, which must reference an Advanced Multipath Link TLV.
[I-D.ospf-cc-stlv] is intended for the OSPF WG and submitted for the [I-D.ospf-cc-stlv] is intended for the OSPF WG and submitted for the
"Experimental" track. The 00 version expired in February 2012. A "Experimental" track. The 00 version expired in February 2012. A
replacement is expected that will be submitted for consideration on replacement is expected that will be submitted for consideration on
the standards track. the standards track.
6.3. Pseudowire Flow and MPLS Entropy Labels 6.3. Pseudowire Flow and MPLS Entropy Labels
Two documents provide a means to add entropy for the purpose of Two documents provide a means to add entropy for the purpose of
improving load balance. MPLS encapsulation can bury information that improving load balance. MPLS encapsulation can bury information that
is needed to identify microflows. These two documents allow a is needed to identify microflows. These two documents allow a
skipping to change at page 29, line 47 skipping to change at page 29, line 42
extensions are then grouped by protocol affected as a convenience to extensions are then grouped by protocol affected as a convenience to
implementors (see (see Section 7.3). implementors (see (see Section 7.3).
7.1. Brief Review of Requirements 7.1. Brief Review of Requirements
The following list provides a categorization of requirements The following list provides a categorization of requirements
specified in [I-D.ietf-rtgwg-cl-requirement] along with a short specified in [I-D.ietf-rtgwg-cl-requirement] along with a short
phrase indication what topic the requirement covers. phrase indication what topic the requirement covers.
routing information aggregation routing information aggregation
FR#1 (routing summarization), FR#20 (composite link may be a FR#1 (routing summarization), FR#20 (Advanced Multipath may be a
component of another composite link) component of another Advanced Multipath)
restoration speed restoration speed
FR#2 (restoration speed meeting NPO), FR#12 (minimally disruptive FR#2 (restoration speed meeting performance objectives), FR#12
load rebalance), DR#6 (fast convergence), DR#7 (fast worst case (minimally disruptive load rebalance), DR#6 (fast convergence),
failure convergence) DR#7 (fast worst case failure convergence)
load distribution, stability, minimal disruption load distribution, stability, minimal disruption
FR#3 (automatic load distribution), FR#5 (must not oscillate), FR#3 (automatic load distribution), FR#5 (must not oscillate),
FR#11 (dynamic placement of flows), FR#12 (minimally disruptive FR#11 (dynamic placement of flows), FR#12 (minimally disruptive
load rebalance), FR#13 (bounded rearrangement frequency), FR#18 load rebalance), FR#13 (bounded rearrangement frequency), FR#18
(flow placement must satisfy NPO), FR#19 (flow identification (flow placement must satisfy performance objectives), FR#19 (flow
finer than per top level LSP), MR#6 (operator initiated flow identification finer than per top level LSP), MR#6 (operator
rebalance) initiated flow rebalance)
backward compatibility and migration backward compatibility and migration
FR#4 (smooth incremental deployment), FR#6 (management and FR#4 (smooth incremental deployment), FR#6 (management and
diagnostics must continue to function), DR#1 (extend existing diagnostics must continue to function), DR#1 (extend existing
protocols), DR#2 (extend LDP, no LDP TE) protocols), DR#2 (extend LDP, no LDP TE)
delay and delay variation delay and delay variation
FR#7 (expose lower layer measured delay), FR#8 (precision of FR#7 (expose lower layer measured delay), FR#8 (precision of
latency reporting), FR#9 (limit latency on per LSP basis), FR#15 latency reporting), FR#9 (limit latency on per LSP basis), FR#15
(minimum delay path), FR#16 (bounded delay path), FR#17 (bounded (minimum delay path), FR#16 (bounded delay path), FR#17 (bounded
skipping to change at page 36, line 19 skipping to change at page 36, line 19
information. This information can be carried in the PW LDP signaling information. This information can be carried in the PW LDP signaling
[RFC3985] and the the PW requirements could then be used in a [RFC3985] and the the PW requirements could then be used in a
containing LSP. containing LSP.
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 is the "admission control, preemption, traffic listed in Section 7.1 is the "admission control, preemption, traffic
engineering" set of requirements. The "backward compatibility and engineering" set of requirements. The "backward compatibility and
migration" and "general network management" requirements must also be migration" and "general network management" requirements must also be
considered. considered.
7.2.14. Multi-Domain Composite Link 7.2.14. Multi-Domain Advanced Multipath
DR#5 calls for Composite Link to span multiple network topologies. DR#5 calls for Advanced Multipath to span multiple network
Component LSP may already span multiple network topologies, though topologies. Component LSP may already span multiple network
most often in practice these are LDP signaled. Component LSP which topologies, though most often in practice these are LDP signaled.
are RSVP-TE signaled may also span multiple network topologies using Component LSP which are RSVP-TE signaled may also span multiple
at least three existing methods (per domain [RFC5152], BRPC network topologies using at least three existing methods (per domain
[RFC5441], PCE [RFC4655]). When such component links are combined in [RFC5152], BRPC [RFC5441], PCE [RFC4655]). When such component links
a Composite Link, the Composite Link spans multiple network are combined in an Advanced Multipath, the Advanced Multipath spans
topologies. It is not clear in which document this needs to be multiple network topologies. It is not clear in which document this
described or whether this description in the framework is sufficient. needs to be described or whether this description in the framework is
The authors and/or the WG may need to discuss this. DR#5 mandates sufficient. The authors and/or the WG may need to discuss this.
that IGP-TE extension cannot be used. This would disallow the use of DR#5 mandates that IGP-TE extension cannot be used. This would
[RFC5316] or [RFC5392] in conjunction with [RFC5151]. disallow the use of [RFC5316] or [RFC5392] in conjunction with
[RFC5151].
The primary focus of this document, among the sets of requirements The primary focus of this document, among the sets of requirements
listed in Section 7.1 are "single vs multiple domain" and "admission listed in Section 7.1 are "single vs multiple domain" and "admission
control, preemption, traffic engineering". The "routing information control, preemption, traffic engineering". The "routing information
aggregation" and "load distribution, stability, minimal disruption" aggregation" and "load distribution, stability, minimal disruption"
requirements need attention due to their use of the IGP in single requirements need attention due to their use of the IGP in single
domain Composite Link. Other requirements such as "delay and delay domain Advanced Multipath. Other requirements such as "delay and
variation", can more easily be accommodated by carrying metrics delay variation", can more easily be accommodated by carrying metrics
within BGP. The "path determination, connectivity verification" within BGP. The "path determination, connectivity verification"
requirements need attention due to requirements to restrict requirements need attention due to requirements to restrict
disclosure of topology information across domains in multi-domain disclosure of topology information across domains in multi-domain
deployments. The "backward compatibility and migration" and "general deployments. The "backward compatibility and migration" and "general
network management" requirements must also be considered. network management" requirements must also be considered.
7.3. Framework Requirement Coverage by Protocol 7.3. Framework Requirement Coverage by Protocol
As an aid to implementors, this section summarizes requirement As an aid to implementors, this section summarizes requirement
coverage listed in Section 7.2 by protocol or LSR functionality coverage listed in Section 7.2 by protocol or LSR functionality
skipping to change at page 40, line 23 skipping to change at page 40, line 23
February 2013. February 2013.
[I-D.ietf-ospf-te-metric-extensions] [I-D.ietf-ospf-te-metric-extensions]
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", draft-ietf-ospf-te-metric-extensions-04 (work Extensions", draft-ietf-ospf-te-metric-extensions-04 (work
in progress), June 2013. in progress), June 2013.
[I-D.ietf-rtgwg-cl-requirement] [I-D.ietf-rtgwg-cl-requirement]
Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
Yong, "Requirements for MPLS Over a Composite Link", Yong, "Requirements for Advanced Multipath in MPLS
draft-ietf-rtgwg-cl-requirement-08 (work in progress), Networks", draft-ietf-rtgwg-cl-requirement-11 (work in
August 2012. progress), July 2013.
[I-D.ietf-rtgwg-cl-use-cases] [I-D.ietf-rtgwg-cl-use-cases]
Ning, S., Malis, A., McDysan, D., Yong, L., and C. Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Composite Link Use Cases and Design Villamizar, "Advannced Multipath Use Cases and Design
Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in Considerations", draft-ietf-rtgwg-cl-use-cases-04 (work in
progress), August 2012. progress), July 2013.
[I-D.kompella-mpls-rsvp-ecmp]
Kompella, K., "Multi-path Label Switched Paths Signaled
Using RSVP-TE", draft-kompella-mpls-rsvp-ecmp-03 (work in
progress), May 2013.
[I-D.ospf-cc-stlv] [I-D.ospf-cc-stlv]
Osborne, E., "Component and Composite Link Membership in Osborne, E., "Component and Composite Link Membership in
OSPF", draft-ospf-cc-stlv-00 (work in progress), OSPF", draft-ospf-cc-stlv-00 (work in progress),
August 2011. August 2011.
[I-D.previdi-isis-te-metric-extensions] [I-D.previdi-isis-te-metric-extensions]
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
A., and C. Filsfils, "IS-IS Traffic Engineering (TE) A., and C. Filsfils, "IS-IS Traffic Engineering (TE)
Metric Extensions", Metric Extensions",
skipping to change at page 42, line 46 skipping to change at page 42, line 41
So Ning So Ning
Tata Communications Tata Communications
Email: ning.so@tatacommunications.com Email: ning.so@tatacommunications.com
Dave McDysan Dave McDysan
Verizon Verizon
22001 Loudoun County PKWY 22001 Loudoun County PKWY
Ashburn, VA 20147 Ashburn, VA 20147
USA
Email: dave.mcdysan@verizon.com Email: dave.mcdysan@verizon.com
Eric Osborne Eric Osborne
Cisco Cisco
Email: eosborne@cisco.com Email: eosborne@cisco.com
Lucy Yong Lucy Yong
Huawei USA Huawei USA
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75025 Plano, TX 75025
USA
Phone: +1 469-277-5837 Phone: +1 469-277-5837
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
Curtis Villamizar Curtis Villamizar
Outer Cape Cod Network Consulting Outer Cape Cod Network Consulting
Email: curtis@occnc.com Email: curtis@occnc.com
 End of changes. 88 change blocks. 
240 lines changed or deleted 230 lines changed or added

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