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