draft-ietf-spring-problem-statement-07.txt   draft-ietf-spring-problem-statement-08.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils, Ed. Internet-Draft C. Filsfils, Ed.
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: September 2, 2016 B. Decraene Expires: October 8, 2016 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
Jive Communications Jive Communications
March 1, 2016 April 6, 2016
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-ietf-spring-problem-statement-07 draft-ietf-spring-problem-statement-08
Abstract Abstract
The ability for a node to specify a forwarding path, other than the The ability for a node to specify a forwarding path, other than the
normal shortest path, that a particular packet will traverse, normal shortest path, that a particular packet will traverse,
benefits a number of network functions. Source-based routing benefits a number of network functions. Source-based routing
mechanisms have previously been specified for network protocols, but mechanisms have previously been specified for network protocols, but
have not seen widespread adoption. In this context, the term have not seen widespread adoption. In this context, the term
'source' means 'the point at which the explicit route is imposed' and 'source' means 'the point at which the explicit route is imposed' and
therefore it is not limited to the originator of the packet (i.e.: therefore it is not limited to the originator of the packet (i.e.:
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2016. This Internet-Draft will expire on October 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 11 skipping to change at page 5, line 11
In order to cope with the reality of current deployments, the SPRING In order to cope with the reality of current deployments, the SPRING
architecture MUST allow PE to PE forwarding according to the IGP architecture MUST allow PE to PE forwarding according to the IGP
shortest path without the addition of any other signaling protocol. shortest path without the addition of any other signaling protocol.
The packet each PE forwards across the network will contain the The packet each PE forwards across the network will contain the
necessary information derived from the topology database in order to necessary information derived from the topology database in order to
deliver the packet to the remote PE. deliver the packet to the remote PE.
3.2. Fast Reroute (FRR) 3.2. Fast Reroute (FRR)
FRR technologies have been deployed by network operators in order to FRR (Fast Reroute) technologies have been deployed by network
cope with link or node failures through pre-computation of backup operators in order to cope with link or node failures through pre-
paths. computation of backup paths.
Illustration of the problem statement for FRR and microloop avoidance
are to be found in [I-D.ietf-spring-resiliency-use-cases].
The SPRING architecture MUST address the following requirements: The SPRING architecture MUST address the following requirements:
o support of Fast Reroute (FRR) on any topology o support of Fast Reroute (FRR) on any topology
o pre-computation and setup of backup path without any additional o pre-computation and setup of backup path without any additional
signaling (other than the regular IGP/BGP protocols) signaling (other than the regular IGP/BGP protocols)
o support of shared risk constraints o support of shared risk constraints
o support of node and link protection o support of node and link protection
o support of microloop avoidance 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].
3.3. Traffic Engineering 3.3. Traffic Engineering
Traffic Engineering (TE) is the term used to refer to techniques that Traffic Engineering (TE) is the term used to refer to techniques that
enable operators to control how specific traffic flows are treated enable operators to control how specific traffic flows are treated
within their networks. Different contexts and modes have been within their networks. Different contexts and modes have been
defined (single vs. multiple domains, with or without bandwidth defined (single vs. multiple domains, with or without bandwidth
admission control, centralized vs. distributed path computation, admission control, centralized vs. distributed path computation,
etc). etc).
Some deployments have a limited use of TE such as addressing specific Some deployments have a limited use of TE such as addressing specific
skipping to change at page 16, line 48 skipping to change at page 16, line 48
Virtual Private Networks Using BGP for Auto-Discovery and Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<http://www.rfc-editor.org/info/rfc6624>. <http://www.rfc-editor.org/info/rfc6624>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing- Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-00 (work in progress), December 2015. header-01 (work in progress), March 2016.
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-13 (work in progress), December 2015. add-paths-13 (work in progress), December 2015.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-13 (work in progress), December 2015. pce-14 (work in progress), March 2016.
[I-D.ietf-spring-oam-usecase] [I-D.ietf-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
Case for a Scalable and Topology-Aware Segment Routing Case for a Scalable and Topology-Aware Segment Routing
MPLS Data Plane Monitoring System", draft-ietf-spring-oam- MPLS Data Plane Monitoring System", draft-ietf-spring-oam-
usecase-01 (work in progress), October 2015. usecase-01 (work in progress), October 2015.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir, Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
"Use-cases for Resiliency in SPRING", draft-ietf-spring- "Use-cases for Resiliency in SPRING", draft-ietf-spring-
resiliency-use-cases-02 (work in progress), December 2015. resiliency-use-cases-03 (work in progress), April 2016.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev,
"Segment Routing Centralized Egress Peer Engineering", "Segment Routing Centralized BGP Peer Engineering", draft-
draft-ietf-spring-segment-routing-central-epe-00 (work in ietf-spring-segment-routing-central-epe-01 (work in
progress), October 2015. progress), March 2016.
[I-D.ietf-spring-sr-oam-requirement] [I-D.ietf-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-ietf-spring-sr-oam-requirement-01 (work in Network", draft-ietf-spring-sr-oam-requirement-01 (work in
progress), December 2015. progress), December 2015.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
 End of changes. 10 change blocks. 
16 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/