[secdir] [new-work] WG Review: Service Function Chaining (sfc)

[The IESG <[e-mail]>]

A new IETF working group has been proposed in the Routing Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-19.

Service Function Chaining (sfc)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Jim Guichard <[e-mail]>
  Thomas Narten <[e-mail]>

Assigned Area Director:
  Adrian Farrel <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: https://www.ietf.org/mailman/listinfo/nsc
  Archive: http://www.ietf.org/mail-archive/web/nsc/

Charter:

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.

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


_______________________________________________
new-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work