draft-previdi-spring-problem-statement-01.txt   draft-previdi-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: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: September 29, 2014 B. Decraene Expires: October 6, 2014 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
R. Geib R. Geib
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
British Telecom British Telecom
R. Raszuk R. Raszuk
Individual Individual
March 28, 2014 April 4, 2014
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-previdi-spring-problem-statement-01 draft-previdi-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'.
This document outlines various use cases, with their requirements, This document outlines various use cases, with their requirements,
that need to be taken into account by the Source Packet Routing in that need to be taken into account by the Source Packet Routing in
Networking (SPRING) architecture. Networking (SPRING) architecture for unicast traffic. Multicast use-
cases and requirements are out of scope of this document.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
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 29, 2014. This Internet-Draft will expire on October 6, 2014.
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 4, line 7 skipping to change at page 4, line 7
10. Manageability Considerations . . . . . . . . . . . . . . . . . 15 10. Manageability Considerations . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The ability for a node to specify a forwarding path, other than the The ability for a node to specify a unicast forwarding path, other
normal shortest path, that a particular packet will traverse, than the normal shortest path, that a particular packet will
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
Network, link, path and node protection such as fast re-route Network, link, path and node protection such as fast re-route
Network programmability Network programmability
OAM techniques OAM techniques
skipping to change at page 4, line 49 skipping to change at page 4, line 49
2. Dataplanes 2. Dataplanes
The SPRING architecture should be general in order to ease its The SPRING architecture should be general in order to ease its
applicability to different dataplanes. applicability to different dataplanes.
MPLS dataplane doesn't require any modification in order to apply a MPLS dataplane doesn't require any modification in order to apply a
source-based routed model (e.g.: source-based routed model (e.g.:
[I-D.filsfils-spring-segment-routing-mpls]). [I-D.filsfils-spring-segment-routing-mpls]).
IPv6 specification [RFC2460] defines the Routing Extension Header IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045],
which provides IPv6 source-based routing capabilities. defines the Routing Extension Header which provides IPv6 source-based
routing capabilities.
The SPRING architecture should leverage existing MPLS dataplane The SPRING architecture should leverage existing MPLS dataplane
without any modification and leverage IPv6 dataplane with minor without any modification and leverage IPv6 dataplane with minor
modifications. modifications.
3. IGP-based MPLS Tunneling 3. IGP-based MPLS Tunneling
The source-based routing model, applied to the MPLS dataplane, offers The source-based routing model, applied to the MPLS dataplane, offers
the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE
to an egress PE, without any other protocol than IGPs (ISIS or OSPF). to an egress PE, with or without the expression of an explicit path
LDP and RSVP-TE signaling protocols are not required. and without requiring forwarding plane or control plane state in
intermediate nodes.
3.1. Example of IGP-based MPLS Tunnels 3.1. Example of IGP-based MPLS Tunnels
This section illustrates an example use-case taken from This section illustrates an example use-case taken from
[I-D.filsfils-rtgwg-segment-routing-use-cases]. [I-D.filsfils-spring-segment-routing-use-cases].
P1---P2 P1---P2
/ \ / \
A---CE1---PE1 PE2---CE2---Z A---CE1---PE1 PE2---CE2---Z
\ / \ /
P3---P4 P3---P4
Figure 1: IGP-based MPLS Tunneling Figure 1: IGP-based MPLS Tunneling
In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 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 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 label LZ to that route and propagates the route and its label via
MPBGP to PE1 with nhop 192.168.0.2. PE1 installs the VPN prefix Z in MPBGP to PE1 with nhop 192.168.0.2. PE1 installs the VPN prefix Z in
the appropriate VRF and resolves the next-hop onto the node segment the appropriate VRF and resolves the next-hop onto the node segment
associated with PE2. Upon receiving a packet from A destined to Z, associated with PE2.
PE1 pushes two labels onto the packet: the top label is the Prefix
SID attached to 192.168.0.2/32, the bottom label is the VPN label LZ
attached to the VPN route Z.
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 should allow PE to PE forwarding according to the IGP architecture should 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 (within The packet each PE forwards across the network will contain (within
their label stack) the necessary information derived from the their label stack) the necessary information derived from the
topology database in order to deliver the packet to the remote PE. topology database in order to deliver the packet to the remote PE.
4. Fast Reroute 4. Fast Reroute
skipping to change at page 7, line 4 skipping to change at page 6, line 49
The source-based routing model allows traffic engineering to be The source-based routing model allows traffic engineering to be
implemented without the need of a signaling component. implemented without the need of a signaling component.
The SPRING architecture should support traffic engineering, The SPRING architecture should support traffic engineering,
including: including:
o loose or strict options o loose or strict options
o bandwidth admission control o bandwidth admission control
o distributed vs. centralized model (PCE, SDN Controller)
o distributed vs. centralized model (PCE, SDN Controller)
o disjointness in dual-plane networks o disjointness in dual-plane networks
o egress peering traffic engineering o egress peering traffic engineering
o load-balancing among non-parallel links o load-balancing among non-parallel links
o Limiting (scalable, preferably zero) per-service state and o Limiting (scalable, preferably zero) per-service state and
signaling on midpoint and tail-end routers. signaling on midpoint and tail-end routers.
o ECMP-awareness o ECMP-awareness
o node resiliency property (i.e.: the traffic-engineering policy is o node resiliency property (i.e.: the traffic-engineering policy is
not anchored to a specific core node whose failure could impact not anchored to a specific core node whose failure could impact
the service. the service.
5.1. Examples of Traffic Engineering Use Cases 5.1. Examples of Traffic Engineering Use Cases
As documented in [I-D.filsfils-rtgwg-segment-routing-use-cases] here As documented in [I-D.filsfils-spring-segment-routing-use-cases] here
follows the description of two sets of use cases: follows the description of two sets of use cases:
o Traffic Engineering without Admission Control o Traffic Engineering without Admission Control
o Traffic Engineering with Admission Control o Traffic Engineering with Admission Control
5.1.1. Traffic Engineering without Bandwidth Admission Control 5.1.1. Traffic Engineering without Bandwidth Admission Control
In this section, we describe Traffic Engineering use-cases without In this section, we describe Traffic Engineering use-cases without
bandwidth admission control. bandwidth admission control.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
+---------+ | AS 3 | +---------+ | AS 3 |
+------+\ +------+\
Figure 3: Egress peering traffic engineering Figure 3: Egress peering traffic engineering
Let us assume, in the network depicted in Figure 3, that: Let us assume, in the network depicted in Figure 3, that:
C in AS1 learns about destination Z of AS 4 via two BGP paths C in AS1 learns about destination Z of AS 4 via two BGP paths
(AS2, AS4) and (AS3, AS4). (AS2, AS4) and (AS3, AS4).
C sets next-hop-self before propagating the paths within AS1. C may or may not be configured so to enforce next-hop-self
behavior before propagating the paths within AS1.
C propagates all the paths to Z within AS1 (add-path). C propagates all the paths to Z within AS1 (add-path).
C only installs the path via AS2 in its RIB. C only installs the path via AS2 in its RIB.
In that context, the operator of AS1 cannot apply the following In that context, SPRING should allow the operator of AS1 to apply the
traffic-engineering policy: following traffic-engineering policy, regardless the configured
behavior of next-hop-self:
Steer 60% of the Z-destined traffic received at A via AS2 and 40% 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 While egress routers are known in the routing domain (generally
through their loopback address), the SPRING architecture should through their loopback address), the SPRING architecture should
enable following: enable following:
skipping to change at page 15, line 41 skipping to change at page 15, line 41
10. Manageability Considerations 10. Manageability Considerations
TBD TBD
11. Security Considerations 11. Security Considerations
TBD TBD
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Robert Raszuk and Yakov Rekhter for The authors would like to thank Yakov Rekhter for his contribution to
their contribution to this document. this document.
13. References 13. References
13.1. Normative References 13.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
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012.
[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, Exchange of Flow Information", STD 77, RFC 7011,
September 2013. September 2013.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013.
13.2. Informative References 13.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-rtgwg-segment-routing] [I-D.filsfils-rtgwg-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", "Segment Routing Architecture",
draft-filsfils-rtgwg-segment-routing-01 (work in draft-filsfils-rtgwg-segment-routing-01 (work in
progress), October 2013. progress), October 2013.
[I-D.filsfils-rtgwg-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases",
draft-filsfils-rtgwg-segment-routing-use-cases-02 (work in
progress), October 2013.
[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", "Segment Routing interoperability with LDP",
draft-filsfils-spring-segment-routing-ldp-interop-00 (work draft-filsfils-spring-segment-routing-ldp-interop-00 (work
in progress), October 2013. in progress), October 2013.
[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", "Segment Routing with MPLS data plane",
draft-filsfils-spring-segment-routing-mpls-00 (work in draft-filsfils-spring-segment-routing-mpls-00 (work in
progress), October 2013. progress), October 2013.
[I-D.filsfils-spring-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases",
draft-filsfils-spring-segment-routing-use-cases-00 (work
in progress), March 2014.
[I-D.francois-spring-resiliency-use-case] [I-D.francois-spring-resiliency-use-case]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir, Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
"Use-cases for Resiliency in Segment Routing", "Use-cases for Resiliency in SPRING",
draft-francois-spring-resiliency-use-case-00 (work in draft-francois-spring-resiliency-use-case-01 (work in
progress), January 2014. 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. and C. Filsfils, "Use case for a scalable and
topology aware MPLS data plane monitoring system", topology aware MPLS data plane monitoring system",
draft-geib-spring-oam-usecase-01 (work in progress), draft-geib-spring-oam-usecase-01 (work in progress),
February 2014. February 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
 End of changes. 21 change blocks. 
35 lines changed or deleted 44 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/