draft-previdi-spring-problem-statement-03.txt   draft-previdi-spring-problem-statement-04.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: October 20, 2014 B. Decraene Expires: October 26, 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
April 18, 2014 April 24, 2014
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-previdi-spring-problem-statement-03 draft-previdi-spring-problem-statement-04
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 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 October 20, 2014. This Internet-Draft will expire on October 26, 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 2, line 39 skipping to change at page 2, line 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . 4 3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . 13 6. Interoperability with non-SPRING nodes . . . . . . . . . . . 14
7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Manageability Considerations . . . . . . . . . . . . . . . . 14 10. Manageability Considerations . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 15 13.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:
skipping to change at page 9, line 16 skipping to change at page 9, line 16
o Node resiliency property: the traffic-engineering policy is not o Node resiliency property: the traffic-engineering policy is not
anchored to a specific core node whose failure could impact the anchored to a specific core node whose failure could impact the
service. service.
5.1.1.2. Egress Peering Traffic Engineering 5.1.1.2. Egress Peering Traffic Engineering
+------+ +------+
| | | |
+---D F +---D F
+---------+ / | AS 2 |\ +------+ +---------+ / | AS 2 |\ +------+
| X |/ +------+ \ | Z |---L/8 | |/ +------+ \| Z |
A C---+ \| | A C | |
| |\\ \ +------+ /| AS 4 |---M/8 | |\ +------+ /| AS 4 |
| AS1 | \\ +-H |/ +------+ B AS1 | \ | |/ +------+
| | \\ | G | | +---E G
+----P----+ +===E AS 3 | +---------+ | AS 3 |
| +--Q---+ +------+\
| |
+----------------+
Figure 3: Reference Diagram Figure 3: Egress peering traffic engineering
Assuming the topology illustrated in the diagram above, a solution is Let us assume, in the network depicted in Figure 3, that:
required to allow a centralized controller to force an ingress PE or
a content source to use a specific egress PE and a specific egress
interface of that egress PE to reach some destination. We call this
solution "EPE" for "Egress Peer Engineering".
For example, the solution MUST provide a mechanism in order to C in AS1 learns about destination Z of AS 4 via two BGP paths
instruct node A to prefer C-H link for destination L/8 and prefer the (AS2, AS4) and (AS3, AS4).
parallel links between C and E for destination M/8.
The solution MUST apply to the Internet use-case where the Internet C may or may not be configured so to enforce next-hop-self
routes are assumed to use IPv4 unlabeled. The solution MUST NOT behavior before propagating the paths within AS1.
require to place the internet routes in a VRF and allocate labels on
a per route, per-path basis.
The solution MUST NOT make assumption in the way iBGP scheme is C may propagate all the paths to Z within AS1 (add-path).
deployed (RRs, Confederations or iBGP full mesh).
C may install in its FIB only the route via AS2, or only the route
via AS3, or both.
In that context, SPRING should allow the operator of AS1 to apply the
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%
via AS3.
Steer 80% of the Z-destined traffic received at B via AS2 and 20%
via AS3.
While egress routers are known in the routing domain (generally
through their loopback address), the SPRING architecture should
enable following:
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 47 skipping to change at page 16, line 17
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-rtgwg- "Segment Routing Architecture", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), October 2013. segment-routing-01 (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", draft- "Segment Routing interoperability with LDP", draft-
filsfils-spring-segment-routing-ldp-interop-00 (work in filsfils-spring-segment-routing-ldp-interop-01 (work in
progress), October 2013. progress), April 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-00 (work in progress), October spring-segment-routing-mpls-01 (work in progress), April
2013. 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] [I-D.francois-spring-resiliency-use-case]
 End of changes. 14 change blocks. 
38 lines changed or deleted 56 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/