Source Packet Routing in Networking (spring)

WG Name Source Packet Routing in Networking
Acronym spring
Area Routing Area (rtg)
State Active
Charter charter-ietf-spring-01 Approved
Dependencies Document dependency graph (SVG)
Additional URLs Wiki
Issue tracker
Personnel Chairs Bruno Decraene
Martin Vigoureux
Area Director Alvaro Retana
Mailing list Address spring@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/spring
Archive https://mailarchive.ietf.org/arch/browse/spring/
Jabber chat Room address xmpp:spring@jabber.ietf.org?join
Logs https://jabber.ietf.org/logs/spring/

Charter for Working Group

The ability for a node to specify a forwarding path, other
than the normal shortest path, that a particular packet
will traverse, benefits a number of network functions,
for example:

o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs
o Network path and node protection such as fast re-route
o Network programmability
o New OAM techniques
o Simplification and reduction of network signalling
components
o Load balancing and traffic engineering

Source-based routing mechanisms have previously been
specified for network protocols, but have not seen
widespread adoption other than in MPLS traffic engineering.
These network functions may require greater flexibility and
per packet source imposed routing than can be achieved
through the use of the previously defined methods. In the
context of this charter, 'source' means 'the point at
which the explicit route is imposed'.

The SPRING working group will define procedures that
will allow a node to steer a packet along an explicit
route using information attached to the packet and
without the need for per-path state information to be
held at transit nodes. Full explicit control (through loose
or strict path specification) can be achieved in a network
comprising only SPRING nodes, however SPRING must
inter-operate through loose routing in existing networks
and may find it advantageous to use loose routing for
for other network applications.

The initial data planes that will be considered are MPLS
and IPv6.

There is an assumed trust model such that any node
imposing an explicit route on a packet is assumed to
be allowed to do so, however administrative and trust
boundaries may strip explicit routes from a packet.
For each data plane technology that SPRING specifies,
a security analysis must be provided showing how protection
is provided against an attacker disrupting the network by
for example, maliciously injecting SPRING packets.
There are a number of serious security concerns with
source routing at the IP layer [RFC 5095]. As a part
of its work, the working group will define the new
IPv6-based routing header in way that blind attacks
are never possible, i.e., attackers will be unable to
send source routed packets that get successfully
processed, without being part of the negotiation for
setting up the source routes or being able to eavesdrop
legitimate source routed packets. In some networks
this base level security may be complemented with
other mechanisms, such as packet filtering, cryptographic
security, etc.

Initial work will focus on SPRING within in a single AS,
however design decisions must not preclude operation
of SPRING across AS boundaries. In such multi-AS
deployments, the previously-stated trust model would
still apply.

SPRING should support both centralised and distributed
path computation.

The SPRING WG should provide OAM and the
management needed to manage SPRING enabled networks.
The SPRING procedures may also be used as a tool for OAM
in SPRING enabled networks.

SPRING should avoid modification to existing data
planes that would make them incompatible with
existing deployments. Where possible, existing control
and management plane protocols must be used within existing
architectures to implement the SPRING function. Any
modification of or extension to existing architectures,
data planes, or control or management plane protocols
must be carried out in the working groups responsible
for the architecture, data plane, or control or
management plane protocol being modified and in
co-ordination with this working group, but may be
done in this working group after agreement with
all the relevant WG chairs and responsible Area Directors.

The SPRING working group is chartered for the following
list of items:

o Identification and evaluation of use cases for SPRING.
These use cases must include a definition of the
data plane for the environment in which they are to be
deployed.

o Definition of requirements for any new data plane
encodings and procedures, required to implement
the use cases. Such procedures must include the
necessary security considerations.

o Definition of requirements and if necessary any
new control plane mechanism needed to enable
the use cases.

o Definition of requirements and if necessary management
plane mechanisms needed to manage and operate a
SPRING enabled network.

The SPRING working group will not work on any
mechanisms for use in networks that forward IPv4 packets.

Milestones

Date Milestone
Nov 2016 Recharter or close WG.
Aug 2016 Specify the OAM mechanisms needed to support SPRING.
draft-ietf-spring-sr-oam-requirement
draft-kumarkini-mpls-spring-lsp-ping
Apr 2016 Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols.
draft-ietf-spring-segment-routing-ldp-interop
Apr 2016 Requirements for modifications if any to IPv6 architecture to support SPRING use cases.
draft-ietf-spring-ipv6-use-cases
draft-ietf-spring-segment-routing
draft-previdi-6man-segment-routing-header
Apr 2016 Requirements for modifications if any to MPLS architecture to support SPRING use cases.
draft-ietf-spring-segment-routing-mpls
Jan 2016 Inter-operability reports pertaining to the implementation of extensions supporting SPRING.
Dec 2015 One or more control protocol extensions requirements documents.
draft-ietf-spring-segment-routing
Dec 2015 Specification of a high-level abstract architecture for SPRING.
draft-ietf-spring-segment-routing
Done One or more documents describing SPRING use cases.
draft-ietf-spring-problem-statement
Jul 2015 One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.

1 new milestone currently in Area Director review.