--- 1/draft-ietf-rtgwg-cl-framework-02.txt 2013-06-15 18:14:33.788045126 +0100 +++ 2/draft-ietf-rtgwg-cl-framework-03.txt 2013-06-15 18:14:33.876047310 +0100 @@ -1,26 +1,26 @@ RTGWG S. Ning Internet-Draft Tata Communications Intended status: Informational D. McDysan -Expires: April 22, 2013 Verizon +Expires: December 17, 2013 Verizon E. Osborne Cisco L. Yong Huawei USA C. Villamizar Outer Cape Cod Network Consulting - October 19, 2012 + June 15, 2013 Composite Link Framework in Multi Protocol Label Switching (MPLS) - draft-ietf-rtgwg-cl-framework-02 + draft-ietf-rtgwg-cl-framework-03 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 @@ -34,25 +34,25 @@ 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 April 22, 2013. + This Internet-Draft will expire on December 17, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -83,62 +83,62 @@ 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 4.2.3. Traffic Ordering Constraints . . . . . . . . . . . . . 23 - 4.2.4. Accounting for IP and LDP Traffic . . . . . . . . . . 24 + 4.2.4. Accounting for IP and LDP Traffic . . . . . . . . . . 23 4.2.5. IP and LDP Limitations . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . 30 - 7.1. Brief Review of Requirements . . . . . . . . . . . . . . . 30 + 7. Required Protocol Extensions and Mechanisms . . . . . . . . . 29 + 7.1. Brief Review of Requirements . . . . . . . . . . . . . . . 29 7.2. Proposed Document Coverage . . . . . . . . . . . . . . . . 31 7.2.1. Component Link Grouping . . . . . . . . . . . . . . . 31 - 7.2.2. Delay and Jitter Extensions . . . . . . . . . . . . . 32 + 7.2.2. Delay and Jitter Extensions . . . . . . . . . . . . . 31 7.2.3. Path Selection and Admission Control . . . . . . . . . 32 - 7.2.4. Dynamic Multipath Balance . . . . . . . . . . . . . . 33 + 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 . . . . . . . . . . . . . 34 + 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 . . . . . . . . . . . . . . . . . . . . 36 + 7.2.12. LDP Extensions . . . . . . . . . . . . . . . . . . . . 35 7.2.13. Pseudowire Extensions . . . . . . . . . . . . . . . . 36 7.2.14. Multi-Domain Composite Link . . . . . . . . . . . . . 36 - 7.3. Framework Requirement Coverage by Protocol . . . . . . . . 37 + 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 . . . . . . . 38 - 7.3.7. Flow Identification and Traffic Balance . . . . . . . 38 + 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 . . . . . . . . . . . . . . . . . . 40 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 + 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 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 @@ -245,39 +245,34 @@ 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. 5. The following referenced drafts have expired: - A. [I-D.kompella-mpls-rsvp-ecmp] - - B. [I-D.wang-ccamp-latency-te-metric] - - C. [I-D.giacalone-ospf-te-express-path] - - D. [I-D.ietf-mpls-explicit-resource-control-bundle] + A. [I-D.ospf-cc-stlv] - E. [I-D.ospf-cc-stlv] + B. [I-D.villamizar-mpls-multipath-extn] - 6. Section 6.1 contains a note to co-authors suggesting that - reference to [I-D.giacalone-ospf-te-express-path] be dropped. - The co-authors and WG should consider this, and if there is - agreement, drop it. + 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. - 7. Clarification of what we intend to do with Multi-Domain Composite + 6. Clarification of what we intend to do with Multi-Domain Composite Link is needed in Section 7.2.14. - 8. 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 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 @@ -347,22 +342,22 @@ 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, 4. 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 [I-D.ietf-mpls-entropy-label] - identified by an MPLS entropy label, + 5. 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 source and destination pair, 7. 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 identification is PW payload type specific, such as Ethernet MAC @@ -400,27 +394,27 @@ The common practices described in [RFC2991] and [RFC2992] were extended to include the MPLS label stack and the common practice of looking at IP addresses within the MPLS payload. These extended practices require that pseudowires use a PWE3 Control Word and are described in [RFC4385] and [RFC4928]. Additional detail on current multipath practices can be found in the appendices of [I-D.ietf-rtgwg-cl-use-cases]. Using only the top label supports too coarse a traffic balance. - Prior to MPLS Entropy Label [I-D.ietf-mpls-entropy-label] 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 + 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. 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. @@ -428,27 +422,26 @@ 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 [I-D.ietf-mpls-entropy-label] 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. + 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.2. Composite Link in Control Plane 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 @@ -1082,22 +1075,22 @@ 4.2.3. Traffic Ordering Constraints Some LSP have strict traffic ordering constraints. Most notable among these are MPLS-TP LSP. In the absence of aggregation into hierarchical LSP, those LSP with strict traffic ordering constraints can be placed on individual component links if there is a means of identifying which LSP have such a constraint. If LSP with strict traffic ordering constraints are aggregated in hierarchical LSP, the hierarchical LSP capacity may exceed the capacity of any single component link. In such a case the load balancing may be constrained - through the use of an entropy label [I-D.ietf-mpls-entropy-label]. - This and related issues are discussed further in Section 6.4. + through the use of an entropy label [RFC6790]. This and related + issues are discussed further in Section 6.4. 4.2.4. Accounting for IP and LDP Traffic Networks which carry RSVP-TE signaled MPLS traffic generally carry low volumes of native IP traffic, often only carrying control traffic 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 @@ -1258,106 +1251,92 @@ progress address parts of the requirements of Composite Link, 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 two additional Internet-Drafts that address delay - and delay variation metrics. + Currently there are three documents that address delay and delay + variation metrics. - draft-wang-ccamp-latency-te-metric - [I-D.wang-ccamp-latency-te-metric] is designed specifically to - meet this requirement. OSPF-TE and ISIS-TE extensions are - defined to indicate link delay and delay variance. The RSVP-TE - ERO is extended to include service level requirements. A latency - accumulation object is defined to provide a means of verification - of the service level requirements. This draft is intended to - proceed in the CCAMP WG. It is currently an individual - submission which has expired. + draft-ietf-ospf-te-metric-extensions + [I-D.ietf-ospf-te-metric-extensions] provides a set of OSPF-TE + extension to support delay, jitter, and loss. Stability is not + adequately addressed and some minor issues remain. - draft-giacalone-ospf-te-express-path - [I-D.giacalone-ospf-te-express-path] proposes to extend OSPF-TE - only. Extensions support delay, delay variance, loss, residual - bandwidth, and available bandwidth. No extensions to RSVP-TE are - proposed. This draft is intended to proceed in the CCAMP WG. It - is currently and individual submission which has expired. + I-D.previdi-isis-te-metric-extensions + [I-D.previdi-isis-te-metric-extensions] provides the set of + extensions for ISIS that [I-D.ietf-ospf-te-metric-extensions] + provides for OSPF. This draft mirrors + [I-D.ietf-ospf-te-metric-extensions] sometimes lagging for a + brief period when the OSPF version is updated. - A possible course of action may be to combine these two drafts. The - delay variance, loss, residual bandwidth, and available bandwidth + I-D.atlas-mpls-te-express-path + [I-D.atlas-mpls-te-express-path] provides information on the use + of OSPF and ISIS extensions defined in + [I-D.ietf-ospf-te-metric-extensions] and + [I-D.previdi-isis-te-metric-extensions] and a modified CSPF path + selection to meet LSP performance criteria such as minimal delay + paths or bounded delay paths. + + Delay variance, loss, residual bandwidth, and available bandwidth extensions are particular prone to network instability. The question as to whether queuing delay and delay variation should be considered, and if so for which diffserv Per-Hop Service Class (PSC) is not - addressed. - - Note to co-authors: The ccamp-latency-te-metric draft refers to - [I-D.ietf-rtgwg-cl-requirement] and is well matched to those - requirements, including stability. The ospf-te-express-path draft - refers to the "Alto Protocol" (draft-ietf-alto-protocol) and - therefore may not be intended for RSVP-TE use. The authors of the - two drafts may be able to resolve this. It may be best to drop ospf- - te-express-path from this framework document. + adequately addressed in the current versions of these drafts. These + drafts are actively being discussed and updated and remaining issues + are expected to be resolved. 6.2. Link Bundle Extensions - A set of link bundling extensions are defined in - [I-D.ietf-mpls-explicit-resource-control-bundle]. This document - provides extensions to the ERO and RRO to explicitly control the - labels and resources within a bundle used by an LSP. - - The extensions in this document could be further extended to support - indicating 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.ietf-mpls-explicit-resource-control-bundle] does not provide a - means to advertise the link bundle components. It is not certain how - the ingress LSR would determine the set of link bundle component - links available for a given link bundle. + 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. [I-D.ospf-cc-stlv] is intended for the OSPF WG and submitted for the - "Experimental" track. The 00 version expired in February 2012. + "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 pseudowire ingress and LSP ingress respectively to add a label solely for the purpose of providing a finer granularity of microflow groups. [RFC6391] allows pseudowires which carry a large volume of traffic, where microflows can be identified to be load balanced across multiple members of an Ethernet LAG or an MPLS link bundle. This is accomplished by adding a flow label below the pseudowire label in the MPLS label stack. For this to be effective the link bundle load balance must make use of the label stack up to and including this flow label. - [I-D.ietf-mpls-entropy-label] provides a means for a LER to put an - additional label known as an entropy label on the MPLS label stack. - Only the LER can add the entropy label. The LER of a PSC LSP would - have to add a entropy label for contained LSPs for which it is a - midpoint LSR. LSP packet ordering requirements can be passed to an - LSP midpoint using the extensions in - [I-D.villamizar-mpls-tp-multipath-te-extn]. + [RFC6790] provides a means for a LER to put an additional label known + as an entropy label on the MPLS label stack. Only the LER can add + the entropy label. The LER of a PSC LSP would have to add a entropy + label for contained LSPs for which it is a midpoint LSR. Core LSR acting as LER for aggregated LSP can add entropy labels based on deep packet inspection and place an entropy label indicator (ELI) and entropy label (EL) just below the label being acted on. + This would be helpful in situations where the label stack depth to which load distribution can operate is limited by implementation or is limited for other reasons such as carrying both MPLS-TP and MPLS with entropy labels within the same hierarchical LSP. 6.4. Multipath Extensions The multipath extensions drafts address the issue of accommodating LSP which have strict packet ordering constraints in a network containing multipath. MPLS-TP has become the one important instance @@ -1357,35 +1336,28 @@ with entropy labels within the same hierarchical LSP. 6.4. Multipath Extensions The multipath extensions drafts address the issue of accommodating LSP which have strict packet ordering constraints in a network containing multipath. MPLS-TP has become the one important instance of LSP with strict packet ordering constraints and has driven this work. - [I-D.villamizar-mpls-tp-multipath] proposed to use MPLS Entropy Label - [I-D.ietf-mpls-entropy-label] to allow MPLS-TP to be carried within - MPLS LSP that make use of multipath. Limitations of this approach in - the absence of protocol extensions is discussed. - - [I-D.villamizar-mpls-tp-multipath-te-extn] provides protocol - extensions needed to overcome the limitations in the absence of - protocol extensions is discussed in - [I-D.villamizar-mpls-tp-multipath]. + [I-D.ietf-mpls-multipath-use] proposed to use MPLS Entropy Label + [RFC6790] to allow MPLS-TP to be carried within MPLS LSP that make + use of multipath. Limitations of this approach in the absence of + protocol extensions is discussed. - Other issues pertaining to multipath are also addressed in - [I-D.villamizar-mpls-tp-multipath-te-extn]. Means to advertise the - largest microflow supportable are defined. Means to indicate the - largest expected microflow within an LSP are defined. Issues related - to hierarchy are addressed. + [I-D.villamizar-mpls-multipath-extn] provides protocol extensions + needed to overcome the limitations in the absence of protocol + extensions is discussed in [I-D.ietf-mpls-multipath-use]. 7. Required Protocol Extensions and Mechanisms Prior sections have reviewed key characteristics, architecture tradeoffs, new challenges, existing mechanisms, and relevant mechanisms proposed in existing new documents. This section first summarizes and groups requirements specified in [I-D.ietf-rtgwg-cl-requirement] (see Section 7.1). A set of documents coverage groupings are proposed with existing works-in- @@ -1490,22 +1462,28 @@ listed in Section 7.1 is the "routing information aggregation" set of requirements. The "restoration speed", "backward compatibility and migration", and "general network management" requirements must also be considered. 7.2.2. Delay and Jitter Extensions A extension is needed in the IGP-TE advertisement to support delay and delay variation for links, link bundles, and forwarding adjacencies. Whatever mechanism is described must take precautions - that insure that route oscillations cannot occur. - [I-D.wang-ccamp-latency-te-metric] may be a good starting point. + that insure that route oscillations cannot occur. The following set + of drafts address this. + + 1. [I-D.ietf-ospf-te-metric-extensions] + + 2. [I-D.previdi-isis-te-metric-extensions] + + 3. [I-D.atlas-mpls-te-express-path] The primary focus of this document, among the sets of requirements listed in Section 7.1 is the "delay and delay variation" set of requirements. The "restoration speed", "backward compatibility and migration", and "general network management" requirements must also be considered. 7.2.3. Path Selection and Admission Control Path selection and admission control changes must be documented in @@ -1554,43 +1532,41 @@ The primary focus of this document, among the sets of requirements listed in Section 7.1 is the "load distribution, stability, minimal disruption" set of requirements. The "path determination, connectivity verification" must also be considered. The "backward compatibility and migration" and "general network management" requirements must also be considered. 7.2.6. Inter-Layer Communication Lower layer to upper layer communication called for in FR#7 and - FR#20. This is addressed for a subset of parameters related to - packet ordering in [I-D.villamizar-mpls-tp-multipath] where layers - are MPLS. Remaining parameters, specifically delay and delay - variation, need to be addressed. Passing information from a lower - non-MPLS layer to an MPLS layer needs to be addressed, though this - may largely be generic advice encouraging a coupling of MPLS to lower - layer management plane or control plane interfaces. This topic can - be addressed in each document proposing a protocol extension, where + FR#20. Specific parameters, specifically delay and delay variation, + need to be addressed. Passing information from a lower non-MPLS + layer to an MPLS layer needs to be addressed, though this may largely + be generic advice encouraging a coupling of MPLS to lower layer + management plane or control plane interfaces. This topic can be + addressed in each document proposing a protocol extension, where applicable. The primary focus of this document, among the sets of requirements listed in Section 7.1 is the "restoration speed" set of requirements. The "backward compatibility and migration" and "general network management" requirements must also be considered. 7.2.7. Packet Ordering Requirements A document is needed to define extensions supporting various packet ordering requirements, ranging from requirements to preserve microflow ordering only, to requirements to preserve full LSP ordering (as in MPLS-TP). This is covered by - [I-D.villamizar-mpls-tp-multipath] and - [I-D.villamizar-mpls-tp-multipath-te-extn]. + [I-D.ietf-mpls-multipath-use] and + [I-D.villamizar-mpls-multipath-extn]. The primary focus of this document, among the sets of requirements listed in Section 7.1 are the "admission control, preemption, traffic engineering" and the "path determination, connectivity verification" sets of requirements. The "backward compatibility and migration" and "general network management" requirements must also be considered. 7.2.8. Minimally Disruption Load Balance The behavior of hash methods used in classic multipath needs to be @@ -1783,30 +1759,30 @@ Section 7.2.5, Section 7.2.7, and Section 7.2.8. 8. IANA Considerations This is a framework document and therefore does not specify protocol extensions. This memo includes no request to IANA. 9. Security Considerations The security considerations for MPLS/GMPLS and for MPLS-TP are - documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework]. + documented in [RFC5920] and [RFC6941]. The types protocol extensions proposed in this framework document provide additional information about links, forwarding adjacencies, and LSP requirements. The protocol semantics changes described in this framework document propose additional LSP constraints applied at path computation time and at LSP admission at midpoints LSR. The additional information and constraints provide no additional security considerations beyond the security considerations already documented - in [RFC5920] and [I-D.ietf-mpls-tp-security-framework]. + in [RFC5920] and [RFC6941]. 10. Acknowledgments Authors would like to thank Adrian Farrel, Fred Jounay, Yuji Kamite for his extensive comments and suggestions regarding early versions of this document, Ron Bonica, Nabil Bitar, Eric Gray, Lou Berger, and Kireeti Kompella for their reviews of early versions and great suggestions. Authors would like to thank Iftekhar Hussain for review and @@ -1861,83 +1836,71 @@ J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011. 11.2. Informative References [DBP] Bertsekas, D., "Dynamic Behavior of Shortest Path Routing Algorithms for Communication Networks", IEEE Trans. Auto. Control 1982. - [I-D.giacalone-ospf-te-express-path] - Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. - Previdi, "OSPF Traffic Engineering (TE) Express Path", - draft-giacalone-ospf-te-express-path-02 (work in - progress), September 2011. - - [I-D.ietf-mpls-entropy-label] - Kompella, K., Drake, J., Amante, S., Henderickx, W., and - L. Yong, "The Use of Entropy Labels in MPLS Forwarding", - draft-ietf-mpls-entropy-label-06 (work in progress), - September 2012. + [I-D.atlas-mpls-te-express-path] + Atlas, A., Drake, J., Giacalone, S., Ward, D., Previdi, + S., and C. Filsfils, "Performance-based Path Selection for + Explicitly Routed LSPs", + draft-atlas-mpls-te-express-path-02 (work in progress), + February 2013. - [I-D.ietf-mpls-explicit-resource-control-bundle] - Zamfir, A., Ali, Z., and P. Dimitri, "Component Link - Recording and Resource Control for TE Links", - draft-ietf-mpls-explicit-resource-control-bundle-10 (work - in progress), April 2011. + [I-D.ietf-mpls-multipath-use] + Villamizar, C., "Use of Multipath with MPLS-TP and MPLS", + draft-ietf-mpls-multipath-use-00 (work in progress), + February 2013. - [I-D.ietf-mpls-tp-security-framework] - Fang, L., Niven-Jenkins, B., Mansfield, S., and R. - Graveman, "MPLS-TP Security Framework", - draft-ietf-mpls-tp-security-framework-04 (work in - progress), July 2012. + [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. [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-01 (work in - progress), October 2011. + Using RSVP-TE", draft-kompella-mpls-rsvp-ecmp-03 (work in + progress), May 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.villamizar-mpls-tp-multipath] - Villamizar, C., "Use of Multipath with MPLS-TP and MPLS", - draft-villamizar-mpls-tp-multipath-02 (work in progress), - February 2012. + [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", + draft-previdi-isis-te-metric-extensions-03 (work in + progress), February 2013. - [I-D.villamizar-mpls-tp-multipath-te-extn] + [I-D.villamizar-mpls-multipath-extn] Villamizar, C., "Multipath Extensions for MPLS Traffic - Engineering", - draft-villamizar-mpls-tp-multipath-te-extn-01 (work in - progress), February 2012. - - [I-D.wang-ccamp-latency-te-metric] - Fu, X., Betts, M., Wang, Q., McDysan, D., and A. Malis, - "GMPLS extensions to communicate latency as a traffic - engineering performance metric", - draft-wang-ccamp-latency-te-metric-03 (work in progress), - March 2011. + Engineering", draft-villamizar-mpls-multipath-extn-00 + (work in progress), November 2012. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000. [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000. @@ -1993,20 +1956,28 @@ to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. + [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and + L. Yong, "The Use of Entropy Labels in MPLS Forwarding", + RFC 6790, November 2012. + + [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. + Graveman, "MPLS Transport Profile (MPLS-TP) Security + Framework", RFC 6941, April 2013. + Authors' Addresses So Ning Tata Communications Email: ning.so@tatacommunications.com Dave McDysan Verizon 22001 Loudoun County PKWY