From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7855.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc7855.txt (limited to 'doc/rfc/rfc7855.txt') diff --git a/doc/rfc/rfc7855.txt b/doc/rfc/rfc7855.txt new file mode 100644 index 0000000..177c6db --- /dev/null +++ b/doc/rfc/rfc7855.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Previdi, Ed. +Request for Comments: 7855 C. Filsfils, Ed. +Category: Informational Cisco Systems, Inc. +ISSN: 2070-1721 B. Decraene + S. Litkowski + Orange + M. Horneffer + Deutsche Telekom + R. Shakir + Jive Communications, Inc. + May 2016 + + + Source Packet Routing in Networking (SPRING) + Problem Statement and Requirements + +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"; + therefore, it is not limited to the originator of the packet (i.e., + the node imposing the explicit route may be the ingress node of an + operator's network). + + 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 for this document. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7855. + + + +Previdi, et al. Informational [Page 1] + +RFC 7855 SPRING Problem Statement May 2016 + + +Copyright Notice + + Copyright (c) 2016 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 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Data Planes . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. IGP-Based MPLS Tunneling . . . . . . . . . . . . . . . . 4 + 3.1.1. Example of IGP-Based MPLS Tunnels . . . . . . . . . . 5 + 3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5 + 3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 6 + 3.3.1. Examples of Traffic-Engineering Use Cases . . . . . . 7 + 3.4. Interoperability with Non-SPRING Nodes . . . . . . . . . 13 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 5. Manageability Considerations . . . . . . . . . . . . . . . . 15 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 6.2. Informative References . . . . . . . . . . . . . . . . . 16 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + + + + + + + + + + + + + + + + +Previdi, et al. Informational [Page 2] + +RFC 7855 SPRING Problem Statement May 2016 + + +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: + + o Some types of network virtualization, including multi-topology + networks and the partitioning of network resources for VPNs + + o Network, link, path, and node protection such as fast reroute + + o Network programmability + + o OAM techniques + + o Simplification and reduction of network signaling components + + o 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 more + source-imposed routing than can be achieved through the use of the + previously defined methods. In the context of this document, the + term "source" means "the point at which the explicit route is + imposed"; therefore, it is not limited to the originator of the + packet (i.e., the node imposing the explicit route may be the ingress + node of an operator's network). Throughout this document, we refer + to this definition of "source". + + 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. + + The SPRING architecture MUST allow incremental and selective + deployment without any requirement of a flag day or massive upgrade + of all network elements. + + The SPRING architecture MUST allow putting the policy state in the + packet header and not in the intermediate nodes along the path. + Hence, the policy is instantiated in the packet header and does not + requires any policy state in midpoints and tail-ends. + + + + + + + +Previdi, et al. Informational [Page 3] + +RFC 7855 SPRING Problem Statement May 2016 + + + The SPRING architecture objective is not to replace existing source- + routing and traffic-engineering mechanisms, but rather to complement + them and address use cases where removal of signaling and path state + in the core is a requirement. + + Multicast use cases and requirements are out of scope for this + document. + +1.1. 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]. + +2. Data Planes + + The SPRING architecture SHOULD be general in order to ease its + applicability to different data planes. + + The SPRING architecture SHOULD leverage the existing MPLS data plane + without any modification and leverage the IPv6 data plane with a new + IPv6 Routing Header Type (IPv6 Routing Header is defined in + [RFC2460]) and a proposal for a new type of routing header is made by + [SRH]. + + The SPRING architecture MUST allow interoperability between SPRING- + capable and non-SPRING-capable nodes in both the MPLS and IPv6 data + planes. + +3. SPRING Use Cases + +3.1. IGP-Based MPLS Tunneling + + The source-based routing model, applied to the MPLS data plane, + offers the ability to tunnel services like VPN ([RFC4364]), Virtual + Private LAN Service (VPLS) ([RFC4761], [RFC4762]) and Virtual Private + Wire Service (VPWS) ([RFC6624]), from an ingress Provider Edge (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. Point-to-multipoint and multipoint-to-multipoint + tunnels are outside the scope of this document. + + + + + + + + + + +Previdi, et al. Informational [Page 4] + +RFC 7855 SPRING Problem Statement May 2016 + + +3.1.1. Example of IGP-Based MPLS Tunnels + + This section illustrates an example use case. + + 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 the + Multiprotocol Border Gateway Protocol (MPBGP) to PE1 with next-hop + address 192.0.2.2 (i.e., the local address of PE2). PE1 installs the + VPN prefix Z in the appropriate VPN Routing and Forwarding table + (VRF) and resolves the next hop onto the IGP-based MPLS tunnel to + PE2. + + To cope with the reality of current deployments, the SPRING + architecture MUST 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 the + necessary information derived from the topology database in order to + deliver the packet to the remote PE. + +3.2. Fast Reroute (FRR) + + Fast Reroute (FRR) technologies have been deployed by network + operators in order to cope with link or node failures through + precomputation of backup paths. + + Illustration of the problem statement for FRR and micro-loop + avoidance can be found in [SPRING-RESIL]. + + The SPRING architecture MUST address the following requirements: + + o support of Fast Reroute (FRR) on any topology + + o precomputation and setup of backup path without any additional + signaling (other than the regular IGP/BGP protocols) + + o support of shared risk constraints + + + + + + +Previdi, et al. Informational [Page 5] + +RFC 7855 SPRING Problem Statement May 2016 + + + o support of node and link protection + + o support of micro-loop avoidance + +3.3. Traffic Engineering + + Traffic Engineering (TE) is the term used to refer to techniques that + enable operators to control how specific traffic flows are treated + within their networks. Different contexts and modes have been + defined (single vs. multiple domains, with or without bandwidth + admission control, centralized vs. distributed path computation, + etc.). + + Some deployments have a limited use of TE, such as addressing + specific application or customer requirements, or addressing specific + bandwidth limitations in the network (tactical TE). In these + situations, there is a need to reduce, as much as possible, the cost + (such as the number of signaling protocols and the number of nodes + requiring specific configurations/features). Some other deployments + have a very high-scale use of TE, such as fine tuning flows at the + application level. In this situation, there is a need for very high + scalability, in particular on midpoints. + + The source-based routing model allows traffic engineering to be + implemented without the need for a signaling component. + + The SPRING architecture MUST support the following traffic- + engineering requirements: + + o loose or strict options + + o bandwidth admission control + + o distributed vs. centralized model (e.g., Path Computation Element + (PCE) [STATEFUL-PCE], Software-Defined Networking (SDN) + Controller) + + o disjointness in dual-plane networks + + o egress peer engineering + + o load balancing among non-parallel links (i.e., links connected to + different adjacent neighbors). + + o limiting (scalable, preferably zero) per-service state and + signaling on midpoint and tail-end routers. + + o ECMP-awareness + + + +Previdi, et al. Informational [Page 6] + +RFC 7855 SPRING Problem Statement May 2016 + + + o node resiliency property (i.e., the traffic-engineering policy is + not anchored to a specific core node whose failure could impact + the service). + + In most cases, traffic engineering makes use of the "loose" route + option where most of the explicit paths can be expressed through a + small number of hops. However, there are use cases where the + "strict" option may be used and, in such cases, each individual hop + in the explicit path is specified. This may result in a long list of + hops that is instantiated into a MPLS label stack (in the MPLS data + plane) or list of IPv6 addresses (in the IPv6 data plane). + + It is obvious that, in the case of long, strict source-routed paths, + the deployment is possible if the head-end of the explicit path + supports the instantiation of long explicit paths. + + Alternatively, a controller could decompose the end-to-end path into + a set of sub-paths such as each of these sub-paths is supported by + its respective head-end and advertised with a single identifier. + Hence, the concatenation (or stitching) of the sub-paths identifiers + gives a compression scheme allowing an end-to-end path to be + expressed in a smaller number of hops. + +3.3.1. Examples of Traffic-Engineering Use Cases + + Below are descriptions of two sets of use cases: + + o Traffic Engineering without Admission Control + + o Traffic Engineering with Admission Control + +3.3.1.1. Traffic Engineering without Bandwidth Admission Control + + In this section, we describe Traffic Engineering use cases without + bandwidth admission control. + +3.3.1.1.1. Disjointness in Dual-Plane Networks + + Many networks are built according to the dual-plane design, as + illustrated in Figure 2: + + Each aggregation region k is connected to the core by two C + routers C1k and C2k, where k refers to the region. + + C1k is part of plane 1 and aggregation region k + + C2k is part of plane 2 and aggregation region k + + + + +Previdi, et al. Informational [Page 7] + +RFC 7855 SPRING Problem Statement May 2016 + + + C1k has a link to C2j iff k = j. + + The core nodes of a given region are directly connected. + Inter-region links only connect core nodes of the same plane. + + {C1k has a link to C1j} iff {C2k has a link to C2j}. + + The distribution of these links depends on the topological + properties of the core of the Autonomous System (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. + + 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, Edge Router A should be able to + use the three following options: + + o The traffic is load-balanced across any ECMP path through the + network. + + + + +Previdi, et al. Informational [Page 8] + +RFC 7855 SPRING Problem Statement May 2016 + + + o The traffic is load-balanced across any ECMP path within Plane1 of + the network. + + o The traffic is load-balanced across any ECMP path within Plane2 of + the network. + + Most of the data traffic from A to Z would use the first option, so + 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 MUST support this use case with the following + requirements: + + o Zero per-service state and signaling on midpoint and tail-end + routers. + + 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. + +3.3.1.1.2. Egress Peering Traffic Engineering + + +------+ + | | + +---D F + +---------+ / | AS2 |\ +------+ + | |/ +------+ \| Z | + A C | | + | |\ +------+ /| AS4 | + B AS1 | \ | |/ +------+ + | | +---E G + +---------+ | AS3 | + +------+\ + + Figure 3: Egress Peering Traffic Engineering + + Let us assume, in the network depicted in Figure 3, that: + + o C in AS1 learns about destination Z of AS4 via two BGP paths (AS2, + AS4) and (AS3, AS4). + + o C may or may not be configured to enforce the next-hop-self + behavior before propagating the paths within AS1. + + + + + +Previdi, et al. Informational [Page 9] + +RFC 7855 SPRING Problem Statement May 2016 + + + o C may propagate all the paths to Z within AS1 (using BGP ADD-PATH + as specified in [ADD-PATH]). + + o C may install in its Forwarding Information Base (FIB) only the + route via AS2, or only the route via AS3, or both. + + In that context, the SPRING architecture MUST allow the operator of + AS1 to apply a traffic-engineering policy such as the following one, + regardless of the configured behavior of the next-hop-self: + + o Steer 60% of the Z-destined traffic received at A via AS2 and 40% + via AS3. + + o Steer 80% of the Z-destined traffic received at B via AS2 and 20% + via AS3. + + The SPRING architecture MUST allow an ingress node (i.e., an explicit + route source node) to select the exit point of a packet as any + combination of an egress node, an egress interface, a peering + neighbor, and a peering AS. + + The use cases and requirements for egress peer engineering are + described in [SR-BGP-EPE]. + +3.3.1.1.3. Load Balancing among Non-parallel Links + + The SPRING architecture MUST allow a given node to load-share traffic + across multiple non-parallel links (i.e., links connected to + different adjacent routers), even if these lead to different + neighbors. This may be useful for supporting 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 equal-cost paths in a + controlled way where the operator MUST be allowed to distribute + traffic unevenly between paths (Weighted Equal-Cost Multipath + (WECMP)). + + + + + + + + +Previdi, et al. Informational [Page 10] + +RFC 7855 SPRING Problem Statement May 2016 + + +3.3.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. + +3.3.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 1600 Mbps + A-to-Z flow is accounted as consuming 1600 Mbps on links AB and FZ; + 800 Mbps on links BC, BG, and GF; and 400 Mbps on links CD, DF, CE, + and EF. + + C-----D + / \ \ + A---B +--E--F--Z + \ / + G------+ + + Figure 5: Capacity Planning an ECMP-Based Demand + + ECMP is extremely frequent in Service Provider (SP), enterprise, and + data-center 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 network diagram below, which consists of a + subset of a network where already 5 ECMP paths are observed from A to + M. + + + + + + + +Previdi, et al. Informational [Page 11] + +RFC 7855 SPRING Problem Statement May 2016 + + + 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, and then to compute an explicit + path for each of them and instantiate these traffic-engineered + policies in the network. + + The SPRING architecture MUST 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 + + o the ability to diverge from a set of ECMP shortest paths to one or + more paths not in the set of shortest paths + +3.3.1.2.2. SDN Use Case + + The SDN use case lies in the SDN controller, (e.g., Stateful PCE as + described in [STATEFUL-PCE]). + + The SDN controller is responsible for controlling 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. + + + +Previdi, et al. Informational [Page 12] + +RFC 7855 SPRING Problem Statement May 2016 + + + The means of collecting traffic and topology information are the same + as what would be used with other SDN-based traffic-engineering + solutions. + + 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. + + In the context of centralized optimization and the SDN use case, the + SPRING architecture MUST have the following attributes: + + o Explicit routing capability with or without ECMP-awareness. + + o No signaling hop-by-hop through the network. + + o The policy state is only maintained at the policy head-end. No + policy state is maintained at midpoints and tail-ends. + + o Automated guaranteed FRR for any topology. + + o The policy state is in the packet header and not in the + intermediate nodes along the path. The policy is absent from + midpoints and tail-ends. + + o 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. + +3.4. Interoperability with Non-SPRING Nodes + + SPRING nodes MUST interoperate with non-SPRING nodes and in both MPLS + and IPv6 data planes in order to allow a gradual deployment of SPRING + on existing MPLS and IPv6 networks. + +4. Security Considerations + + SPRING reuses the concept of source routing by encoding the path in + the packet. As with other similar source-routing architecture, an + attacker may manipulate the traffic path by modifying the packet + header. By manipulating the traffic path, an attacker may be able to + cause outages on any part of the network. + + SPRING adds some metadata on the packet, with the list of forwarding + path elements that the packet must traverse. Depending on the data + plane, this list may shrink as the packet traverses the network, by + keeping only the next elements and forgetting the past ones. + + + + + +Previdi, et al. Informational [Page 13] + +RFC 7855 SPRING Problem Statement May 2016 + + + SPRING architecture MUST provide clear trust domain boundaries so + that source-routing information is only usable within the trusted + domain and never exposed to the outside world. + + From a network protection standpoint, 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. This is a significant change compared to + plain IP offering the shortest-path routing, but not fundamentally + different compared to existing techniques providing explicit routing + capability. It is expected that, by default, the explicit routing + information is not leaked through the boundaries of the administered + domain. + + Therefore, the data plane MUST NOT expose any source-routing + information when a packet leaves the trusted domain. Special care + will be required for the existing data planes like MPLS, especially + for the inter-provider scenario where a third-party provider may push + MPLS labels corresponding to a SPRING header anywhere in the stack. + The architecture document MUST analyze the exact security + considerations of such a scenario. + + Filtering routing information is typically performed in the control + plane, but an additional filtering in the forwarding plane is also + required. In SPRING, as there is no control plane (related to + source-routed paths) between the source and the midpoints, filtering + in the control plane is not possible (or not required, depending on + the point of view). Filtering MUST be performed on the forwarding + plane on the boundaries and MAY require looking at multiple labels or + instructions. + + For the MPLS data plane, this is not a new requirement as the + existing MPLS architecture already allows such source routing by + stacking multiple labels. For security protection, Section 2.4 of + [RFC4381] and Section 8.2 of [RFC5920] already call for the filtering + of MPLS packets on trust boundaries. + + If all MPLS labels are filtered at domain boundaries, then SPRING + does not introduce any change. If only a subset of labels are + filtered, then SPRING introduces a change since the border router is + expected to determine which information (e.g., labels) is filtered, + while the border router is not the originator of these label + advertisements. + + As the SPRING architecture must be based on a clear trust domain, + mechanisms allowing the authentication and validation of the source- + routing information must be evaluated by the SPRING architecture in + order to prevent any form of attack or unwanted source-routing + information manipulation. + + + +Previdi, et al. Informational [Page 14] + +RFC 7855 SPRING Problem Statement May 2016 + + + Data-plane security considerations MUST be addressed in each document + related to the SPRING data plane (i.e., MPLS and IPv6). + + The IPv6 data plane proposes the use of a cryptographic signature of + the source-routed path, which would ease this configuration. This is + indeed needed more for the IPv6 data plane, which is end to end in + nature, compared to the MPLS data plane, which is typically + restricted to a controlled and trusted zone. + + In the forwarding plane, data-plane extension documents MUST address + the security implications of the required change. + + In terms of privacy, SPRING does not propose change in terms of + encryption. Each data plane may or may not provide existing or + future encryption capability. + + To build the source-routing information in the packet, a node in the + SPRING architecture will require learning information from a control + layer. As this control layer will be in charge of programming + forwarding instructions, an attacker taking over this component may + also manipulate the traffic path. Any control protocol used in the + SPRING architecture SHOULD provide security mechanisms or design to + protect against such a control-layer attacker. Control-plane + security considerations MUST be addressed in each document related to + the SPRING control plane. + +5. Manageability Considerations + + The SPRING WG MUST define Operations, Administration, and Maintenance + (OAM) procedures applicable to SPRING-enabled networks. + + In SPRING networks, the path the packet takes is encoded in the + header. SPRING architecture MUST include the necessary OAM + mechanisms in order for the network operator to validate the + effectiveness of a path as well as to check and monitor its liveness + and performance. Moreover, in SPRING architecture, a path may be + defined in the forwarding layer (in both MPLS and IPv6 data planes) + or as a service path (formed by a set of service instances). The + network operator MUST be capable to monitor, control, and manage + paths (both network and service based) using OAM procedures. + + OAM use cases and requirements are detailed in [OAM-USE] and + [SR-OAM]. + + + + + + + + +Previdi, et al. Informational [Page 15] + +RFC 7855 SPRING Problem Statement May 2016 + + +6. References + +6.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, + . + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February + 2006, . + + [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, + . + + [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private + LAN Service (VPLS) Using Label Distribution Protocol (LDP) + Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, + . + + [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 + Virtual Private Networks Using BGP for Auto-Discovery and + Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, + . + +6.2. Informative References + + [ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder, + "Advertisement of Multiple Paths in BGP", Work in + Progress, draft-ietf-idr-add-paths-14, April 2016. + + [OAM-USE] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. + Kumar, "A Scalable and Topology-Aware MPLS Dataplane + Monitoring System", Work in Progress, draft-ietf-spring- + oam-usecase-03, April 2016. + + [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP + Virtual Private Networks (VPNs)", RFC 4381, + DOI 10.17487/RFC4381, February 2006, + . + + + + +Previdi, et al. Informational [Page 16] + +RFC 7855 SPRING Problem Statement May 2016 + + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + . + + [SPRING-RESIL] + Francois, P., Filsfils, C., Decraene, B., and R. Shakir, + "Use-cases for Resiliency in SPRING", Work in Progress, + draft-ietf-spring-resiliency-use-cases-03, April 2016. + + [SR-BGP-EPE] + Filsfils, C., Ed., Previdi, S., Ed., Ginsburg, D., and D. + Afanasiev, "Segment Routing Centralized BGP Peer + Engineering", Work in Progress, draft-ietf-spring-segment- + routing-central-epe-01, March 2016. + + [SR-OAM] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., + and S. Litkowski, "OAM Requirements for Segment Routing + Network", Work in Progress, draft-ietf-spring-sr-oam- + requirement-01, December 2015. + + [SRH] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, + J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment + Routing Header (SRH)", Work in Progress, draft-ietf-6man- + segment-routing-header-01, March 2016. + + [STATEFUL-PCE] + Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP + Extensions for Stateful PCE", Work in Progress, + draft-ietf-pce-stateful-pce-14, March 2016. + + + + + + + + + + + + + + + + + + + + + + +Previdi, et al. Informational [Page 17] + +RFC 7855 SPRING Problem Statement May 2016 + + +Acknowledgements + + The authors would like to thank Yakov Rekhter for his contribution to + this document. + +Contributors + + The following individuals substantially contributed to the content of + this document: + + Ruediger Geib + Deutsche Telekom + Heinrich Hertz Str. 3-7 + Darmstadt 64295 + Germany + + Email: Ruediger.Geib@telekom.de + + + Robert Raszuk + Mirantis Inc. + 615 National Ave. + 94043 Mountain View, CA + United States + + Email: robert@raszuk.net + +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 + Belgium + + Email: cfilsfil@cisco.com + + + + + + + +Previdi, et al. Informational [Page 18] + +RFC 7855 SPRING Problem Statement May 2016 + + + Bruno Decraene + Orange + France + + Email: bruno.decraene@orange.com + + + Stephane Litkowski + Orange + France + + Email: stephane.litkowski@orange.com + + + Martin Horneffer + Deutsche Telekom + Muenster 48153 + Germany + + Email: Martin.Horneffer@telekom.de + + + Rob Shakir + Jive Communications, Inc. + 1275 West 1600 North, Suite 100 + Orem, UT 84057 + United States + + Email: rjs@rob.sh + + + + + + + + + + + + + + + + + + + + + + +Previdi, et al. Informational [Page 19] + -- cgit v1.2.3