Subject: [nsc] Back to the charter ...

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 6 Sep 2013 17:36:21 +0000

Folks,

Here is the current version of the charter. Please be encouraged to review further and add comments. I would especially welcome those subscribers on the list that have yet to comment – we have at current count 299 subscribers so I know you are out there ;-) :

Proposed NSC WG Charter

Existing service insertion and deployment techniques fail to address new challenging requirements raised by the introduction of emerging technologies such as multi-tenancy, virtualization, elasticity, and rich classification. Networks, servers, and other storage technologies, let alone applications, have all undergone significant change in recent years: virtualization, network overlays, and orchestration have increasingly become techniques that count and sometimes prevail. All of these have profound effects on network and services design.

Today, deploying new services, or making changes to existing services, often requires network topology changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading to massively static configuration procedures for network service delivery or update purposes. The structuring and the delivery of new network services assume the (smart) combination of various service functions as shared resources, and enable the linkage of these resources using service function chains that represent the abstracted view of the required service functions, and define the order in which they should be invoked. Such (smart) combinations could be made of heterogeneous service functions which may act at various layers of a protocol stack (network layer, application layer, etc). When a service function chain is instantiated in a network, specific instances of service functions are selected, and a service topology is created and used for forwarding packets according to the service function chain.

A basic service function chain might simply utilize an existing overlay technology to force traffic through the necessary service functions. However, additional information that is shared across a subset of service functions may enable a richer service function chain for more advanced composite services. For example, shared information, such as the results of a classification function, may be passed to downstream service functions to enable the offloading of service function processing or to share information that would otherwise be hard to glean.

The Network Service Chaining (NSC) working group focuses on new and simpler approaches to network service structuring, insertion, and deployment, providing a framework for the construction of services built using service function chains. The WG focuses on the necessary protocols for management (e.g. create, delete, monitor) of service function chains, and the transmission of network and service-specific information from the network to service functions, and between service functions. When possible, the WG will extend existing protocols to provide service chaining functionality, and any protocol extensions will be reviewed by both the Network Service Chaining WG and by the WG responsible for the protocol being extended.

Specifically, the Network Service Chaining WG is chartered to deliver the following work items:

1) Problem Statement: this document will provide a summary of the problem space to be addressed by the Network Service Chaining WG including example high-level use cases.  Additionally, the WG will normalize on nomenclature and definitions for service function chaining.

2) System Architecture: this set of documents will provide a description of the architecture building blocks and their relationships including interconnection, placement of capabilities, and security models, as well as requirements on the control mechanisms and data plane encapsulation.

3) Service Function Chaining Data & Control Plane: A data plane document will describe on the wire data plane encapsulation in support of (2). A single service-level encapsulation will be selected in order to enable interoperability of data plane components, which can in turn be carried in various transport encapsulations (e.g., IP, MPLS, or other overlays). Supporting control plane protocol elements will be added as needed (as a separate document).

4) Manageability: this document will address service function chaining management in support of (2) including relevant MIBs and YANG information models, and service function chaining OAM.

Proposed Milestones:

Dec 2013 Request publication of an Informational document defining the Network Service Function Chaining problem statement to the IESG

Mar 2014 Request publication of informational documents defining the system architecture including protocol requirements and framework to the IESG

May 2014 Request publication of a Standards Track document specifying the data-plane service-level encapsulation (including context data) for Service Function Chaining to IESG

May 2014 Request publication of an informational document specifying Service Function Chaining Control Plane requirements to IESG

Dec 2014 Request publication of Informational document(s) defining Network Service Function Chaining use cases to IESG

Dec 2014 Request publication of informational documents defining Service Function Chaining manageability including MIBs, OAM, and YANG information models to IESG

---

From: Kevin Glavin <[email-masked]>
Date: Mon, 9 Sep 2013 20:53:26 +0000

Jim,

With regards to the 'meta data' that may be shunted along the service chain, is there any proposal to work on some minimum level of standardization of this data with the scope of this charter?
I assume that as a chain could/would be populated with service logic from multiple vendors then a base set of capabilities within the meta data would make initial adaption easier?

If so is this part of (3) below, or is it something else that may need to be added to the target deliverables?

The flip side of this is that this meta data may be tied to specific use cases and as such would be handled in that sphere and considered outside the scope of the current work deliverables.

Kevin

From: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 6, 2013 10:36 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [nsc] Back to the charter ...

Folks,

Proposed NSC WG Charter

…..

……

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 10 Sep 2013 09:19:14 +0000

Hi Jim,

Please see my inline comments on the new charter.

Cheers,
Yuanlong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, September 07, 2013 1:36 AM
To: [email-masked]
Subject: [nsc] Back to the charter ...

Folks,

Here is the current version of the charter. Please be encouraged to review further and add comments. I would especially welcome those subscribers on the list that have yet to comment - we have at current count 299 subscribers so I know you are out there ;-) :

Proposed NSC WG Charter

[JY] I would expect most nomenclature and definitions for service function chaining shall appear in the architecture document.

[JY] Data plane of service chaining may cover more topics than encapsulation, could we remove "encapsulation" from the above texts to generalize it?

[JY] Same comment as 2), can we generalize the description of the data plane document?

[JY] According to RFC 3444, information models are high level "abstract models", while MIB and YANG are detailed data models. Thus it is proposed to replace "relevant MIBs and YANG information models" with "information models, relevant MIBs and YANG data models".

Proposed Milestones:

Dec 2014 Request publication of informational documents defining Service Function Chaining manageability including MIBs, OAM, and YANG information models to IESG
[JY] I think MIB, YANG data model and OAM should all be in Standards Track.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 10 Sep 2013 22:55:56 +0000

Hi Kevin,

Apologies for my delayed response; just catching up on email. Inline.

From: Kevin Glavin <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 9, 2013 4:53 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] Back to the charter ...

Jim,

Jim> I don't think that belongs in the charter, rather, if needed we can look at two approaches to address this:

1.  Decide on a registry for common metadata.
2.  Write a draft that defines some core metadata that is broadly agreed as needed.

Having said that, I think of these as future work, i.e. we won't bite it off now.

Jim> We expect this as well.  For example, in mobile, the operators will have metadata specific to their deployment.  I think option #2 above, specific drafts, or well defined and partitioned registration procedures, will be required.

Kevin

Folks,

Proposed NSC WG Charter

…..

……