draft-ietf-spring-problem-statement-01.txt   draft-ietf-spring-problem-statement-02.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: December 28, 2014 B. Decraene Expires: April 4, 2015 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
R. Geib
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
British Telecom British Telecom
R. Raszuk October 1, 2014
Individual
June 26, 2014
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-ietf-spring-problem-statement-01 draft-ietf-spring-problem-statement-02
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'. 'source' means 'the point at which the explicit route is imposed'.
skipping to change at page 2, line 10 skipping to change at page 2, line 7
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 December 28, 2014. This Internet-Draft will expire on April 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 42 skipping to change at page 2, line 39
3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 4 3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 4
4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 5 5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 5
5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 6 5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 6
5.1.1. Traffic Engineering without Bandwidth Admission 5.1.1. Traffic Engineering without Bandwidth Admission
Control . . . . . . . . . . . . . . . . . . . . . . . 6 Control . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Traffic Engineering with Bandwidth Admission Control 10 5.1.2. Traffic Engineering with Bandwidth Admission Control 10
6. Interoperability with non-SPRING nodes . . . . . . . . . . . 14 6. Interoperability with non-SPRING nodes . . . . . . . . . . . 14
7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Manageability Considerations . . . . . . . . . . . . . . . . 15 10. Manageability Considerations . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The ability for a node to specify a unicast forwarding path, other The ability for a node to specify a unicast forwarding path, other
than the normal shortest path, that a particular packet will than the normal shortest path, that a particular packet will
traverse, benefits a number of network functions, for example: traverse, benefits a number of network functions, for example:
Some types of network virtualization, including multi-topology Some types of network virtualization, including multi-topology
networks and the partitioning of network resources for VPNs networks and the partitioning of network resources for VPNs
skipping to change at page 5, line 35 skipping to change at page 5, line 35
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 Further illustrations of the problem statement for FRR are to be
found in [I-D.francois-spring-resiliency-use-case]. found in [I-D.ietf-spring-resiliency-use-cases].
5. Traffic Engineering 5. Traffic Engineering
Traffic Engineering has been addressed using IGP protocol extensions Traffic Engineering has been addressed using IGP protocol extensions
(for resources information propagation) and RSVP-TE for signaling (for resources information propagation) and RSVP-TE for signaling
explicit paths. Different contexts and modes have been defined explicit paths. Different contexts and modes have been defined
(single vs. multiple domains, with or without bandwidth admission (single vs. multiple domains, with or without bandwidth admission
control, centralized vs. distributed path computation, etc). control, centralized vs. distributed path computation, etc).
In all cases, one of the major components of the TE architecture is In all cases, one of the major components of the TE architecture is
skipping to change at page 9, line 50 skipping to change at page 9, line 50
In that context, SPRING should allow the operator of AS1 to apply the In that context, SPRING should allow the operator of AS1 to apply the
following traffic-engineering policy, regardless the configured following traffic-engineering policy, regardless the configured
behavior of next-hop-self: behavior of next-hop-self:
Steer 60% of the Z-destined traffic received at A via AS2 and 40% Steer 60% of the Z-destined traffic received at A via AS2 and 40%
via AS3. via AS3.
Steer 80% of the Z-destined traffic received at B via AS2 and 20% Steer 80% of the Z-destined traffic received at B via AS2 and 20%
via AS3. via AS3.
While egress routers are known in the routing domain (generally The SPRING architecture should allow an ingress node (or a source
through their loopback address), the SPRING architecture should node) to select the exit point of a packet as any combination of an
enable following: egress node, an egress interface, a peering neighbor, and a peering
AS.
o identify the egress interfaces of an egress node
o identify the peering neighbors of an egress node
o identify the peering ASes of an egress node
With these identifiers known in the domain, the SPRING architecture
should allow an ingress 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.
5.1.1.3. Load-balancing among non-parallel links 5.1.1.3. Load-balancing among non-parallel links
The SPRING architecture should allow a given node should be able to The SPRING architecture should allow a given node should be able to
load share traffic across multiple non parallel links even if these load share traffic across multiple non parallel links even if these
ones lead to different neighbors. This may be useful to support ones lead to different neighbors. This may be useful to support
traffic engineering policies. traffic engineering policies.
+---C---D---+ +---C---D---+
| | | |
skipping to change at page 15, line 17 skipping to change at page 15, line 5
TBD TBD
10. Manageability Considerations 10. Manageability Considerations
TBD TBD
11. Security Considerations 11. Security Considerations
TBD TBD
12. Acknowledgements 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 The authors would like to thank Yakov Rekhter for his contribution to
this document. this document.
13. References 14. References
13.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012. RFC 6564, April 2012.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013. of IPv6 Extension Headers", RFC 7045, December 2013.
13.2. Informative References 14.2. Informative References
[I-D.crabbe-pce-pce-initiated-lsp] [I-D.crabbe-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in
progress), October 2013. progress), October 2013.
[I-D.filsfils-spring-segment-routing] [I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring- "Segment Routing Architecture", draft-filsfils-spring-
segment-routing-03 (work in progress), June 2014. segment-routing-04 (work in progress), July 2014.
[I-D.filsfils-spring-segment-routing-ldp-interop] [I-D.filsfils-spring-segment-routing-ldp-interop]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing interoperability with LDP", draft- "Segment Routing interoperability with LDP", draft-
filsfils-spring-segment-routing-ldp-interop-01 (work in filsfils-spring-segment-routing-ldp-interop-02 (work in
progress), April 2014. progress), September 2014.
[I-D.filsfils-spring-segment-routing-mpls] [I-D.filsfils-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing with MPLS data plane", draft-filsfils- "Segment Routing with MPLS data plane", draft-filsfils-
spring-segment-routing-mpls-02 (work in progress), June spring-segment-routing-mpls-03 (work in progress), August
2014. 2014.
[I-D.filsfils-spring-segment-routing-use-cases] [I-D.filsfils-spring-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B., Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils- Crabbe, "Segment Routing Use Cases", draft-filsfils-
spring-segment-routing-use-cases-00 (work in progress), spring-segment-routing-use-cases-00 (work in progress),
March 2014. March 2014.
[I-D.francois-spring-resiliency-use-case]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
"Use-cases for Resiliency in SPRING", draft-francois-
spring-resiliency-use-case-02 (work in progress), April
2014.
[I-D.geib-spring-oam-usecase] [I-D.geib-spring-oam-usecase]
Geib, R. and C. Filsfils, "Use case for a scalable and Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
topology aware MPLS data plane monitoring system", draft- case for a scalable and topology aware MPLS data plane
geib-spring-oam-usecase-01 (work in progress), February monitoring system", draft-geib-spring-oam-usecase-02 (work
2014. in progress), July 2014.
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-04 (work in System", draft-ietf-i2rs-architecture-05 (work in
progress), June 2014. progress), July 2014.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-05 Information using BGP", draft-ietf-idr-ls-distribution-06
(work in progress), May 2014. (work in progress), September 2014.
[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-09 (work in progress), June 2014. 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] [I-D.kumar-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G.
Mirsky, "OAM Requirements for Segment Routing Network", Mirsky, "OAM Requirements for Segment Routing Network",
draft-kumar-spring-sr-oam-requirement-00 (work in draft-kumar-spring-sr-oam-requirement-01 (work in
progress), February 2014. progress), July 2014.
[I-D.sivabalan-pce-segment-routing] [I-D.sivabalan-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
R. Raszuk, "PCEP Extensions for Segment Routing", draft- Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions
sivabalan-pce-segment-routing-02 (work in progress), for Segment Routing", draft-sivabalan-pce-segment-
October 2013. routing-03 (work in progress), July 2014.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September Exchange of Flow Information", STD 77, RFC 7011, September
2013. 2013.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 18, line 18 skipping to change at page 18, line 24
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
Muenster 48153 Muenster 48153
DE DE
Email: Martin.Horneffer@telekom.de Email: Martin.Horneffer@telekom.de
Ruediger Geib
Deutsche Telekom
Heinrich Hertz Str. 3-7
Darmstadt 64295
DE
Email: Ruediger.Geib@telekom.de
Rob Shakir Rob Shakir
British Telecom British Telecom
London London
UK UK
Email: rob.shakir@bt.com Email: rob.shakir@bt.com
Robert Raszuk
Individual
Email: robert@raszuk.net
 End of changes. 24 change blocks. 
65 lines changed or deleted 60 lines changed or added

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