Subject: [nsc] Time to get to work!

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Dec 2013 18:03:40 -0000

All systems go. Please work according to your charter under the guidance of your
chairs.

For the enquiring mind...
We will migrate the list to sfc@... when the Secretariat gets back after the New
Year break.
>From my experience, this is pretty painless.

Adrian

> -----Original Message-----
> From: nsc [mailto:[email-masked]] On Behalf Of The IESG
> Sent: 20 December 2013 17:13
> To: IETF-Announce
> Cc: sfc WG
> Subject: [nsc] WG Action: Formed Service Function Chaining (sfc)
> 
> A new IETF working group has been formed in the Routing Area. For
> additional information please contact the Area Directors or the WG
> Chairs.
> 
> Service Function Chaining (sfc)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>   Jim Guichard <[email-masked]>
>   Thomas Narten <[email-masked]>
> 
> Assigned Area Director:
>   Adrian Farrel <[email-masked]>
> 
> Mailing list
>   Address: [email-masked]
>   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
> 
> 
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc