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

Sfc Status Pages

Service Function Chaining (Active WG)
Rtg Area: Alia Atlas, Alvaro Retana, Deborah Brungard | 2013-Dec-20 —  
Chairs
 
 


2017-10-03 charter

Service Function Chaining (sfc)
-------------------------------

 Charter

 Current Status: Active

 Chairs:
     Jim Guichard <james.n.guichard@huawei.com>
     Joel M. Halpern <jmh@joelhalpern.com>

 Routing Area Directors:
     Alia Atlas <akatlas@gmail.com>
     Deborah Brungard <db3546@att.com>
     Alvaro Retana <aretana.ietf@gmail.com>

 Routing Area Advisor:
     Alia Atlas <akatlas@gmail.com>

 Secretary:
     Tal Mizrahi <talmi@marvell.com>

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

Description of Working Group:

  Network operators frequently utilize service functions such as packet
  filtering at firewalls, load-balancing and transactional proxies (for
  example spam filters) in the delivery of services to end users. Delivery
  of these types of services is undergoing significant change with the
  introduction of virtualization, network overlays, and orchestration.

  Deploying service functions to support service delivery is currently both
  a technical and an organizational challenge that involves significant
  modification to the network configuration, impacting the speed at which
  services can be deployed and increasing operational costs. Such
  services are typically implemented by the ordered combination of a
  number of service functions that are deployed at different points within
  a network.

  Today, common deployment models have service functions inserted on
  the data-forwarding path between communicating peers. Going forward,
  however, there is a need to move to a different model, where service
  functions, whether physical or virtualized, are not required to reside on
  the direct data path and traffic is instead steered through required
  service functions, wherever they are deployed.

  For a given service, the abstracted view of the required service
  functions and the order in which they are to be applied is called a
  Service Function Chain (SFC). An SFC is instantiated through selection
  of specific service function instances on specific network nodes to form
  a service graph: this is called a Service Function Path (SFP). The
  service functions may be applied at any layer within the network
  protocol stack (network layer, transport layer, application layer, etc.).

  The SFC working group will document a new approach to service delivery
  and operation. It will produce an architecture for service function
  chaining that includes the necessary protocols or protocol extensions to
  convey the Service Function Chain and Service Function Path information
  to nodes that are involved in the implementation of service functions
  and Service Function Chains, as well as mechanisms for steering traffic
  through service functions. The WG will examine existing identifier schemes,
  if there is a need for such identifiers in the context of the Generic SFC
  encapsulation, before defining any new identifier scheme.

  The working group will examine what information needs to be gathered
  from the network and service functions in support of Service Function
  Chaining and how that information may be made available to the
  components of the Service Function Chaining architecture. The SFC
  WG will closely consider and address the management and security
  implications when documenting these deliverables.

  Specifically, the SFC WG is chartered to deliver the following:

  1. Problem Statement: This document will provide a summary of the
     problem space to be addressed by the SFC working group including
     example high-level use cases. Additionally, the working group will
     normalize nomenclature and definitions for service function chaining.

  2. Architecture: This document will provide a description of the SFC
     architectural building blocks and their relationships including
     interconnection, placement of SFC specific capabilities, management,
     diagnostics, design analysis, and security models, as well as
     requirements on the protocol mechanisms.  The initial scope is
     restricted to a single administrative domain, keeping in mind that
     architectural decisions made for the intra-domain case may have
     implications for the inter-domain case.

  3. Generic SFC Encapsulation: This document will describe a single
     service-level data plane encapsulation format that:
     - indicates the sequence of service functions that make up the
       Service Function Chain
     - specifies the Service Function Path,
     - communicates context information between nodes that implement
       service functions and Service Function Chains.
     It is intended that the encapsulation format be agnostic to the
     layer at which it is applied and the service that is being
     constructed. That is, the same encapsulation may be used on a
     service function chain applied at the network layer or at any other
     layer, and the same encapsulation format will apply for the
     construction of Service Function Paths regardless of the actual
     service. The working group will consider using an existing
     encapsulation (with extensions as appropriate) if a suitable
     candidate is found.

  4. Control Plane Mechanisms: A document will be developed to describe
     requirements for conveying information between control or management
     elements and SFC implementation points. All protocol extension work
     resulting from these requirements should be carried out in the
     working group responsible for the protocol being modified in
     coordination with this working group, but may be done in this working
     group under a revised charter after agreement with all the relevant
     WG chairs and responsible ADs.

  5. Manageability: Work on the management and configuration of SFC
     components related to the support of Service Function Chaining will
     certainly be needed, but first needs to be better understood and
     scoped.

Goals and Milestones:
  Apr 2014 - Submit to IESG Information document defining the SFC problem statement and core use cases
  Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining
  Jan 2015 - Submit to IESG Informational document defining the architecture for SFC
  Jan 2015 - Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points
  Aug 2015 - Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation


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



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