SPRING Problem Statement and Requirements
draft-ietf-spring-problem-statement-02
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7855.
|
|
---|---|---|---|
Authors | Stefano Previdi , Clarence Filsfils , Bruno Decraene , Stephane Litkowski , Martin Horneffer , Rob Shakir | ||
Last updated | 2014-10-01 | ||
Replaces | draft-previdi-spring-problem-statement | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Telechat review
(of
-06)
by Meral Shirazipour
Ready w/nits
GENART Telechat review
(of
-06)
by Meral Shirazipour
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | In WG Last Call | |
Document shepherd | Alvaro Retana | ||
IESG | IESG state | Became RFC 7855 (Informational) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-spring-problem-statement-02
Network Working Group S. Previdi, Ed. Internet-Draft C. Filsfils, Ed. Intended status: Informational Cisco Systems, Inc. Expires: April 4, 2015 B. Decraene S. Litkowski Orange M. Horneffer Deutsche Telekom R. Shakir British Telecom October 1, 2014 SPRING Problem Statement and Requirements draft-ietf-spring-problem-statement-02 Abstract The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed'. This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use- cases and requirements are out of scope of this document. Requirements Language 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]. 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 Previdi, et al. Expires April 4, 2015 [Page 1] Internet-Draft SPRING Problem Statement October 2014 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 4, 2015. Copyright Notice Copyright (c) 2014 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . 4 3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 4 4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 5 5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 6 5.1.1. Traffic Engineering without Bandwidth Admission Control . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. Traffic Engineering with Bandwidth Admission Control 10 6. Interoperability with non-SPRING nodes . . . . . . . . . . . 14 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Manageability Considerations . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Previdi, et al. Expires April 4, 2015 [Page 2] Internet-Draft SPRING Problem Statement October 2014 1. Introduction The ability for a node to specify a unicast forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example: Some types of network virtualization, including multi-topology networks and the partitioning of network resources for VPNs Network, link, path and node protection such as fast re-route Network programmability OAM techniques Simplification and reduction of network signaling components Load balancing and traffic engineering Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering. These network functions may require greater flexibility and per packet source imposed routing than can be achieved through the use of the previously defined methods. In the context of this charter, 'source' means 'the point at which the explicit route is imposed'. In this context, Source Packet Routing in Networking (SPRING) architecture is being defined in order to address the use cases and requirements described in this document. SPRING architecture should allow incremental and selective deployment without any requirement of flag day or massive upgrade of all network elements. SPRING architecture should allow optimal virtualization: put policy state in the packet header and not in the intermediate nodes along the path. Hence, the policy is completely virtualized away from midpoints and tail-ends. SPRING architecture objective is not to replace existing source routing and traffic engineering mechanisms but rather complement them and address use cases where removal of signaling and path state in the core is a requirement. Previdi, et al. Expires April 4, 2015 [Page 3] Internet-Draft SPRING Problem Statement October 2014 2. Dataplanes The SPRING architecture should be general in order to ease its applicability to different dataplanes. MPLS dataplane doesn't require any modification in order to apply a source-based routed model (e.g.: [I-D.filsfils-spring-segment-routing-mpls]). IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045], defines the Routing Extension Header which provides IPv6 source-based routing capabilities. The SPRING architecture should leverage existing MPLS dataplane without any modification and leverage IPv6 dataplane with a new IPv6 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). 3. IGP-based MPLS Tunneling The source-based routing model, applied to the MPLS dataplane, offers the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress PE, with or without the expression of an explicit path and without requiring forwarding plane or control plane state in intermediate nodes. The source-based routing model, applied to the MPLS dataplane, offers the ability to tunnel unicast services (VPN, VPLS, VPWS) from an ingress PE to an egress PE, with or without the expression of an explicit path and without requiring forwarding plane or control plane state in intermediate nodes. p2mp and mp2mp tunnels are out of the scope of this document. 3.1. Example of IGP-based MPLS Tunnels This section illustrates an example use-case taken from [I-D.filsfils-spring-segment-routing-use-cases]. P1---P2 / \ A---CE1---PE1 PE2---CE2---Z \ / P3---P4 Figure 1: IGP-based MPLS Tunneling In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to that route and propagates the route and its label via Previdi, et al. Expires April 4, 2015 [Page 4] Internet-Draft SPRING Problem Statement October 2014 MPBGP to PE1 with nhop 192.168.0.2. PE1 installs the VPN prefix Z in the appropriate VRF and resolves the next-hop onto the node segment associated with PE2. In order to cope with the reality of current deployments, the SPRING architecture should allow PE to PE forwarding according to the IGP shortest path without the addition of any other signaling protocol. The packet each PE forwards across the network will contain (within their label stack) the necessary information derived from the topology database in order to deliver the packet to the remote PE. 4. Fast Reroute FRR technologies have been deployed by network operators in order to cope with link or node failures through pre-computation of backup paths. The SPRING architecture should address following requirements: o support of FRR on any topology o pre-computation and setup of backup path without any additional signaling (other than the regular IGP/BGP protocols) o support of shared risk constraints o support of node and link protection o support of microloop avoidance Further illustrations of the problem statement for FRR are to be found in [I-D.ietf-spring-resiliency-use-cases]. 5. Traffic Engineering Traffic Engineering has been addressed using IGP protocol extensions (for resources information propagation) and RSVP-TE for signaling explicit paths. Different contexts and modes have been defined (single vs. multiple domains, with or without bandwidth admission control, centralized vs. distributed path computation, etc). In all cases, one of the major components of the TE architecture is the soft state based signaling protocol (RSVP-TE) which is used in order to signal and establish the explicit path. Each path, once computed, need to be signaled and state for each path must be present in each node traversed by the path. This incurs a scalability problem especially in the context of SDN where traffic differentiation may be done at a finer granularity (e.g.: application Previdi, et al. Expires April 4, 2015 [Page 5] Internet-Draft SPRING Problem Statement October 2014 specific). Also the amount of state needed to be maintained and periodically refreshed in all involved nodes contributes significantly to complexity and the number of failures cases, and thus increases operational effort while decreasing overall network reliability. The source-based routing model allows traffic engineering to be implemented without the need of a signaling component. The SPRING architecture should support traffic engineering, including: o loose or strict options o bandwidth admission control o distributed vs. centralized model (PCE, SDN Controller) o disjointness in dual-plane networks o egress peering traffic engineering o load-balancing among non-parallel links o Limiting (scalable, preferably zero) per-service state and signaling on midpoint and tail-end routers. o ECMP-awareness o node resiliency property (i.e.: the traffic-engineering policy is not anchored to a specific core node whose failure could impact the service. 5.1. Examples of Traffic Engineering Use Cases As documented in [I-D.filsfils-spring-segment-routing-use-cases] here follows the description of two sets of use cases: o Traffic Engineering without Admission Control o Traffic Engineering with Admission Control 5.1.1. Traffic Engineering without Bandwidth Admission Control In this section, we describe Traffic Engineering use-cases without bandwidth admission control. Previdi, et al. Expires April 4, 2015 [Page 6] Internet-Draft SPRING Problem Statement October 2014 5.1.1.1. Disjointness in dual-plane networks Many networks are built according to the dual-plane design, as illustrated in Figure 2: Each access region k is connected to the core by two C routers (C(1,k) and C(2,k)). C(1,k) is part of plane 1 and aggregation region K C(2,k) is part of plane 2 and aggregation region K C(1,k) has a link to C(2, j) iff k = j. The core nodes of a given region are directly connected. Inter-region links only connect core nodes of the same plane. {C(1,k) has a link to C(1, j)} iff {C(2,k) has a link to C(2, j)}. The distribution of these links depends on the topological properties of the core of the AS. The design rule presented above specifies that these links appear in both core planes. We assume a common design rule found in such deployments: the inter- plane link costs (Cik-Cjk where i<>j) are set such that the route to an edge destination from a given plane stays within the plane unless the plane is partitioned. Previdi, et al. Expires April 4, 2015 [Page 7] Internet-Draft SPRING Problem Statement October 2014 Edge Router A / \ / \ / \ Agg Region A / \ / \ C1A----------C2A | \ | \ | \ | \ | C1B----------C2B Plane1 | | | | Plane2 | | | | C1C--|-----C2C | \ | \ | \ | \ | C1Z----------C2Z \ / \ / Agg Region Z \ / \ / Edge Router Z Figure 2: Dual-Plane Network and Disjointness In this scenario, the operator requires the ability to deploy different strategies. For example, A should be able to use the three following options: o the traffic is load-balanced across any ECMP path through the network o the traffic is load-balanced across any ECMP path within the Plane1 of the network o the traffic is load-balanced across any ECMP path within the Plane2 of the network Most of the data traffic from A to Z would use the first option, such as to exploit the capacity efficiently. The operator would use the two other choices for specific premium traffic that has requested disjoint transport. The SPRING architecture should support this use case with the following requirements: o Zero per-service state and signaling on midpoint and tail-end routers. Previdi, et al. Expires April 4, 2015 [Page 8] Internet-Draft SPRING Problem Statement October 2014 o ECMP-awareness. o Node resiliency property: the traffic-engineering policy is not anchored to a specific core node whose failure could impact the service. 5.1.1.2. Egress Peering Traffic Engineering +------+ | | +---D F +---------+ / | AS 2 |\ +------+ | |/ +------+ \| Z | A C | | | |\ +------+ /| AS 4 | B AS1 | \ | |/ +------+ | | +---E G +---------+ | AS 3 | +------+\ Figure 3: Egress peering traffic engineering Let us assume, in the network depicted in Figure 3, that: C in AS1 learns about destination Z of AS 4 via two BGP paths (AS2, AS4) and (AS3, AS4). C may or may not be configured so to enforce next-hop-self behavior before propagating the paths within AS1. C may propagate all the paths to Z within AS1 (add-path). C may install in its FIB only the route via AS2, or only the route via AS3, or both. In that context, SPRING should allow the operator of AS1 to apply the following traffic-engineering policy, regardless the configured behavior of next-hop-self: Steer 60% of the Z-destined traffic received at A via AS2 and 40% via AS3. Steer 80% of the Z-destined traffic received at B via AS2 and 20% via AS3. The SPRING architecture should allow an ingress node (or a source node) to select the exit point of a packet as any combination of an Previdi, et al. Expires April 4, 2015 [Page 9] Internet-Draft SPRING Problem Statement October 2014 egress node, an egress interface, a peering neighbor, and a peering AS. 5.1.1.3. Load-balancing among non-parallel links The SPRING architecture should allow a given node should be able to load share traffic across multiple non parallel links even if these ones lead to different neighbors. This may be useful to support traffic engineering policies. +---C---D---+ | | PE1---A---B-----F-----E---PE2 Figure 4: Multiple (non-parallel) Adjacencies In the above example, the operator requires PE1 to load-balance its PE2-destined traffic between the ABCDE and ABFE paths. 5.1.2. Traffic Engineering with Bandwidth Admission Control The implementation of bandwidth admission control within a network (and its possible routing consequence which consists in routing along explicit paths where the bandwidth is available) requires a capacity planning process. The spreading of load among ECMP paths is a key attribute of the capacity planning processes applied to packet-based networks. 5.1.2.1. Capacity Planning Process Capacity Planning anticipates the routing of the traffic matrix onto the network topology, for a set of expected traffic and topology variations. The heart of the process consists in simulating the placement of the traffic along ECMP-aware shortest-paths and accounting for the resulting bandwidth usage. The bandwidth accounting of a demand along its shortest-path is a basic capability of any planning tool or PCE server. For example, in the network topology described below, and assuming a default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and EF. Internet-Draft Segment Routing Proxy Forwarding October 2018 3. Building proxy forwarding table Hu, et al. Expires April 25, 2019 [Page 5] Internet-Draft Segment Routing Proxy Forwarding October 2018 Node Sid:2 Node Sid:3 +-----+ +-----+ | |----------+ | / |RT2 | | RT3 |\ / +-----+ +-----+ \ / | \ /| \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ Node Sid:1 | \ / | \Node Sid:4 Node Sid:5 +-----+ | \ / | +-----+ +-----+ | | | X | | |-------| | | RT1 | | / \ | | RT4 | | RT5 | +-----+ | / \ | +-----+ +-----+ \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \| / \ |/ | / \ +-----+ +-----+ / \ | | | |/ \ | RT6 |-----------| RT7 | +-----+ +-----+ Node Sid:6 Node Sid:7 +------------------+ +----------------+ | Node SRGB | | label stack | +------------------+ +----------------+ | RT1:[1000-1999] | | 1003 | +------------------+ +-----------------+ +----------------+ | RT2:[2000-2999] | | Adj-Sid | | 3004 | +------------------+ +-----------------+ +----------------+ | RT3:[3000-3999] | |RT3->RT6:3036 | | 4005 | +------------------+ +-----------------+ +----------------+ | RT4:[4000=4999] | |RT3->RT7:3037 | +------------------+ +-----------------+ | RT5:[5000-5999] | |RT3->RT4:3034 | +------------------+ +-----------------+ | RT6:[6000-6999] | |RT7->RT4:7074 | +------------------+ +-----------------+ | RT7:[7000-7999] | |RT4->RT5:4045 | +------------------+ +-----------------+ Figure 1. Topolocy of SR-TE path Hu, et al. Expires April 25, 2019 [Page 6] Internet-Draft Segment Routing Proxy Forwarding October 2018 We use Figure 1 to illustrate the SR proxy forwarding approach. Each node N has SRGB = [N000-N999], RT1 is an ingress node of SR domain . A label stack that represents the path R1->R3->R4->R5 is shown as well. In the figure,RT3 is a failure node , RT2 is a Point of Local Repair (PLR) node. 3.1. Advertise proxy forwarding TLV If the Point of Local Repair (PLR) has proxy forwarding ability, for example, RT2. When node RT2 learns the prefix-sid of the direct neighbor RT3, it must use the proxy forwarding TLV to advertise the prefix-sid learned from RT3. When RT3 fails, RT2 needs to maintain proxy forwarding TLV for a period of time. When the proxy forwarding table corresponding to the fault node is deleted (see section 3.2), the proxy forwarding TLV is withdrawn. The nodes in the network (for example, RT1) learn the Prefix-Sid TLV advertised by RT3 and the proxy forwarding TLV advertised by RT2, when RT3 is normal, the nodes prefer Prefix-Sid TLV. When the RT3 fails, the proxy forwarding TLV advertised by RT2 is preferred. 3.2. Calculate the proxy forwarding table The SR proxy node needs to calculate a proxy forwarding table for each neighbor, each neighbor has an independent proxy forwarding table. The Node P (PLR) generates a proxy forwarding table for Node N, and P needs to contain the following information: 1: Node N's SRGB range and the difference between the SRGB start value of node P and that of node N; 2: All adjacency-SID of N and Node-SID of the node pointed to by NODE N's adjacency-SID. 3: The binding-SID of N and the label stack associated with binding- SID of N. NODE P (PLR) uses a proxy forwarding table based on the next segment to find a node N as a backup forwarding entry to the adj-SID and Node-SID of the N. When the N fails, the proxy forwarding table needs to be maintained for a period of time, which is recommended for 30 minutes. Node RT3 in the topology of Figure 1 is the node N, and the node RT2 is the P (PLR). RT2 calculates the proxy forwarding table for RT3, as shown in Figure 2. Hu, et al. Expires April 25, 2019 [Page 7] Internet-Draft Segment Routing Proxy Forwarding October 2018 RT2's Routing Table (partial) +==========+====================================+===========+=======+ | In-Label | Action | Out-Label | TYPE | +==========+====================================+===========+=======+ | 2003 | pop, fwd to RT3 | 3003 |Primary| | | pop, lookup Proxy Forwarding table | |Backup | +----------+--------------------------------------------------------+ | 2004 |pop, fwd to RT3 | 3004 |Primary| | |pop, fwd to RT7 | 7004 |Backup | +----------+--------------------------------------------------------+ RT2's Proxy Forwarding Table for RT3 (partial) +==========+===============+============+=============+==============+ | In-label | SRGBDiffValue | Next Label | Action | Map Label | +==========+===============+============+=============+==============+ | 2003 | -1000 | 3034 | Fwd to RT4 | 2004 | +----------+---------------+------------+-------------+--------------+ | 3036 | Fwd to RT6 | 2006 | +------------+-------------+--------------+ | 3037 | Fwd to RT7 | 2007 | +------------+-------------+--------------+ | 100 | Swap to { 3034, 4045 } | +------------+-------------+--------------+ Figure 2. RT2's Routing Table and Proxy Forwarding Table for RT3 (partial) Where: In-Lable: Local Node SRGB starting value + Node-Sid of protected node RT3. SRGBDiffValue: Local node(RT2) SRGB starting value - Protected node(RT3) SRGB starting value. Next Label: Generate forwarding entries for adj-Sids and binding-sids of Protected node(RT3). Map Label: the PLR swaps the Next Label to the Map Label, and then queries the PLR Routing Table again according to the Map Label to obtain the out-label. 4. Node Protection for Segment List Segment Routing Traffic Engineering supports the creation of explicit paths using adjacency-sids, node-sids, and binding-sids. The label stack is a combination of one or more of adjacency-sids, node-sids, and binding-sids. This Section shows how the P-node uses the SR Hu, et al. Expires April 25, 2019 [Page 8] Internet-Draft Segment Routing Proxy Forwarding October 2018 proxy forwarding mechanism to protect traffic to the destination node when the next segment of label stack is adjacency-sids, node-sids, or binding-sids, respectively. 4.1. Next segment is an adjacency segment Hu, et al. Expires April 25, 2019 [Page 9] Internet-Draft Segment Routing Proxy Forwarding October 2018 Node Sid:2 Node Sid:3 +-----+ +-----+ | |----------+ | / |RT2 | | RT3 |\ / +-----+ +-----+ \ / | \ /| \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ Node Sid:1 | \ / | \Node Sid:4 Node Sid:5 +-----+ | \ / | +-----+ +-----+ | | | X | | |-------| | | RT1 | | / \ | | RT4 | | RT5 | +-----+ | / \ | +-----+ +-----+ \ | / \ | / \ | / \ | /2 \ | / \ | /ru \ | / \ | / \ | / \| / \ |/ | / \ +-----+ +-----+ / \ | | | |/ \ | RT6 |-----------| RT7 | +-----+ +-----+ Node Sid:6 Node Sid:7 +------------------+ +-----------------+ +----------------+ | Node SRGB | | Adj-Sid | | Label Stack | +------------------+ +-----------------+ +----------------+ | RT1:[1000-1999] | |RT1->RT2:1012 | | 1012 | +------------------+ +-----------------+ +----------------+ | RT2:[2000-2999] | |RT2->RT3:2023 | | 2023 | +------------------+ +-----------------+ +----------------+ | RT3:[3000-3999] | |RT3->RT6:3036 | | 3034 | +------------------+ +-----------------+ +----------------+ | RT4:[4000=4999] | |RT3->RT7:3037 | | 4045 | +------------------+ +-----------------+ +----------------+ | RT5:[5000-5999] | |RT3->RT4:3034 | +------------------+ +-----------------+ | RT6:[6000-6999] | |RT7->RT4:7074 | +------------------+ +-----------------+ | RT7:[7000-7999] | |RT4->RT5:4045 | +------------------+ +-----------------+ Figure 3. Next Segment is adj-SID for Node Protection Hu, et al. Expires April 25, 2019 [Page 10] Internet-Draft Segment Routing Proxy Forwarding October 2018 As shown in Figure 3, the SR-TE strict explicit path is RT1->RT2->RT3->RT4->RT5, identified by the label stack { 1012, 2023, 3034, 4045 }. The adj-sid: 3034, which is used to identify the traffic forwarding path of the RT3->RT4. Node RT2 acts as a PLR node, and uses next adj-SID of the label stack to lookup the proxy forwarding table calculated by RT2 locally for RT3. The queried path is the label forwarding path of the next hop node of RT3, which bypasses RT3. The specific steps are as follows: a. RT1 pops top adj-SID 1012, and forwards packets to RT2; b. RT2 identifies the next hop node RT3 fault, pops top adj-SID 2023, and queries Proxy Forwarding Table with the next sid (3034). The query result is forwarding packets to RT4, the map label is 2004; c. RT2 swaps the label 3034 to map label 2004, and then uses the map label 2004 to query RT2's Routing Table. Due to RT3 failure, the result of the query is forwarding the packets to RT7 (backup path) , and the out-label is 7004. d. RT2 swaps the label 2004 to out-label 7004, and forwards packets to RT7. RT7 queries the local routing table to forward to RT4. 4.2. Next segment is a node segment Hu, et al. Expires April 25, 2019 [Page 11] Internet-Draft Segment Routing Proxy Forwarding October 2018 Node Sid:2 Node Sid:3 +-----+ +-----+ | |----------+ | / |RT2 | | RT3 |\ / +-----+ +-----+ \ / | \ /| \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ Node Sid:1 | \ / | \Node Sid:4 Node Sid:5 +-----+ | \ / | +-----+ +-----+ | | | X | | |-------| | | RT1 | | / \ | | RT4 | | RT5 | +-----+ | / \ | +-----+ +-----+ \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \| / \ |/ | / \ +-----+ +-----+ / \ | | | |/ \ | RT6 |-----------| RT7 | +-----+ +-----+ Node Sid:6 Node Sid:7 +------------------+ +-----------------+ +----------------+ | Node SRGB | | Adj-Sid | | Label Stack | +------------------+ +-----------------+ +----------------+ | RT1:[1000-1999] | |RT1->RT2:1012 | | 1003 | +------------------+ +-----------------+ +----------------+ | RT2:[2000-2999] | |RT2->RT3:2023 | | 3004 | +------------------+ +-----------------+ +----------------+ | RT3:[3000-3999] | |RT3->RT6:3036 | | 4005 | +------------------+ +-----------------+ +----------------+ | RT4:[4000=4999] | |RT3->RT7:3037 | +------------------+ +-----------------+ | RT5:[5000-5999] | |RT3->RT4:3034 | +------------------+ +-----------------+ | RT6:[6000-6999] | |RT7->RT4:7074 | +------------------+ +-----------------+ | RT7:[7000-7999] | |RT4->RT5:4045 | +------------------+ +-----------------+ Figure 4. Next Segment is node-SID for Node Protection Hu, et al. Expires April 25, 2019 [Page 12] Internet-Draft Segment Routing Proxy Forwarding October 2018 As shown in Figure 4, the SR-TE loose path is RT1->RT3->RT4->RT5, which is identified by the label stack {1003, 3004, 4005}. When the node RT3 fails, the proxy forwarding TLV advertised by the RT2 is preferred to direct the traffic of the RT1 to the PLR node RT2. Node RT2 acts as a PLR node and queries the proxy forwarding table locally calculated for RT3. The queried path is the label forwarding path of the next hop node of RT3, which bypasses RT3. The specific steps are as follows: a. RT1 swaps label 1003 to out-label 2003 to RT3. b. RT2 receives the label forwarding packet whose top label of label stack is 2003, and searches for the local Routing Table, the behavior found is lookup Proxy Forwarding table due to RT3 failure. c. RT2 uses 2003 as the in-label to lookup Proxy Forwarding tabel, and finds that the SRGB difference between local node and the faulty node is -1000. The next label(3004) of the label stack (top label 2003 pop) and the SRGB difference are used to recalculated the new in-label[ 3004+(-1000)= 2004 ]. d. Uses the new in-label(2004) to lookup the RT2's Routing Table. because of RT3 failure, the backup path is searched directly, and the behavior of backup path is forwarded to RT7, out-label is 7004. e. RT2 swaps the label 2004 to out-label 7004, and forwards packets to RT7. RT7 queries the local routing table to forward to RT4. 4.3. Next segment is a binding segment Hu, et al. Expires April 25, 2019 [Page 13] Internet-Draft Segment Routing Proxy Forwarding October 2018 Node Sid:2 Node Sid:3 +-----+ +-----+ | |----------+ | / |RT2 | | RT3 |\ / +-----+ +-----+ \ / | \ /| \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ Node Sid:1 | \ / | \Node Sid:4 Node Sid:5 +-----+ | \ / | +-----+ +-----+ | | | X | | |-------| | | RT1 | | / \ | | RT4 | | RT5 | +-----+ | / \ | +-----+ +-----+ \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \ | / \| / \ |/ | / \ +-----+ +-----+ / \ | | | |/ \ | RT6 |-----------| RT7 | +-----+ +-----+ Node Sid:6 Node Sid:7 +------------------+ +-----------------+ +----------------+ | Node SRGB | | Adj-Sid | | Label Stack | +------------------+ +-----------------+ +----------------+ | RT1:[1000-1999] | |RT1->RT2:1012 | | 1003 | +------------------+ +-----------------+ +----------------+ | RT2:[2000-2999] | |RT2->RT3:2023 | | 100 | +------------------+ +-----------------+ +----------------+ | RT3:[3000-3999] | |RT3->RT6:3036 | +------------------+ +-----------------+ | RT4:[4000=4999] | |RT3->RT7:3037 | +------------------+ +-----------------+ | RT5:[5000-5999] | |RT3->RT4:3034 | +------------------+ +-----------------+ | RT6:[6000-6999] | |RT7->RT4:7074 | +------------------+ +-----------------+ | RT7:[7000-7999] | |RT4->RT5:4045 | +------------------+ +-----------------+ Figure 5. Next Segment is Binding-SID for Node Protection Hu, et al. Expires April 25, 2019 [Page 14] Internet-Draft Segment Routing Proxy Forwarding October 2018 As shown in Figure 4, the SR-TE loose path is RT1->RT3->RT4->RT5, which is identified by the label stack { 1003,100 },where 100 is a Binding-Sid, which represents the label combination of { 3034, 4045}. When the node RT3 fails, the proxy forwarding TLV advertised by the RT2 is preferred to direct the traffic of the RT1 to the PLR node RT2. Node RT2 acts as a PLR node and uses Binding-SID to query the proxy forwarding table locally calculated for RT3. The queried path is the label forwarding path of the next hop node of RT3, which bypasses RT3. The specific steps are as follows: a. RT1 swaps label 1003 to out-label 2003 to RT3. b. RT2 receives the label forwarding packet whose top label of label stack is 2003, and searches for the local Routing Table, the behavior found is lookup Proxy Forwarding table due to RT3 failure. c. RT2 uses Binding-sid:100(label 2003 has pop) as the in-label to lookup the Next Label record of the Proxy Forwarding Tabel, the behavior found is swap to Segment list { 3034, 4045 }. d. RT2 swaps Binding-sid:100 to Segment list { 3034, 4045 }, and RT2 Uses the 3034 to lookup the Next Label record of the Proxy Forwarding table again. The behavior found is Forward to RT4, and the map label is 2004. e. Uses the new in-label(2004) to lookup the RT2's Routing Table. because of RT3 failure, the backup path is searched directly, and the behavior of backup path is forwarded to RT7, out-label is 7004. f. RT2 swaps the label 2004 to out-label 7004, and forwards packets to RT7. RT7 queries the local routing table to forward to RT4. 5. Other scenario considerations The implementation for SRv6 and egress protection will be added in subsequent documentation. 6. IANA Considerations TBD 7. Security Considerations TBD Hu, et al. Expires April 25, 2019 [Page 15] Internet-Draft Segment Routing Proxy Forwarding October 2018 8. Acknowledgements TBD 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. 9.2. Informative References [I-D.bashandy-rtgwg-segment-routing-ti-lfa] Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Camarillo, "Topology Independent Fast Reroute using Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- lfa-05 (work in progress), October 2018. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf-isis- segment-routing-extensions-19 (work in progress), July 2018. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing- policy-01 (work in progress), June 2018. [I-D.sivabalan-pce-binding-label-sid] Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., Previdi, S., and D. Dhody, "Carrying Binding Label/ Segment-ID in PCE-based Networks.", draft-sivabalan-pce- binding-label-sid-05 (work in progress), October 2018. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: &Previdi, et al. Expires April 4, 2015 [Page 10] Internet-Draft SPRING Problem Statement October 2014 C-----D / \ \ A---B +--E--F--Z \ / G------+ Figure 5: Capacity Planning an ECMP-based demand ECMP is extremely frequent in SP, Enterprise and DC architectures and it is not rare to see as much as 128 different ECMP paths between a source and a destination within a single network domain. It is a key efficiency objective to spread the traffic among as many ECMP paths as possible. This is illustrated in the below network diagram which consists of a subset of a network where already 5 ECMP paths are observed from A to M. C / \ B-D-L-- / \ / \ A E \ \ M \ G / \ / \ / F K \ / I Figure 6: ECMP Topology Example When the capacity planning process detects that a traffic growth scenario and topology variation would lead to congestion, a capacity increase is triggered and if it cannot be deployed in due time, a traffic engineering solution is activated within the network. A basic traffic engineering objective consists of finding the smallest set of demands that need to be routed off their shortest path to eliminate the congestion, then to compute an explicit path for each of them and instantiating these traffic-engineered policies in the network. SPRING architecture should offer a simple support for ECMP-based shortest path placement as well as for explicit path policy without incurring additional signaling in the domain. This includes: o the ability to steer a packet across a set of ECMP paths Previdi, et al. Expires April 4, 2015 [Page 11] Internet-Draft SPRING Problem Statement October 2014 o the ability to diverge from a set of ECMP shortest paths to one or more paths not in the set of shortest paths 5.1.2.2. SDN/SR use-case The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as described in [I-D.ietf-pce-stateful-pce]. The SDN controller is responsible to control the evolution of the traffic matrix and topology. It accepts or denies the addition of new traffic into the network. It decides how to route the accepted traffic. It monitors the topology and upon topological change, determines the minimum traffic that should be rerouted on an alternate path to alleviate a bandwidth congestion issue. The algorithms supporting this behavior are a local matter of the SDN controller and are outside the scope of this document. The means of collecting traffic and topology information are the same as what would be used with other SDN-based traffic-engineering solutions (e.g. [RFC7011] and [I-D.ietf-idr-ls-distribution]. The means of instantiating policy information at a traffic- engineering head-end are the same as what would be used with other SDN-based traffic-engineering solutions (e.g.: [I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and [I-D.sivabalan-pce-segment-routing]). In the context of Centralized-Based Optimization and the SDN use- case, here are the benefits that the SPRING architecture should deliver: Explicit routing capability with or without ECMP-awareness. No signaling hop-by-hop through the network. State is only maintained at the policy head-end. No state is maintained at mid-points and tail-ends. Automated guaranteed FRR for any topology. Optimum virtualization: the policy state is in the packet header and not in the intermediate nodes along the path. The policy is completely virtualized away from midpoints and tail-ends. Highly responsive to change: the SDN Controller only needs to apply a policy change at the head-end. No delay is introduced due to programming the midpoints and tail-end along the path. Previdi, et al. Expires April 4, 2015 [Page 12] Internet-Draft SPRING Problem Statement October 2014 5.1.2.2.1. SDN Example The data-set consists in a full-mesh of 12000 explicitly-routed tunnels observed on a real network. These tunnels resulted from distributed headend-based CSPF computation. We measured that only 65% of the traffic is forwarded over its shortest path. Three well-known defects are illustrated in this data set: The lack of ECMP support in explicitly routed tunnels: ATM-alike traffic-steering mechanisms steer the traffic along a non-ECMP path. The increase of the number of explicitly-routed non-ECMP tunnels to enumerate all the ECMP options. The inefficiency of distributed optimization: too much traffic is forwarded off its shortest path. We applied the SDN use-case to this dataset implying a source route model where the path of the packet is encoded within the packet itself. This means that: The distributed CSPF computation is replaced by centralized optimization and BW admission control, supported by the SDN Controller. As part of the optimization, we also optimized the IGP-metrics such as to get a maximum of traffic load-spread among ECMP paths by default. The traffic-engineering policies are supported by a source route model (e.g.: [I-D.filsfils-spring-segment-routing]). As a result, we measured that 98% of the traffic would be kept on its normal policy (over the shortest-path) and only 2% of the traffic requires a path away from the shortest-path. Let us highlight a few benefits: 98% of the traffic-engineering head-end policies are eliminated. Indeed, by default, an ingress edge node capable of injecting source routed packets steers the traffic to the egress edge node. No configuration or policy needs to be maintained at the ingress edge node to realize this. Previdi, et al. Expires April 4, 2015 [Page 13] Internet-Draft SPRING Problem Statement October 2014 100% of the states at mid/tail nodes are eliminated. 6. Interoperability with non-SPRING nodes SPRING must inter-operate with non-SPRING nodes. An illustration of interoperability between SPRING and other MPLS Signalling Protocols (LDP) is described here in [I-D.filsfils-spring-segment-routing-ldp-interop]. Interoperability with IPv6 non-SPRING nodes will be described in a future document. 7. OAM The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. The SPRING procedures may also be used as a tool for OAM in SPRING enabled networks. OAM use cases and requirements are described in [I-D.geib-spring-oam-usecase] and [I-D.kumar-spring-sr-oam-requirement]. 8. Security There is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so. In such context trust boundaries should strip explicit routes from a packet. For each data plane technology that SPRING specifies, a security analysis must be provided showing how protection is provided against an attacker disrupting the network by for example, maliciously injecting SPRING packets. 9. IANA Considerations TBD 10. Manageability Considerations TBD 11. Security Considerations TBD Previdi, et al. Expires April 4, 2015 [Page 14] Internet-Draft SPRING Problem Statement October 2014 12. Contributors The following individuals substantially contributed to the content of this documents: Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 DE Email: Ruediger.Geib@telekom.de Robert Raszuk Individual Email: robert@raszuk.net 13. Acknowledgements The authors would like to thank Yakov Rekhter for his contribution to this document. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012. [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013. 14.2. Informative References [I-D.crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in progress), October 2013. Previdi, et al. Expires April 4, 2015 [Page 15] Internet-Draft SPRING Problem Statement October 2014 [I-D.filsfils-spring-segment-routing] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", draft-filsfils-spring- segment-routing-04 (work in progress), July 2014. [I-D.filsfils-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment Routing interoperability with LDP", draft- filsfils-spring-segment-routing-ldp-interop-02 (work in progress), September 2014. [I-D.filsfils-spring-segment-routing-mpls] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment Routing with MPLS data plane", draft-filsfils- spring-segment-routing-mpls-03 (work in progress), August 2014. [I-D.filsfils-spring-segment-routing-use-cases] Filsfils, C., Francois, P., Previdi, S., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. Crabbe, "Segment Routing Use Cases", draft-filsfils- spring-segment-routing-use-cases-00 (work in progress), March 2014. [I-D.geib-spring-oam-usecase] Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use case for a scalable and topology aware MPLS data plane monitoring system", draft-geib-spring-oam-usecase-02 (work in progress), July 2014. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-05 (work in progress), July 2014. [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", draft-ietf-idr-ls-distribution-06 (work in progress), September 2014. Previdi, et al. Expires April 4, 2015 [Page 16] Internet-Draft SPRING Problem Statement October 2014 [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- pce-09 (work in progress), June 2014. [I-D.ietf-spring-resiliency-use-cases] Francois, P., Filsfils, C., Decraene, B., and R. Shakir, "Use-cases for Resiliency in SPRING", draft-ietf-spring- resiliency-use-cases-00 (work in progress), May 2014. [I-D.kumar-spring-sr-oam-requirement] Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. Mirsky, "OAM Requirements for Segment Routing Network", draft-kumar-spring-sr-oam-requirement-01 (work in progress), July 2014. [I-D.sivabalan-pce-segment-routing] Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions for Segment Routing", draft-sivabalan-pce-segment- routing-03 (work in progress), July 2014. [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013. Authors' Addresses Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy Email: sprevidi@cisco.com Clarence Filsfils (editor) Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Previdi, et al. Expires April 4, 2015 [Page 17] Internet-Draft SPRING Problem Statement October 2014 Bruno Decraene Orange FR Email: bruno.decraene@orange.com Stephane Litkowski Orange FR Email: stephane.litkowski@orange.com Martin Horneffer Deutsche Telekom Hammer Str. 216-226 Muenster 48153 DE Email: Martin.Horneffer@telekom.de Rob Shakir British Telecom London UK Email: rob.shakir@bt.com Previdi, et al. Expires April 4, 2015 [Page 18]