idnits 2.17.1 draft-ietf-spring-problem-statement-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2016) is 2950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-00 == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-13 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-13 == Outdated reference: A later version (-10) exists of draft-ietf-spring-oam-usecase-01 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-02 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-00 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-oam-requirement-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi, Ed. 3 Internet-Draft C. Filsfils, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: September 2, 2016 B. Decraene 6 S. Litkowski 7 Orange 8 M. Horneffer 9 Deutsche Telekom 10 R. Shakir 11 Jive Communications 12 March 1, 2016 14 SPRING Problem Statement and Requirements 15 draft-ietf-spring-problem-statement-07 17 Abstract 19 The ability for a node to specify a forwarding path, other than the 20 normal shortest path, that a particular packet will traverse, 21 benefits a number of network functions. Source-based routing 22 mechanisms have previously been specified for network protocols, but 23 have not seen widespread adoption. In this context, the term 24 'source' means 'the point at which the explicit route is imposed' and 25 therefore it is not limited to the originator of the packet (i.e.: 26 the node imposing the explicit route may be the ingress node of an 27 operator's network). 29 This document outlines various use cases, with their requirements, 30 that need to be taken into account by the Source Packet Routing in 31 Networking (SPRING) architecture for unicast traffic. Multicast use- 32 cases and requirements are out of scope of this document. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 2, 2016. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . 4 78 3.1.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . 4 79 3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5 80 3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5 81 3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 7 82 3.4. Interoperability with non-SPRING nodes . . . . . . . . . 13 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 6. Manageability Considerations . . . . . . . . . . . . . . . . 15 86 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 9.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 The ability for a node to specify a unicast forwarding path, other 96 than the normal shortest path, that a particular packet will 97 traverse, benefits a number of network functions, for example: 99 Some types of network virtualization, including multi-topology 100 networks and the partitioning of network resources for VPNs 102 Network, link, path and node protection such as fast re-route 104 Network programmability 106 OAM techniques 108 Simplification and reduction of network signaling components 110 Load balancing and traffic engineering 112 Source-based routing mechanisms have previously been specified for 113 network protocols, but have not seen widespread adoption other than 114 in MPLS traffic engineering. 116 These network functions may require greater flexibility and per 117 packet source imposed routing than can be achieved through the use of 118 the previously defined methods. In the context of this document, the 119 term 'source' means 'the point at which the explicit route is 120 imposed' and therefore it is not limited to the originator of the 121 packet (i.e.: the node imposing the explicit route may be the ingress 122 node of an operator's network). Throughout this document we refer to 123 this definition of 'source'. 125 In this context, Source Packet Routing in Networking (SPRING) 126 architecture is being defined in order to address the use cases and 127 requirements described in this document. 129 The SPRING architecture MUST allow incremental and selective 130 deployment without any requirement of flag day or massive upgrade of 131 all network elements. 133 The SPRING architecture MUST allow to put policy state in the packet 134 header and not in the intermediate nodes along the path. Hence, the 135 policy is instantiated in the packet header and does not requires any 136 policy state in midpoints and tail-ends. 138 The SPRING architecture objective is not to replace existing source 139 routing and traffic engineering mechanisms but rather complement them 140 and address use cases where removal of signaling and path state in 141 the core is a requirement. 143 Multicast use-cases and requirements are out of scope of this 144 document. 146 2. Dataplanes 148 The SPRING architecture SHOULD be general in order to ease its 149 applicability to different dataplanes. 151 The SPRING architecture SHOULD leverage the existing MPLS dataplane 152 without any modification and leverage IPv6 dataplane with a new IPv6 153 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]) and 154 a proposal for a new type of routing header is made by 155 [I-D.ietf-6man-segment-routing-header]. 157 The SPRING architecture MUST allow interoperability between SPRING 158 capable and non-capable nodes and this in both MPLS and IPv6 159 dataplanes. 161 3. SPRING Use Cases 163 3.1. IGP-based MPLS Tunneling 165 The source-based routing model, applied to the MPLS dataplane, offers 166 the ability to tunnel services like VPN ([RFC4364]), VPLS ([RFC4761], 167 [RFC4762]) and VPWS ([RFC6624]), from an ingress PE to an egress PE, 168 with or without the expression of an explicit path and without 169 requiring forwarding plane or control plane state in intermediate 170 nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are 171 outside of the scope of this document. 173 3.1.1. Example of IGP-based MPLS Tunnels 175 This section illustrates an example use-case. 177 P1---P2 178 / \ 179 A---CE1---PE1 PE2---CE2---Z 180 \ / 181 P3---P4 183 Figure 1: IGP-based MPLS Tunneling 185 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 186 same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local 187 label LZ to that route and propagates the route and its label via 188 MPBGP to PE1 with nhop 192.0.2.2 (i.e.: the local address of PE2). 189 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 190 next-hop onto the IGP-based MPLS tunnel to PE2. 192 In order to cope with the reality of current deployments, the SPRING 193 architecture MUST allow PE to PE forwarding according to the IGP 194 shortest path without the addition of any other signaling protocol. 195 The packet each PE forwards across the network will contain the 196 necessary information derived from the topology database in order to 197 deliver the packet to the remote PE. 199 3.2. Fast Reroute (FRR) 201 FRR technologies have been deployed by network operators in order to 202 cope with link or node failures through pre-computation of backup 203 paths. 205 The SPRING architecture MUST address the following requirements: 207 o support of Fast Reroute (FRR) on any topology 209 o pre-computation and setup of backup path without any additional 210 signaling (other than the regular IGP/BGP protocols) 212 o support of shared risk constraints 214 o support of node and link protection 216 o support of microloop avoidance 218 Further illustrations of the problem statement for FRR are to be 219 found in [I-D.ietf-spring-resiliency-use-cases]. 221 3.3. Traffic Engineering 223 Traffic Engineering (TE) is the term used to refer to techniques that 224 enable operators to control how specific traffic flows are treated 225 within their networks. Different contexts and modes have been 226 defined (single vs. multiple domains, with or without bandwidth 227 admission control, centralized vs. distributed path computation, 228 etc). 230 Some deployments have a limited use of TE such as addressing specific 231 application or customer requirements or address specific bandwidth 232 limitation in the network (tactical TE). In this situation, there is 233 need to reduce as much of possible the cost (such as the number of 234 signaling protocols and the number of nodes requiring specific 235 configurations/features. Some other deployments have a very high 236 scale use of TE, such as fine tuning flows at the application level. 237 In this situation, there is a need for a very high scalability, in 238 particular on mid-points. 240 The source-based routing model allows traffic engineering to be 241 implemented without the need of a signaling component. 243 The SPRING architecture MUST support the following traffic 244 engineering requirements: 246 o loose or strict options 248 o bandwidth admission control 250 o distributed vs. centralized model (PCE 251 [I-D.ietf-pce-stateful-pce], SDN Controller) 253 o disjointness in dual-plane networks 255 o egress peering traffic engineering 257 o load-balancing among non-parallel links (i.e.: links connected to 258 different adjacent neighbors). 260 o Limiting (scalable, preferably zero) per-service state and 261 signaling on midpoint and tail-end routers. 263 o ECMP-awareness 265 o node resiliency property (i.e.: the traffic-engineering policy is 266 not anchored to a specific core node whose failure could impact 267 the service. 269 In most cases, Traffic Engineering makes use of the "loose" route 270 option where most of the explicit paths can be expressed through a 271 small number of hops. However, there are use cases where the 272 "strict" option may be used and, in such case, each individual hop in 273 the explicit path is specified. This may incur into a long list of 274 hops that is instantiated into a MPLS label stack (in the MPLS 275 dataplane) or list of IPv6 addresses (in the IPv6 dataplane). 277 It is obvious that in case of long strict source routing paths, the 278 deployment is possible if the head-end of the explicit path supports 279 the instantiation of long explicit paths. 281 Alternatively, a controller could decompose the end-to-end path into 282 a set of sub-paths such as each of these sub-paths is supported by 283 its respective head-end and advertised with a single identifier. 284 Hence, the concatenation (or stitching) of the sub-paths identifiers 285 gives a compression scheme allowing an end-to-end path to be 286 expressed in a smaller number of hops. 288 3.3.1. Examples of Traffic Engineering Use Cases 290 Here follows the description of two sets of use cases: 292 o Traffic Engineering without Admission Control 294 o Traffic Engineering with Admission Control 296 3.3.1.1. Traffic Engineering without Bandwidth Admission Control 298 In this section, we describe Traffic Engineering use-cases without 299 bandwidth admission control. 301 3.3.1.1.1. Disjointness in dual-plane networks 303 Many networks are built according to the dual-plane design, as 304 illustrated in Figure 2: 306 Each aggregation region k is connected to the core by 307 two C routers C1k and C2k where k refers to the region. 309 C1k is part of plane 1 and aggregation region k 311 C2k is part of plane 2 and aggregation region k 313 C1k has a link to C2j iff k = j. 315 The core nodes of a given region are directly connected. 316 Inter-region links only connect core nodes of the same plane. 318 {C1k has a link to C1j} iff {C2k has a link to C2j}. 320 The distribution of these links depends on the topological 321 properties of the core of the AS. The design rule presented 322 above specifies that these links appear in both core planes. 324 We assume a common design rule found in such deployments: the inter- 325 plane link costs (Cik-Cjk where i != j) are set such that the route 326 to an edge destination from a given plane stays within the plane 327 unless the plane is partitioned. 329 Edge Router A 330 / \ 331 / \ 332 / \ Agg Region A 333 / \ 334 / \ 335 C1A----------C2A 336 | \ | \ 337 | \ | \ 338 | C1B----------C2B 339 Plane1 | | | | Plane2 340 | | | | 341 C1C--|-----C2C | 342 \ | \ | 343 \ | \ | 344 C1Z----------C2Z 345 \ / 346 \ / Agg Region Z 347 \ / 348 \ / 349 Edge Router Z 351 Figure 2: Dual-Plane Network and Disjointness 353 In this scenario, the operator requires the ability to deploy 354 different strategies. For example, Edge Router A should be able to 355 use the three following options: 357 o the traffic is load-balanced across any ECMP path through the 358 network 360 o the traffic is load-balanced across any ECMP path within the 361 Plane1 of the network 363 o the traffic is load-balanced across any ECMP path within the 364 Plane2 of the network 366 Most of the data traffic from A to Z would use the first option, such 367 as to exploit the capacity efficiently. The operator would use the 368 two other choices for specific premium traffic that has requested 369 disjoint transport. 371 The SPRING architecture MUST support this use case with the following 372 requirements: 374 o Zero per-service state and signaling on midpoint and tail-end 375 routers. 377 o ECMP-awareness. 379 o Node resiliency property: the traffic-engineering policy is not 380 anchored to a specific core node whose failure could impact the 381 service. 383 3.3.1.1.2. Egress Peering Traffic Engineering 385 +------+ 386 | | 387 +---D F 388 +---------+ / | AS 2 |\ +------+ 389 | |/ +------+ \| Z | 390 A C | | 391 | |\ +------+ /| AS 4 | 392 B AS1 | \ | |/ +------+ 393 | | +---E G 394 +---------+ | AS 3 | 395 +------+\ 397 Figure 3: Egress peering traffic engineering 399 Let us assume, in the network depicted in Figure 3, that: 401 C in AS1 learns about destination Z of AS 4 via two BGP paths 402 (AS2, AS4) and (AS3, AS4). 404 C may or may not be configured so to enforce next-hop-self 405 behavior before propagating the paths within AS1. 407 C may propagate all the paths to Z within AS1 (BGP add-paths, 408 [I-D.ietf-idr-add-paths]). 410 C may install in its FIB only the route via AS2, or only the route 411 via AS3, or both. 413 In that context, the SPRING architecture MUST allow the operator of 414 AS1 to apply a traffic-engineering policy such as the following one, 415 regardless the configured behavior of next-hop-self: 417 Steer 60% of the Z-destined traffic received at A via AS2 and 40% 418 via AS3. 420 Steer 80% of the Z-destined traffic received at B via AS2 and 20% 421 via AS3. 423 The SPRING architecture MUST allow an ingress node (i.e., an explicit 424 route source node) to select the exit point of a packet as any 425 combination of an egress node, an egress interface, a peering 426 neighbor, and a peering AS. 428 The use cases and requirements for Egress Peer Engineering are 429 described in [I-D.ietf-spring-segment-routing-central-epe]. 431 3.3.1.1.3. Load-balancing among non-parallel links 433 The SPRING architecture MUST allow a given node to load share traffic 434 across multiple non parallel links (i.e.: links connected to 435 different adjacent routers) even if these lead to different 436 neighbors. This may be useful to support traffic engineering 437 policies. 439 +---C---D---+ 440 | | 441 PE1---A---B-----F-----E---PE2 443 Figure 4: Multiple (non-parallel) Adjacencies 445 In the above example, the operator requires PE1 to load-balance its 446 PE2-destined traffic between the ABCDE and ABFE equal-cost paths in a 447 controlled way where the operator MUST be allowed to distribute 448 traffic unevenly between paths (Weighted Equal Cost Multiplath, 449 WECMP). 451 3.3.1.2. Traffic Engineering with Bandwidth Admission Control 453 The implementation of bandwidth admission control within a network 454 (and its possible routing consequence which consists in routing along 455 explicit paths where the bandwidth is available) requires a capacity 456 planning process. 458 The spreading of load among ECMP paths is a key attribute of the 459 capacity planning processes applied to packet-based networks. 461 3.3.1.2.1. Capacity Planning Process 463 Capacity Planning anticipates the routing of the traffic matrix onto 464 the network topology, for a set of expected traffic and topology 465 variations. The heart of the process consists in simulating the 466 placement of the traffic along ECMP-aware shortest-paths and 467 accounting for the resulting bandwidth usage. 469 The bandwidth accounting of a demand along its shortest-path is a 470 basic capability of any planning tool or PCE server. 472 For example, in the network topology described below, and assuming a 473 default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps 474 A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, 475 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 476 EF. 478 C-----D 479 / \ \ 480 A---B +--E--F--Z 481 \ / 482 G------+ 484 Figure 5: Capacity Planning an ECMP-based demand 486 ECMP is extremely frequent in SP, Enterprise and DC architectures and 487 it is not rare to see as much as 128 different ECMP paths between a 488 source and a destination within a single network domain. It is a key 489 efficiency objective to spread the traffic among as many ECMP paths 490 as possible. 492 This is illustrated in the below network diagram which consists of a 493 subset of a network where already 5 ECMP paths are observed from A to 494 M. 496 C 497 / \ 498 B-D-L-- 499 / \ / \ 500 A E \ 501 \ M 502 \ G / 503 \ / \ / 504 F K 505 \ / 506 I 508 Figure 6: ECMP Topology Example 510 When the capacity planning process detects that a traffic growth 511 scenario and topology variation would lead to congestion, a capacity 512 increase is triggered and if it cannot be deployed in due time, a 513 traffic engineering solution is activated within the network. 515 A basic traffic engineering objective consists of finding the 516 smallest set of demands that need to be routed off their shortest 517 path to eliminate the congestion, then to compute an explicit path 518 for each of them and instantiating these traffic-engineered policies 519 in the network. 521 The SPRING architecture MUST offer a simple support for ECMP-based 522 shortest path placement as well as for explicit path policy without 523 incurring additional signaling in the domain. This includes: 525 o the ability to steer a packet across a set of ECMP paths 527 o the ability to diverge from a set of ECMP shortest paths to one or 528 more paths not in the set of shortest paths 530 3.3.1.2.2. SDN Use Case 532 The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as 533 described in [I-D.ietf-pce-stateful-pce]. 535 The SDN controller is responsible to control the evolution of the 536 traffic matrix and topology. It accepts or denies the addition of 537 new traffic into the network. It decides how to route the accepted 538 traffic. It monitors the topology and upon topological change, 539 determines the minimum traffic that should be rerouted on an 540 alternate path to alleviate a bandwidth congestion issue. 542 The algorithms supporting this behavior are a local matter of the SDN 543 controller and are outside the scope of this document. 545 The means of collecting traffic and topology information are the same 546 as what would be used with other SDN-based traffic-engineering 547 solutions. 549 The means of instantiating policy information at a traffic- 550 engineering head-end are the same as what would be used with other 551 SDN-based traffic-engineering solutions. 553 In the context of Centralized-Based Optimization and the SDN use- 554 case, here are the functionalities that the SPRING architecture MUST 555 deliver: 557 Explicit routing capability with or without ECMP-awareness. 559 No signaling hop-by-hop through the network. 561 Policy state is only maintained at the policy head-end. No policy 562 state is maintained at mid-points and tail-ends. 564 Automated guaranteed FRR for any topology. 566 The policy state is in the packet header and not in the 567 intermediate nodes along the path. The policy is absent from 568 midpoints and tail-ends. 570 Highly responsive to change: the SDN Controller only needs to 571 apply a policy change at the head-end. No delay is introduced due 572 to programming the midpoints and tail-end along the path. 574 3.4. Interoperability with non-SPRING nodes 576 SPRING nodes MUST inter-operate with non-SPRING nodes and in both 577 MPLS and IPv6 dataplanes in order to allow a gradual deployment of 578 SPRING on existing MPLS and IPv6 networks. 580 4. Security Considerations 582 SPRING reuses the concept of source routing by encoding the path in 583 the packet. As with other similar source routing architecture, an 584 attacker may manipulate traffic path by modifying the packet header. 585 By manipulating traffic path, an attacker may be able to cause 586 outages on any part of the network. 588 SPRING adds some meta-data on the packet, with the list of forwarding 589 path elements that the packet must traverse. Depending on the data 590 plane, this list may shrink as the packet traverse the network, by 591 only keeping the next elements and forgetting the past ones. 593 SPRING architecture MUST provide clear trust domain boundaries, so 594 that source routing information is only usable within the trusted 595 domain and never exposed to the outside world. 597 From a network protection standpoint, there is an assumed trust model 598 such that any node imposing an explicit route on a packet is assumed 599 to be allowed to do so. This is a significant change compared to 600 plain IP offering shortest path routing but not fundamentally 601 different compared to existing techniques providing explicit routing 602 capability. It is expected that, by default, the explicit routing 603 information is not leaked through the boundaries of the administered 604 domain. 606 Therefore, the dataplane MUST NOT expose any source routing 607 information when a packet leaves the trusted domain. Special care 608 will be required for the existing dataplanes like MPLS, especially 609 for the inter-provider scenario where a third-party provider may push 610 MPLS labels corresponding to a SPRING header anywhere in the stack. 611 The architecture document MUST analyze the exact security 612 considerations of such scenario. 614 Filtering routing information is typically performed in the control 615 plane, but an additional filtering in the forwarding plane is also 616 required. In SPRING, as there is no control plane (related to source 617 routed paths) between the source and the mid points, filtering in the 618 control plane is not possible (or not required, depending on the 619 point of view). Filtering MUST be performed on the forwarding plane 620 on the boundaries and MAY require looking at multiple labels/ 621 instruction. 623 For the MPLS data plane, this not a new requirement as the existing 624 MPLS architecture already allow such source routing by stacking 625 multiple labels. And for security protection, RFC4381 section 2.4 626 and RFC 5920 section 8.2 already calls for the filtering of MPLS 627 packets on trust boundaries. 629 If all MPLS labels are filtered at domain boundaries, then SPRING 630 does not introduce any change. If only a subset of labels are 631 filtered, then SPRING introduces a change since the border router is 632 expected to determine which information (e.g.: labels) are filtered 633 while the border router is not the originator of these label 634 advertisements. 636 As the SPRING architecture must be based on clear trust domain, 637 mechanisms allowing the authentication and validation of the source 638 routing information must be evaluated by the SPRING architecture in 639 order to prevent any form of attack or unwanted source routing 640 information manipulation. 642 Dataplane security considerations MUST be addressed in each SPRING 643 dataplane related document (i.e.: MPLS and IPv6). 645 The IPv6 data plane proposes the use of a cryptographic signature of 646 the source routed path which would ease this configuration. This is 647 indeed more needed for the IPv6 data plane which is end to end in 648 nature, compared to the MPLS data plane which is typically restricted 649 to a controlled and trusted zone. 651 In the forwarding plane, data plane extension documents MUST address 652 the security implications of the required change. 654 In term of privacy, SPRING does not propose change in term of 655 encryption. Each dataplane, may or may not provide existing or 656 future encryption capability. 658 In order to build the source routing information in the packet, a 659 node in SPRING architecture will require learning information from a 660 control layer. As this control layer will be in charge of 661 programming forwarding instructions, an attacker taking over this 662 component may also manipulate the traffic path. Any control protocol 663 used in the SPRING architecture SHOULD provide security mechanisms or 664 design to protect against such control layer attacker. Control plane 665 security considerations MUST be addressed in each SPRING control 666 plane related document. 668 5. IANA Considerations 670 This document does not request any IANA allocations. 672 6. Manageability Considerations 674 The SPRING WG MUST define Operations and Management (OAM) procedures 675 applicable to SPRING enabled networks. 677 In SPRING networks, the path the packet takes is encoded in the 678 header. SPRING architecture MUST include the necessary OAM 679 mechanisms in order for the network operator to validate the 680 effectiveness of a path as well as to check and monitor its liveness 681 and performance. Moreover, in SPRING architecture, a path may be 682 defined in the forwarding layer (in both MPLS and IPv6 dataplanes) or 683 as a service path (formed by a set of service instances). The 684 network operator MUST be capable to monitor, control and manage paths 685 (network and service based) using OAM procedures. 687 OAM use cases and requirements are detailed in 688 [I-D.ietf-spring-oam-usecase] and 689 [I-D.ietf-spring-sr-oam-requirement]. 691 7. Contributors 693 The following individuals substantially contributed to the content of 694 this documents: 696 Ruediger Geib 697 Deutsche Telekom 698 Heinrich Hertz Str. 3-7 699 Darmstadt 64295 700 DE 701 Email: Ruediger.Geib@telekom.de 703 Robert Raszuk 704 Mirantis Inc. 705 615 National Ave. 706 94043 Mt View, CA 707 US 708 Email: robert@raszuk.net 710 8. Acknowledgements 712 The authors would like to thank Yakov Rekhter for his contribution to 713 this document. 715 9. References 717 9.1. Normative References 719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 720 Requirement Levels", BCP 14, RFC 2119, 721 DOI 10.17487/RFC2119, March 1997, 722 . 724 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 725 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 726 December 1998, . 728 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 729 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 730 2006, . 732 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 733 LAN Service (VPLS) Using BGP for Auto-Discovery and 734 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 735 . 737 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 738 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 739 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 740 . 742 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 743 Virtual Private Networks Using BGP for Auto-Discovery and 744 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 745 . 747 9.2. Informative References 749 [I-D.ietf-6man-segment-routing-header] 750 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 751 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 752 Routing Header (SRH)", draft-ietf-6man-segment-routing- 753 header-00 (work in progress), December 2015. 755 [I-D.ietf-idr-add-paths] 756 Walton, D., Retana, A., Chen, E., and J. Scudder, 757 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 758 add-paths-13 (work in progress), December 2015. 760 [I-D.ietf-pce-stateful-pce] 761 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 762 Extensions for Stateful PCE", draft-ietf-pce-stateful- 763 pce-13 (work in progress), December 2015. 765 [I-D.ietf-spring-oam-usecase] 766 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 767 Case for a Scalable and Topology-Aware Segment Routing 768 MPLS Data Plane Monitoring System", draft-ietf-spring-oam- 769 usecase-01 (work in progress), October 2015. 771 [I-D.ietf-spring-resiliency-use-cases] 772 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 773 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 774 resiliency-use-cases-02 (work in progress), December 2015. 776 [I-D.ietf-spring-segment-routing-central-epe] 777 Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, 778 "Segment Routing Centralized Egress Peer Engineering", 779 draft-ietf-spring-segment-routing-central-epe-00 (work in 780 progress), October 2015. 782 [I-D.ietf-spring-sr-oam-requirement] 783 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 784 and S. Litkowski, "OAM Requirements for Segment Routing 785 Network", draft-ietf-spring-sr-oam-requirement-01 (work in 786 progress), December 2015. 788 Authors' Addresses 790 Stefano Previdi (editor) 791 Cisco Systems, Inc. 792 Via Del Serafico, 200 793 Rome 00142 794 Italy 796 Email: sprevidi@cisco.com 797 Clarence Filsfils (editor) 798 Cisco Systems, Inc. 799 Brussels 800 BE 802 Email: cfilsfil@cisco.com 804 Bruno Decraene 805 Orange 806 FR 808 Email: bruno.decraene@orange.com 810 Stephane Litkowski 811 Orange 812 FR 814 Email: stephane.litkowski@orange.com 816 Martin Horneffer 817 Deutsche Telekom 818 Hammer Str. 216-226 819 Muenster 48153 820 DE 822 Email: Martin.Horneffer@telekom.de 824 Rob Shakir 825 Jive Communications, Inc. 826 1275 West 1600 North, Suite 100 827 Orem, UT 84057 829 Email: rjs@rob.sh