* 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 —  

2020-06-14 charter

Source Packet Routing in Networking (spring)


 Current Status: Active

     Bruno Decraene <bruno.decraene@orange.com>
     Jim Guichard <james.n.guichard@futurewei.com>
     Joel M. Halpern <jmh@joelhalpern.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>

     Shuping Peng <pengshuping@huawei.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 Source Packet Routing in NetworkinG (SPRING) Working Group is the
  home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).
  SPRING WG serves as a forum to discuss SPRING networks operations,
  define new applications of, and specify extensions of Segment Routing

  SPRING WG 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 should be carried out in the
  WGs responsible for the architecture, data plane, or control or
  management plane protocol being modified and in coordination with the
  SPRING WG, but may be done in SPRING WG after agreement with all the
  relevant WG chairs and responsible Area Directors.

  The SPRING WG defines procedures that allow a node to steer a packet
  through an SR Policy instantiated as an ordered list of instructions
  called segments 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 nodes must inter-operate through loose routing in
  existing networks and may find it advantageous to use loose routing for
  other network applications.

  The scope of the SPRING WG work includes both single Autonomous System
  (AS) and multi-AS environments. Segment Routing typically operates within
  a single trust domain which requires the enforcement of a strict boundary
  and preventing Segment Routing packets from entering the trusted domain
  from the untrusted exterior.  Certain deployments may however involve
  multiple trust domains which in turn may imply the use of cross/inter
  domain segments. Risk models associated with these various scenarios may
  necessitate the use of a cryptographic integrity checks to validate that
  the segment list is provided by an authorised entity.
  As is customary in the Routing Area, the SPRING WG will also identify and
  address any other security considerations introduced by the technologies
  it defines; addressing such considerations may require the introduction of
  new functionality in protocols leveraged for Source Routing, in which case
  the SPRING WG will formulate requirements to be considered by the
  appropriate WG for that work.  The SPRING WG is however not expected to
  wait on the development of a solution to these requirements before
  progressing its own documents.  SPRING technologies may be deployed in
  environments spanning a range of risk and threat models, which may impact
  both the security considerations and the requirements placed on other
  protocols in order to support Source Routing protocols.

  The technologies SPRING WG defines may be applicable to both centralised
  and distributed path computation.

  The SPRING WG will manage its specific work items by milestones agreed
  with the responsible Area Director.

  The work-items of the SPRING WG include functional specifications for:
  o Segment Routing policies and the associated steering, signalling and
  traffic engineering mechanisms.

  o Source-routed stateless service chaining using SR-MPLS and SRv6

  o SRv6 network programming for the underlay networks and overlay
  services, and including data plane behavior and functions associated
  with SIDs

  o Operation, Administration and Management (OAM), and traffic accounting
  in networks with SR-MPLS and SRv6 data planes in the case where SR
  introduces specificities compared to MPLS or IPv6 technologies.

  o Performance Management (PM) and monitoring in networks with SR-MPLS
  and SRv6 data planes in the case where SR introduces specificities
  compared to MPLS or IPv6 technologies.

  o Inter-working between SRv6 and SR-MPLS and between SR and existing
  routing solutions to allow for seamless deployment and co-existence.

  o New types of segments mapping to forwarding behaviour (e.g., local
  ingress replication, local forwarding resources, a pre-existing
  replication structure) if needed for new usages.

  Any of the above may require architectural extensions.

  The work-items of SPRING WG also include:
  o Specification of management models (YANG) for Segment Routing
  applications, services and networks with SR-MPLS and SRv6 dataplanes.

  The SPRING WG will coordinate and collaborate with other WGs as needed.
  Specific expected interactions include (but may not be limited to):

   * mpls on the MPLS dataplane and OAM extensions,
   * 6man on the IPv6 dataplane for SR and associated OAM extensions
   * lsr on OSPF and IS-IS extensions to flood SPRING-related information
   * idr for BGP extensions
   * bess for VPN control plane
   * pce on extensions to communicate with an external entity to compute
     and program SPRING paths
   * teas on generic traffic engineering architecture
   * sfc on service chaining applications
   * rtgwg on fast-reroute technologies

Goals and Milestones:
  Oct 2018 - MPLS anycast sent to IESG
  Dec 2018 - SR-MPLS configuration YANG model sent to IESG
  Jul 2019 - SR-TE policy sent to IESG
  Jul 2019 - SR-MPLS OAM sent to IESG
  Jul 2019 - SR-MPLS Performance Measurement to IESG
  Jul 2019 - SR-IPv6 OAM sent to IESG
  Dec 2019 - SRv6 Network Programming to IESG
  Dec 2019 - SR policies YANG model sent to IESG
  Dec 2019 - Stateless service chaining with SR sent to IESG
  Done     - SR-MPLS sent to IESG

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 -