* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Spring Status Pages

Source Packet Routing in Networking (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2013-Oct-25 —  

2018-03-23 charter

Source Packet Routing in Networking (spring)


 Current Status: Active

     Bruno Decraene <bruno.decraene@orange.com>
     Rob Shakir <robjs@google.com>

 Routing Area Directors:
     Deborah Brungard <db3546@att.com>
     Alvaro Retana <aretana.ietf@gmail.com>
     Martin Vigoureux <martin.vigoureux@nokia.com>

 Routing Area Advisor:
     Martin Vigoureux <martin.vigoureux@nokia.com>

 Mailing Lists:
     General Discussion: spring@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/spring
     Archive:            https://mailarchive.ietf.org/arch/browse/spring/

Description of 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
  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

  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.

Goals and Milestones:
  Done     - One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.
  Done     - One or more documents describing SPRING use cases.
  Done     - Specification of a high-level abstract architecture for SPRING.
  Done     - One or more control protocol extensions requirements documents.
  Jan 2016 - Inter-operability reports pertaining to the implementation of extensions supporting SPRING.
  Apr 2016 - Requirements for modifications if any to MPLS architecture to support SPRING use cases.
  Apr 2016 - Requirements for modifications if any to IPv6 architecture to support SPRING use cases.
  Done     - Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols.
  Aug 2016 - Specify the OAM mechanisms needed to support SPRING.
  Aug 2016 - SPRING YANG model submitted to IESG
  Nov 2016 - Recharter or close WG.

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/spring/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -