Subject: [nsc] New NSC WG Charter

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 13 Sep 2013 14:08:03 +0000

Greetings,

We have been working with the routing area AD's and our IAB shepherd Joel Halpern over the last few days to refine the NSC WG charter. The following is our proposal to the community for review and comment. Please note that as an outcome of the various discussions on the list we are proposing that the WG name change from "Network Service Chaining (NSC)" to "Service Function Chaining (SFC)".

Proposed Service Function Chaining (SFC) WG Charter

Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network. Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration.
For a given service, the abstracted view of the required service functions and the order in which they are to be invoked is called a Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a ServiceFunction Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a servicetopology: this is called a Service Function Path. The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.).
The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment, by providing a framework for service function chaining and the necessary protocols or protocol extensions to convey the service path and for communication between nodes that implement service functions.  The working group will also 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 nodes that implement the service functions.
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 WG including example high-level use cases.  Additionally, the WG will normalize nomenclature and definitions for service function chaining.
2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, and security models, as well as requirements on the protocol mechanisms.
3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level encapsulation protocol for conveying the service function chain and the service function path, and for communicating information between nodes that implement service functions. It is intended that the encapsulation be agnostic to thenetwork 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 path realised at the network layer or at any other layer, and the same encapsulation willapply for the construction of service function paths regardless of the actual service.
4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.
5) Manageability: This document will address the management of service function chaining includingrelevant MIBs and YANG data modules, and service function chaining diagnostics.
Proposed Milestones (all dates TBD):
Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining
Request the IESG for publication of Informational documents defining the architecture for SFC and describing the framework and requirements for a generic service function chaining encapsulation protocol.
Request the IESG for publication of a Standards Track document specifying the generic service function chaining encapsulation protocol.
Request the IESG for publication of Informational documents specifying control plane requirements in support of specific SFC use cases.
Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG data models to IESG
Request the IESG for publication of Informational applicability documents defining how the protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Sep 2013 14:41:54 +0000

I like the new name!
"Service Function Chaining" is much more clear in describing the intent of the proposed work.
IMHO, it would be even more clear to replace the "Services" across the charter with "Service Functions", like "..Service functions delivery...", to differentiate from the today's connectivity/VPN "services".

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: [email-masked]
Subject: [nsc] New NSC WG Charter
Importance: High

Greetings,

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Sep 2013 15:59:48 +0100

Hi Linda,
I think it is important to be very clear when we mean service and when we mean
service function.
IMHO, service functions are not delivered. Service functions are executed to
deliver services.
Perhaps rather than a global search and replace, you could suggest specific
instances to be replaced?
Thanks,
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda
Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] New NSC WG Charter
 
I like the new name! 
"Service Function Chaining" is much more clear in describing the intent of the
proposed work. 
IMHO, it would be even more clear to replace the "Services" across the charter
with "Service Functions", like "..Service functions delivery...", to
differentiate from the today's connectivity/VPN "services". 
 
Linda
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: [email-masked]
Subject: [nsc] New NSC WG Charter
Importance: High
 
Greetings,
 
We have been working with the routing area AD's and our IAB shepherd Joel
Halpern over the last few days to refine the NSC WG charter. The following is
our proposal to the community for review and comment. Please note that as an
outcome of the various discussions on the list we are proposing that the WG name
change from "Network Service Chaining (NSC)" to "Service Function Chaining
(SFC)". 

Networks, servers, storage technologies, and applications, have all undergone
significant change in recent years with the introduction of virtualization,
network overlays, and orchestration. The process of service delivery is changing
from the physical insertion of equipment on the path into a mechanism for
causing the path or data to transit specific physical or virtual nodes on which
the service functions are performed. Services are typically implemented by the
ordered combination of a number of service functions that may be implemented at
different points within the network. Service delivery is currently both a
technical and organisational challenge that involves significant modification to
the network configuration.
For a given service, the abstracted view of the required service functions and
the order in which they are to be invoked is called a Service Function Chain
(SFC). Since a given service function may be available on more than one node
within a network, a ServiceFunction Chain is instantiated via the selection of
specific service function instances and the network nodes on which they are
provided, thereby forming a servicetopology: this is called a Service Function
Path. The service functions may be applied at a specific layer within the
network protocol stack (network layer, application layer, etc.).
The Service Function Chaining (SFC) working group will develop new approaches to
service delivery and deployment, by providing a framework for service function
chaining and the necessary protocols or protocol extensions to convey the
service path and for communication between nodes that implement service
functions.  The working group will also 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 nodes that implement
the service functions.
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 WG including example high-level use cases.  Additionally,
the WG will normalize nomenclature and definitions for service function
chaining.
2) Architecture: This document will provide a description of the architectural
building blocks and their relationships including interconnection, placement of
capabilities, management, diagnostics, and security models, as well as
requirements on the protocol mechanisms.
3) Generic Service Function Chaining Encapsulation: A document will describe the
single service-level encapsulation protocol for conveying the service function
chain and the service function path, and for communicating information between
nodes that implement service functions. It is intended that the encapsulation be
agnostic to thenetwork 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 path realised at the network layer or at any other layer, and the same
encapsulation willapply for the construction of service function paths
regardless of the actual service.
4) Control Plane Mechanisms: A set of documents will be developed to describe
requirements and protocols necessary to convey information to service function
implementation points. Where possible, existing IETF protocols will be used and
extended. All protocol extensions work should be carried out in the working
groups responsible for the protocols being modified in coordination with this
working group, but may be done in this working group after agreement with all
the relevant WG chairs and responsible ADs.
5) Manageability: This document will address the management of service function
chaining includingrelevant MIBs and YANG data modules, and service function
chaining diagnostics.
Proposed Milestones (all dates TBD):
Request the IESG for publication of an Informational document defining the
problem statement and core use cases for Service Function Chaining
Request the IESG for publication of Informational documents defining the
architecture for SFC and describing the framework and requirements for a generic
service function chaining encapsulation protocol.
Request the IESG for publication of a Standards Track document specifying the
generic service function chaining encapsulation protocol.
Request the IESG for publication of Informational documents specifying control
plane requirements in support of specific SFC use cases.
Request the IESG for publication of an Informational document defining SFC
manageability including diagnostics, and MIB and YANG data models to IESG 
Request the IESG for publication of Informational applicability documents
defining how the protocol elements developed by the WG may be combined with
other IETF protocols to satisfy the use cases.

---

From: Ron Parker <[email-masked]>
Date: Fri, 13 Sep 2013 15:03:19 +0000

I tend to agree.   A service is something that a service provider could describe as an offering to its customers and perhaps charge for it.    A good many of these service offerings are realized by the application of a sequence of one or more service functions in the data plane.
   Ron
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Hi Linda,
I think it is important to be very clear when we mean service and when we mean service function.
IMHO, service functions are not delivered. Service functions are executed to deliver services.
Perhaps rather than a global search and replace, you could suggest specific instances to be replaced?
Thanks,
Adrian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

I like the new name!

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] New NSC WG Charter
Importance: High

Greetings,

---

From: Andre Beliveau <[email-masked]>
Date: Fri, 13 Sep 2013 15:07:55 +0000

Some suggestion for the new name for "The resulting service that a service provider can offer to its customers as a result of forming Service Function Chains" :
Delivered Service
Network Service (which could be confused with earlier usage of the name)
Composite Service
Resulting Service
My preference goes for Composite Service.
/AB
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: [email-masked]; 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: Lucy yong <[email-masked]>
Date: Fri, 13 Sep 2013 15:08:45 +0000

Do you mean "by the application of a sequence of service functions that are available on some nodes within a network."
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Friday, September 13, 2013 10:03 AM
To: [email-masked]; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: Ken Gray <[email-masked]>
Date: Fri, 13 Sep 2013 15:13:02 +0000

Or we can just agree that, while we're in a WG room labeled Service Function Chaining or reading a document with such a heading … that we're not implying connectivity/VPN services (or any other macro use of the word service) and are really just discussing - service functions.

I hope this isn't mis-interpreted, because I (for one) am sure to slip and say "service" instead of "service function" in such a context and hope to assume that everyone will be understanding.

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Fri, 13 Sep 2013 14:41:54 +0000
To: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] New NSC WG Charter

I like the new name!
“Service Function Chaining” is much more clear in describing the intent of the proposed work.
IMHO, it would be even more clear to replace the “Services” across the charter with “Service Functions”, like “..Service functions delivery...”, to differentiate from the today’s connectivity/VPN “services”.

Linda

Greetings,

Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. The process of service delivery is changing from the physical insertion of equipment on the path into a mechanism for causing the path or data to transit specific physical or virtual nodes on which the service functions are performed. Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network.Service delivery is currently both a technical and organisational challenge that involves significant modification to the network configuration.

_______________________________________________ nsc mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/nsc

---

From: Lucy yong <[email-masked]>
Date: Fri, 13 Sep 2013 15:32:12 +0000

Andre,
Who will be a customer for this service? Is service provider self or third party? If it is the third party, what is the motivation for the third party to use it?
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; [email-masked]; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Some suggestion for the new name for "The resulting service that a service provider can offer to its customers as a result of forming Service Function Chains" :
Delivered Service
Network Service (which could be confused with earlier usage of the name)
Composite Service
Resulting Service
My preference goes for Composite Service.
/AB
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: [email-masked]<mailto:[email-masked]>; 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Sep 2013 15:43:47 +0000

Adrian,
My interpretation of "Service function Chaining" is about network services that require a sequence of service functions to be applied to a selective data flows. So it is less about "service delivery", but more about "the mechanism of applying service functions to data flows".
So I would suggest the sentence "The process of service delivery is.."  in the first paragraph to
    "The process of applying service functions to selective data flows is changing from the physical insertion of equipment on the path into a mechanism for causing the path or ..."

The wording of the charter: "Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network",  gives me the impression that the charter is about chaining a sequence of applications, like chaining WebServer <->AppServer<->DBserver.  If that is the intent of the charter, it is fine with me.
Linda
From: Adrian Farrel [mailto:[email-masked]]
Sent: Friday, September 13, 2013 10:00 AM
To: Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]
Subject: RE: [nsc] New NSC WG Charter

Hi Linda,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] New NSC WG Charter

I like the new name!

Linda

Greetings,

---

From: Andre Beliveau <[email-masked]>
Date: Fri, 13 Sep 2013 15:44:17 +0000

Hi Lucy,
Think of the Composite Service customer as a person or organization which will subscribe or use the Composite Service but does not need to know of the internals (e.g. what is the order of the services).  In other word, this is the simple or abstract view of the Service Function Chain as seen from the outside world.  I can give you a few examples if needed.
/AB
From: Lucy yong [mailto:[email-masked]]
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; [email-masked]; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]
Subject: RE: [nsc] New NSC WG Charter

Andre,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; [email-masked]<mailto:[email-masked]>; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: Lucy yong <[email-masked]>
Date: Fri, 13 Sep 2013 15:52:07 +0000

Andre,
You mean the order of the service functions, right?  What this abstract view means to the customer then?
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; [email-masked]; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Hi Lucy,
To: Andre Beliveau; Ron Parker; [email-masked]<mailto:[email-masked]>; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>

Andre,

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 13 Sep 2013 15:58:32 +0000

Are we really having this discussion again? From where I am sitting Andre's email is very clear – a composite service is something constructed from one or more service functions and a consumer of said service has no knowledge (or frankly concern) of what particular service functions are used in its construction. Please let's not overcomplicate this!!

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 13, 2013 11:52 AM
To: Andre Beliveau <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nsc] New NSC WG Charter

Andre,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; [email-masked]<mailto:[email-masked]>; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Hi Lucy,

Andre,

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andre Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; [email-masked]<mailto:[email-masked]>; Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Some suggestion for the new name for “The resulting service that a service provider can offer to its customers as a result of forming Service Function Chains” :
Delivered Service
Network Service (which could be confused with earlier usage of the name)
Composite Service
Resulting Service
My preference goes for Composite Service.
/AB
From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: [email-masked]<mailto:[email-masked]>; 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Hi Linda,

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

I like the new name!

Linda

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] New NSC WG Charter
Importance: High

Greetings,

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Sep 2013 17:08:08 +0100

Well, I agree :-)
But I would observe that a "composite service" as defined here is a composition
of one or more service functions.
How is that difference from a "service"?
Simplicity seems to say don't use additional words if they aren't needed.
A
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: 13 September 2013 16:59
To: Lucy yong; Andre Beliveau; Ron Parker; [email-masked]; Linda Dunbar;
[email-masked]
Subject: Re: [nsc] New NSC WG Charter
 
Are we really having this discussion again? From where I am sitting Andre's
email is very clear - a composite service is something constructed from one or
more service functions and a consumer of said service has no knowledge (or
frankly concern) of what particular service functions are used in its
construction. Please let's not overcomplicate this!!
 
From: Lucy yong <[email-masked]>
Date: Friday, September 13, 2013 11:52 AM
To: Andre Beliveau <[email-masked]>, Ron Parker
<[email-masked]>, "[email-masked]" <[email-masked]>,
Linda Dunbar <[email-masked]>, Microsoft Office User
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [nsc] New NSC WG Charter
 
Andre,
You mean the order of the service functions, right?  What this abstract view
means to the customer then? 
Lucy
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andre
Beliveau
Sent: Friday, September 13, 2013 10:44 AM
To: Lucy yong; Ron Parker; [email-masked]; Linda Dunbar; 'Jim Guichard
(jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter
 
Hi Lucy, 
Think of the Composite Service customer as a person or organization which will
subscribe or use the Composite Service but does not need to know of the
internals (e.g. what is the order of the services).  In other word, this is the
simple or abstract view of the Service Function Chain as seen from the outside
world.  I can give you a few examples if needed.
/AB
From: Lucy yong [mailto:[email-masked]] 
Sent: September-13-13 11:32 AM
To: Andre Beliveau; Ron Parker; [email-masked]; Linda Dunbar; 'Jim Guichard
(jguichar)'; [email-masked]
Subject: RE: [nsc] New NSC WG Charter
 
Andre,
Who will be a customer for this service? Is service provider self or third
party? If it is the third party, what is the motivation for the third party to
use it? 
Lucy
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Andre
Beliveau
Sent: Friday, September 13, 2013 10:08 AM
To: Ron Parker; [email-masked]; Linda Dunbar; 'Jim Guichard (jguichar)';
[email-masked]
Subject: Re: [nsc] New NSC WG Charter
 
Some suggestion for the new name for "The resulting service that a service
provider can offer to its customers as a result of forming Service Function
Chains" :
Delivered Service
Network Service (which could be confused with earlier usage of the name)
Composite Service
Resulting Service
My preference goes for Composite Service. 
/AB
From:[email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: September-13-13 11:03 AM
To: [email-masked]; 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter
 
I tend to agree.   A service is something that a service provider could describe
as an offering to its customers and perhaps charge for it.    A good many of
these service offerings are realized by the application of a sequence of one or
more service functions in the data plane.
   Ron
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian
Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]
Subject: Re: [nsc] New NSC WG Charter
 
Hi Linda,
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Linda
Dunbar
Sent: 13 September 2013 15:42
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] New NSC WG Charter
 
I like the new name! 
 
Linda
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Jim
Guichard (jguichar)
Sent: Friday, September 13, 2013 9:08 AM
To: [email-masked]
Subject: [nsc] New NSC WG Charter
Importance: High
 
Greetings,

 
different points within the network.Service delivery is currently both a

---

From: Andre Beliveau <[email-masked]>
Date: Fri, 13 Sep 2013 16:08:27 +0000

Right.  The IETF 87 BoF presentations gave a few examples from different providers of what those Composite Services are.   Those can be used as examples.
/AB
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: September-13-13 11:59 AM
To: Lucy yong; Andre Beliveau; Ron Parker; [email-masked]; Linda Dunbar; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Are we really having this discussion again? From where I am sitting Andre's email is very clear - a composite service is something constructed from one or more service functions and a consumer of said service has no knowledge (or frankly concern) of what particular service functions are used in its construction. Please let's not overcomplicate this!!

Andre,

Hi Lucy,

Andre,

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 13 Sep 2013 16:10:58 +0000

I would argue Adrian that a "composite service" is no different to a "service" as regardless of how a service is constructed, said construction is transparent to the consumer of that service.

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 13, 2013 12:08 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nsc] New NSC WG Charter

Well, I agree :-)
But I would observe that a "composite service" as defined here is a composition of one or more service functions.
How is that difference from a "service"?
Simplicity seems to say don't use additional words if they aren't needed.
A
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: 13 September 2013 16:59
To: Lucy yong; Andre Beliveau; Ron Parker; [email-masked]<mailto:[email-masked]>; Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Andre,

Hi Lucy,

Andre,

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:00 AM
To: 'Linda Dunbar'; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Sep 2013 17:10:59 +0100

Lucy,
I think that is circular. Why would one apply service functions to a data flow
except to provide a service.
Lucy asked to whom the service is provided, and I answer "Why, to the service
consumer, of course."
I don't know what you mean by "applications" in your mail. A service function is
instantiated by a combination of hardware and software. In some cases, the
service function will be instantiated purely by an "application" (i.e. by a
piece of software running on a processor). In other cases it won't. Let's not
complicate things by trying to give examples of everything.
 
A
From: Linda Dunbar [mailto:[email-masked]] 
Sent: 13 September 2013 16:44
To: [email-masked]; 'Jim Guichard (jguichar)'; [email-masked]
Subject: RE: [nsc] New NSC WG Charter

Adrian, 
My interpretation of "Service function Chaining" is about network services that
require a sequence of service functions to be applied to a selective data flows.
So it is less about "service delivery", but more about "the mechanism of
applying service functions to data flows". 
So I would suggest the sentence "The process of service delivery is.."  in the
first paragraph to
    "The process of applying service functions to selective data flows is
changing from the physical insertion of equipment on the path into a mechanism
for causing the path or ..."
 
The wording of the charter: "Services are typically implemented by the ordered
combination of a number of service functions that may be implemented at
different points within the network",  gives me the impression that the charter
is about chaining a sequence of applications, like chaining WebServer
<->AppServer<->DBserver.  If that is the intent of the charter, it is fine with
me. 
Linda
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, September 13, 2013 10:00 AM
To: Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]
Subject: RE: [nsc] New NSC WG Charter
 
Hi Linda,

I like the new name! 
 
Linda

Greetings,

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 13 Sep 2013 16:23:11 +0000

I complete agree with Adrian!
Service already implies "composite" meaning. We do not need to complicate it.

Surendra.

Date: Friday, September 13, 2013 9:08 AM

Well, I agree :-)

Andre,

Hi Lucy,

Andre,

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: Lucy yong <[email-masked]>
Date: Fri, 13 Sep 2013 17:40:38 +0000

Adrian,
Clarify that your reply is to Linda, not me.
My understand is that the SFC addresses the environment that service functions may be only available on the nodes that are not the path and some packet flows on the path need to be treated by some of service functions.  The SFC results these packet flows (need service functions) traverse a new path called service function path in order to be served. This is a clear problem and need to be solved.
To me, term "service delivery" in the charter means the ability to redirect the packet flows to the nodes where they can be served by the service functions.
Thanks,
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:11 AM
To: Linda Dunbar; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Lucy,
I think that is circular. Why would one apply service functions to a data flow except to provide a service.
Lucy asked to whom the service is provided, and I answer "Why, to the service consumer, of course."
I don't know what you mean by "applications" in your mail. A service function is instantiated by a combination of hardware and software. In some cases, the service function will be instantiated purely by an "application" (i.e. by a piece of software running on a processor). In other cases it won't. Let's not complicate things by trying to give examples of everything.

A
From: Linda Dunbar [mailto:[email-masked]]
Sent: 13 September 2013 16:44
To: [email-masked]<mailto:[email-masked]>; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [nsc] New NSC WG Charter

Adrian,

To: Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]<mailto:[email-masked]>

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: Ken Gray <[email-masked]>
Date: Fri, 13 Sep 2013 19:16:49 +0000

It doesn't appear to me as if any of this has to do with the charter, per se … but once again attempts to explore/define how SFC will be achieved/embodied/communicated … which would be in other documents that are yet to be developed.  Cart -> Horse

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Fri, 13 Sep 2013 17:40:38 +0000
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] New NSC WG Charter

Adrian,
Clarify that your reply is to Linda, not me.
My understand is that the SFC addresses the environment that service functions may be only available on the nodes that are not the path and some packet flows on the path need to be treated by some of service functions.  The SFC results these packet flows (need service functions) traverse a new path called service function path in order to be served. This is a clear problem and need to be solved.
To me, term “service delivery” in the charter means the ability to redirect the packet flows to the nodes where they can be served by the service functions.
Thanks,
Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, September 13, 2013 11:11 AM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter

Lucy,

A

Adrian,
My interpretation of “Service function Chaining” is about network services that require a sequence of service functions to be applied to a selective data flows. So it is less about “service delivery”, but more about “the mechanism of applying service functions to data flows”.
So I would suggest the sentence “The process of service delivery is..”  in the first paragraph to
    “The process of applying service functions to selective data flows is changing from the physical insertion of equipment on the path into a mechanism for causing the path or ...”

The wording of the charter: “Services are typically implemented by the ordered combination of a number of service functions that may be implemented at different points within the network”,  gives me the impression that the charter is about chaining a sequence of applications, like chaining WebServer <->AppServer<->DBserver.  If that is the intent of the charter, it is fine with me.
Linda

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Sep 2013 20:18:07 +0100

Hi Lucy

> Clarify that your reply is to Linda, not me.

Sorry. Too many equally nice ladies working in the same company with two
syllable names beginning with L.

As to the rest, I think we are close enough to converged.

Adrian

---

From: Lucy yong <[email-masked]>
Date: Fri, 13 Sep 2013 19:28:57 +0000

From: Ken Gray [mailto:[email-masked]]
Sent: Friday, September 13, 2013 2:17 PM
To: Lucy yong; [email-masked]; Linda Dunbar; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

It doesn't appear to me as if any of this has to do with the charter, per se ... but once again attempts to explore/define how SFC will be achieved/embodied/communicated ... which would be in other documents that are yet to be developed.  Cart -> Horse
[Lucy] that is not my attempt.
Lucy

Adrian,

Lucy,

A

Adrian,

Hi Linda,

I like the new name!

Linda

Greetings,

---

From: Thomas Narten <[email-masked]>
Date: Wed, 25 Sep 2013 16:10:24 -0400

Jim et al,

Here are some specific suggestions on the charter (this is from the
version posted Sept. 13). I think they are all editorial, crisping up
the language used and consistent with the discussion on the list.

> Networks, servers, storage technologies, and applications, have all
> undergone significant change in recent years with the introduction
> of virtualization, network overlays, and orchestration. The process
> of service delivery is changing from the physical insertion of
> equipment on the path into a mechanism for causing the path or data
> to transit specific physical or virtual nodes on which the service
> functions are performed.  Services are typically implemented by the
> ordered combination of a number of service functions that may be
> implemented at different points within the network. Service delivery
> is currently both a technical and organisational challenge that
> involves significant modification to the network configuration.

Suggest changing the above as follows:

1) change sentence:

    The process of service delivery is changing from the physical
    insertion of equipment on the path into a mechanism for causing
    the path or data to transit specific physical or virtual nodes on
    which the service functions are performed.

To:

     Today, a common deployment model has service functions
     physically inserted on the data forwarding path between
     communicating peers. Going forward, however, there is a desire to
     move to a different model, where service functions are not
     required to reside on the default data path and traffic is
     instead steered through services, wherever they are deployed.

2) Reorder the existing text in the pargraph so that teh revised text
goes at end of first paragraph, i.e., resulting in:

     Networks, servers, storage technologies, and applications, have
     all undergone significant change in recent years with the
     introduction of virtualization, network overlays, and
     orchestration.  Service delivery is currently both a technical
     and organisational challenge that involves significant
     modification to the network configuration.  Services are
     typically implemented by the ordered chaining of a number of
     service functions (e.g., firewalls, load-balancers, etc.)  that
     are implemented at different points within the network.  Today, a
     common deployment model has service functions physically inserted
     on the data forwarding path between communicating peers. Going
     forward, however, there is a desire to move to a different model,
     where service functions are not required to reside on the default
     data path and traffic is instead steered through services,
     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 invoked is called a

s/invoked/applied/  ???

> Service Function Chain (SFC). Since a given service function may be
> available on more than one node within a network, a ServiceFunction
> Chain is instantiated via the selection of specific service function
> instances and the network nodes on which they are provided, thereby
> forming a servicetopology: this is called a Service Function Path. The
> service functions may be applied at a specific layer within the

I think talking about "layers" here is confusing and not really
needed. SFC doesn't really care  about what layer is used. It only
cares about steering traffic to a service -- what that service does
with that traffic is the service's own business. Suggest tweaking:

Old:

>  The service functions may be applied at a specific layer within the

better:

  Service functions are applied to the traffic flows that are directed
  through them. What the service function actually does to such
  traffic is service-specific and not of concern to SFC.

> The Service Function Chaining (SFC) working group will develop new
> approaches to service delivery and deployment, by providing a
> framework for service function chaining and the necessary protocols or
> protocol extensions to convey the service path and for communication
> between nodes that implement service functions.  The working group
> will also 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 nodes that implement
> the service functions.

The above doesn't actually include the "steering" part. Suggest:

Old:

    The Service Function Chaining (SFC) working group will develop new
    approaches to service delivery and deployment, by providing a
    framework for service function chaining and the necessary
    protocols or protocol extensions to convey the service path and
    for communication between nodes that implement service functions.
     
New:

    The Service Function Chaining (SFC) working group will develop new
    approaches to service delivery and deployment. It will produce a
    framework for service function chaining that includes the
    necessary protocols or protocol extensions to convey service path
    and service path information to nodes that implement service
    functions, as well as mechanisms for steering traffic through
    service functions.

> 1) Problem Statement: This document will provide a summary of the
> problem space to be addressed by the WG including example high-level
> use cases.  Additionally, the WG will normalize nomenclature and
> definitions for service function chaining.
 
> 2) Architecture: This document will provide a description of the
> architectural building blocks and their relationships including
> interconnection, placement of capabilities, management, diagnostics,
> and security models, as well as requirements on the protocol
> mechanisms.
 
> 3) Generic Service Function Chaining Encapsulation: A document will
> describe the single service-level encapsulation protocol for conveying
> communicating information between nodes that implement service
> functions.

Better:

 3) Generic Service Function Chaining Encapsulation: A document will
 describe the single service-level data plane encapsulation format
 for conveying the service function chain and the service function
 path associated with data packets, and for carrying context information
 between nodes that implement service functions.

> It is intended that the encapsulation be agnostic to
> the network 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 path realised at the network layer or at any other layer, and
> the same encapsulation willapply for the construction of service
> function paths regardless of the actual service.

If I understand the list discussion, I think the above really just
means:

    It is intended that the encapsulation be agnostic to the
    underlying network technology (i.e,. IP, MPLS, etc.) being used
    for transport as well to the specific services being supported.
 
> 4) Control Plane Mechanisms: A set of documents will be developed to
> describe requirements and protocols necessary to convey information to
> service function implementation points. Where possible, existing IETF
> protocols will be used and extended. All protocol extensions work
> should be carried out in the working groups responsible for the
> protocols being modified in coordination with this working group, but
> may be done in this working group after agreement with all the
> relevant WG chairs and responsible ADs.
 
> 5) Manageability: This document will address the management of service
> function chaining includingrelevant MIBs and YANG data modules, and
> service function chaining diagnostics.

> Request the IESG for publication of an Informational document defining
> the problem statement and core use cases for Service Function Chaining
 
> Request the IESG for publication of Informational documents defining
> the architecture for SFC and describing the framework and requirements
> for a generic service function chaining encapsulation protocol.
 
> Request the IESG for publication of a Standards Track document
> specifying the generic service function chaining encapsulation
> protocol.
 
> Request the IESG for publication of Informational documents specifying
> control plane requirements in support of specific SFC use cases.
 
> Request the IESG for publication of an Informational document defining
> SFC manageability including diagnostics, and MIB and YANG data models
> to IESG
 
> Request the IESG for publication of Informational applicability
> documents defining how the protocol elements developed by the WG may
> be combined with other IETF protocols to satisfy the use cases.

Thomas

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 25 Sep 2013 21:01:02 +0000

The group charter's write-up says that: "The Service Function Chaining (SFC) working group will develop new approaches to service delivery ..." (i.e., not one "approach" but "approaches", which means more than one). 

But then is states that a document will be developed such that  it "will describe *the(?) single* service-level data plane encapsulation format for conveying the service function chain and the service function path associated with data packets, and for carrying context information between nodes that implement service functions". 

How to do you reconcile those two statements?
In my opinion, we should open the door for more than one solution to service chaining.

Maria

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Narten
> Sent: Wednesday, September 25, 2013 4:10 PM
> To: Jim Guichard (jguichar)
> Cc: [email-masked]
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc

---

From: Ian Smith <[email-masked]>
Date: Wed, 25 Sep 2013 21:07:42 +0000

>In my opinion, we should open the door for more than one solution to service chaining.

I concur. 

There are a number of ways to skin this particular cat, some of which don't require a new on-the-wire protocol because they use protocols that are already defined today in their fullest capacity or in novel combinations.  

It seems to me that the key question that must be answered in the charter is whether or not this is a WG to deliver an architecture (which may or may not include delivering a protocol) or a WG to merely deliver yet-another-overlay-protocol.

________________________________________
From: [email-masked] [[email-masked]] on behalf of NAPIERALA, MARIA H [[email-masked]]
Sent: Wednesday, September 25, 2013 5:01 PM
To: Thomas Narten; Jim Guichard (jguichar)
Cc: [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Maria

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Sep 2013 17:14:19 -0400

I understand the sentiment expressed.

I am however concerned that if we describe an architecture without 
specifying sufficiently prescriptive realization then we will not get 
interoperability.

Yours,
Joel

---

From: Thomas Narten <[email-masked]>
Date: Wed, 25 Sep 2013 17:24:05 -0400

"NAPIERALA, MARIA H" <[email-masked]> writes:

> The group charter's write-up says that: "The Service Function
> Chaining (SFC) working group will develop new approaches to service
> delivery ..." (i.e., not one "approach" but "approaches", which
> means more than one).

> But then is states that a document will be developed such that it
>  "will describe *the(?) single* service-level data plane
>  encapsulation format for conveying the service function chain and
>  the service function path associated with data packets, and for
>  carrying context information between nodes that implement service
>  functions".

> How to do you reconcile those two statements?

Note: this inconsistency existed in the earlier charter, I didn't
introduce it. :-)

I think for the service plane data encapsulation, we should aim for
one. I'm understand the concern about writing that into the charter in
absolute terms, as I think the WG should have room to discuss and it
may be too early to be definitive. But unless there is compelling
reason, we should have one encap. (BTW, nothing new here.. this is
normal IETF.)

That said, I don't see the need for more than one encap. Does anyone
think we do? And if so, why?

> In my opinion, we should open the door for more than one solution to

Ah, "solution to service chaining" (to me) is more than the encap,
including the control plane and related stuff. So even if we develop
one encap, that doesn't necessarily mean there is only one
"solution". So the inconsistency may not be quite as strong as first
seems.

Suggestion. change:

 A document will describe the single service-level data plane 
 encapsulation format ...

To:

 A document will describe a service-level data plane encapsulation
 format ...

this is a bit weaker, but still does (implicitely) suggest one encap.

or, if folk think this is not good enough, we could add text saying we
are aiming for one, and will only do more if ...

But personally, I think it would be fine to have the charter say one
encap, and if the WG concludes that one encap isn't what is needed,
then recharter. We shouldn't look at rechartering as "impossible". We
just need to be able to make the case that more than one encap is
necessary. If we can do that, I wouldn't think rechartering would be a
big deal.

Thomas

---

From: David Meyer <[email-masked]>
Date: Wed, 25 Sep 2013 14:32:23 -0700

> necessary. If we can do that, I wouldn't think rechartering would be a

This seems reasonable, and captures much of the sentiment/aspiration
about service-plane encap.

--dmm

---

From: Ian Smith <[email-masked]>
Date: Wed, 25 Sep 2013 21:33:14 +0000

I'd argue that defining an architecture permits you to include a prescriptive realization while defining a protocol doesn't permit you to define the prescriptive architectural elements that guarantee interoperability beyond the source-destination interpretation of the protocol.

More to the point, and I guess this turns into a problem statement conversation here, the problem that needs to be solved is only made partially better by forcing everyone with the problem to use the same shim layer/encapsulation protocol/overlay networking methodology; interoperability is merely one part of the problem.

The forwarding plane is the least interesting and least complicated part of this.  More critical to business success (and therefore the uptake that justifies the effort) are the orchestration, policy, and reporting aspects because the existing ways of doing this are far less mature and far less efficient than dynamic policy routing and options or encapsulation headers, which is something we've been able to do for decade or more with existing technology (if somewhat painfully) and for which there are numerous rfcs to show you the way already published.  

________________________________________
From: Joel M. Halpern [[email-masked]]
Sent: Wednesday, September 25, 2013 5:14 PM
To: Ian Smith
Cc: NAPIERALA, MARIA H; Thomas Narten; Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 25 Sep 2013 21:39:31 +0000

Thomas et al,

Let's be clear about what we mean by "service-level data plane
encapsulation" as once the intent is clearly understood I see no issue
with the way the current charter reads. Work item #3 states that the
service-level data plane encapsulation is used "for conveying the service
function chain and the service function path associated with data packets,
and for carrying context information between nodes that implement service
functions". This is *different* than specifying a solution that uses
existing transport encapsulations for forwarding traffic through a set of
service functions (for example a solution that uses an MPLS label stack).

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 25 Sep 2013 21:48:46 +0000

I believe the NSC architecture should not preclude the service chain path/topology from being realized with some existing (and standard ;-) network overlay (=virtual network) technique. But if the decision is made that it does then this should be clearly stated in the charter.
What must be common to the service chain path solutions is, IMO, the method for carrying the metadata/context information.

Maria

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2013 5:24 PM
> To: NAPIERALA, MARIA H
> Cc: Jim Guichard (jguichar); [email-masked]

---

From: Ian Smith <[email-masked]>
Date: Wed, 25 Sep 2013 21:53:51 +0000

If that is the intent, then at some point someone needs to explain, probably prior to Vancouver, in detail what functionality not already existing in standardized overlay networking protocols, encapsulation protocols, and/or options headers is required to solve the problem statement being addressed (which also appears to be lacking consensus).

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jim Guichard (jguichar) [[email-masked]]
Sent: Wednesday, September 25, 2013 5:39 PM
To: Thomas Narten; NAPIERALA, MARIA H
Cc: [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Thomas et al,

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 25 Sep 2013 21:57:01 +0000

With all due respect Ian I think several people have on multiple occasions on this alias as well as within several of the existing IDs associated with the SFC (to be) WG.

Sent from my iPhone

> On Sep 25, 2013, at 5:54 PM, "Ian Smith" <[email-masked]> wrote:
>

---

From: Ian Smith <[email-masked]>
Date: Wed, 25 Sep 2013 22:17:35 +0000

I'm not trying to be confrontational or an anchor, but I was at the BoF in Berlin and I've read the three drafts that are getting the most traffic on list - draft-quinn-nsc-problem-statement-02; draft-boucadair-network-function-chaining-03; draft-boucadair-chaining-requirements-01 - and my reading of them, and my experience building dozens if not hundreds of solutions that look an awful lot like what is being described, leave me wondering why a new protocol is required when there are so many options already out there.  

If what you need to do is identify an information stream or network flow, steer it into a particular set of ordered hops and convey some information in-band that a particular hop or hops will use along the way for on-node processing we have the protocols for that already and they are deployed, so I'm presuming that the desire is to do more, but what "more" is doesn't seem to be well communicated in the BoF presentations or the Charter or the three drafts above.  

I know that using the existing protocols to do this is not as easy as it could be, but those aren't problems with the protocol as much as they are problems with the implementations, and they tend to be engulfed by the corollary presumption that service chains will be used in Programmable, Elastic, Virtualized infrastructure and that will force the complexity and manual nature of their configuration to become automated and abstracted.

________________________________________
From: Jim Guichard (jguichar) [[email-masked]]
Sent: Wednesday, September 25, 2013 5:57 PM
To: Ian Smith
Cc: Thomas Narten; NAPIERALA, MARIA H; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

Sent from my iPhone

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 25 Sep 2013 22:20:51 +0000

Understood Ian. Take a look at draft-quinn-nsh as I think that may provide
more insight. 

On 9/25/13 6:17 PM, "Ian Smith" <[email-masked]> wrote:

>I'm not trying to be confrontational or an anchor, but I was at the BoF
>in Berlin and I've read the three drafts that are getting the most
>traffic on list - draft-quinn-nsc-problem-statement-02;
>draft-boucadair-network-function-chaining-03;
>draft-boucadair-chaining-requirements-01 - and my reading of them, and my
>experience building dozens if not hundreds of solutions that look an
>awful lot like what is being described, leave me wondering why a new
>protocol is required when there are so many options already out there.
>
>If what you need to do is identify an information stream or network flow,
>steer it into a particular set of ordered hops and convey some
>information in-band that a particular hop or hops will use along the way
>for on-node processing we have the protocols for that already and they
>are deployed, so I'm presuming that the desire is to do more, but what
>"more" is doesn't seem to be well communicated in the BoF presentations
>or the Charter or the three drafts above.
>
>I know that using the existing protocols to do this is not as easy as it
>could be, but those aren't problems with the protocol as much as they are
>problems with the implementations, and they tend to be engulfed by the
>corollary presumption that service chains will be used in Programmable,
>Elastic, Virtualized infrastructure and that will force the complexity
>and manual nature of their configuration to become automated and
>abstracted.
>
>
>With all due respect Ian I think several people have on multiple
>occasions on this alias as well as within several of the existing IDs
>associated with the SFC (to be) WG.
>
>Sent from my iPhone
>
>> If that is the intent, then at some point someone needs to explain,
>>probably prior to Vancouver, in detail what functionality not already
>>existing in standardized overlay networking protocols, encapsulation
>>protocols, and/or options headers is required to solve the problem
>>statement being addressed (which also appears to be lacking consensus).
>>
>>
>>
>>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 25 Sep 2013 22:30:06 +0000

Let me say that, unless you are being specially ironical, you summarized one of the main goals: that automated and abstracted configuration. Besides this, I see clear advantage in a common understanding for building such chains, whether by means of a new protocol or an agreement on particular semantics in existing ones.

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Ian Smith <[email-masked]>
Date: Wed, 25 Sep 2013 22:38:37 +0000

thanks.  I'll take a look.
________________________________________
From: Jim Guichard (jguichar) [[email-masked]]
Sent: Wednesday, September 25, 2013 6:20 PM
To: Ian Smith
Cc: Thomas Narten; NAPIERALA, MARIA H; [email-masked]
Subject: Re: [nsc] New NSC WG Charter

---

From: Ian Smith <[email-masked]>
Date: Wed, 25 Sep 2013 22:56:07 +0000

I wasn't being ironic.  What I've seen is that with enough abstraction and automation, heterogeneity and polymorphism are possible, and will in fact contribute to the maintainability and business value of complex systems. 

Instead of having to make decisions about what functional elements to include based on their familiarity to the operations staff, you can make them based on their actual functional utility because they are able to "plug into" the system and be managed using a uniform tool kit and it brings with it the possibility of doing really hard things with far less risk and a lower level of expertise.  When you "layer up" your network management away from L2-4, you can be much more deliberate with what you do to the traffic better and align it with business requirements.  And when you have better visibility at a macro level to the network, you can manage low level risk better, which permits you to do things like source routing and name-based forwarding without creating gaping security problems on your LAN or WAN.

________________________________________
From: Diego R. Lopez [[email-masked]]
Sent: Wednesday, September 25, 2013 6:30 PM
To: Ian Smith
Cc: Jim Guichard (jguichar); Thomas Narten; [email-masked]; NAPIERALA, MARIA H
Subject: Re: [nsc] New NSC WG Charter

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 25 Sep 2013 23:07:55 +0000

Hi Ian,

I happily see we are on the same page. As I tried to say in Berlin, for the NFV use cases we are considering this "layering up" you mention is essential to, first, being able of really taking advantage of a virtualized environment and, second, provide mechanisms to make NFV and non-NFV coexistence possible. And this coexistence is going to last for a long long time.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: <[email-masked]>
Date: Thu, 26 Sep 2013 09:35:30 +0200

Hi Ian,

Your comment is legitimate and I hear it. 

Together with Ron, we initiated an analysis document discussing various design option candidates. The current version is available at
http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00 

That effort is open and you are welcome to record solutions that do not require protocol extensions, etc. Those proposals will be analyzed and challenged.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de Ian
>Smith
>Envoyé : mercredi 25 septembre 2013 23:54
>À : Jim Guichard (jguichar); Thomas Narten; NAPIERALA, MARIA H
>Cc : [email-masked]
>Objet : Re: [nsc] New NSC WG Charter
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 26 Sep 2013 14:01:48 +0000

Hi Thomas et al,

I have updated the charter as follows to capture the comments/suggestions made over the last few days. Please review and let me know if there are any outstanding issues not covered by the charter.

Thomas, some responses inline below in response to your original email.

Service Function Chaining (SFC) WG Charter

Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. Service delivery is currently both a technical and organizational challenge that involves significant modification to the network configuration. Services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within the network. Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, 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). Since a given service function may be available on more than one node within a network, a Service Function Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a service topology: this is called a Service Function Path (SFP). The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.).

The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment. It will produce a framework for service function chaining that includes the necessary protocols or protocol extensions to convey the service path and service path information to nodes that implement service functions, as well as mechanisms for steering traffic through service functions. The working group will also 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 nodes that implement the service functions.

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

2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms.

3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation 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 path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.

4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF
protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.

5) Manageability: This document will address the management of service function chaining including relevant MIBs and YANG information & data modules, and service function chaining diagnostics.

Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining.

Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG information/data models to IESG.

On 9/25/13 4:10 PM, "Thomas Narten" <[email-masked]<mailto:[email-masked]>> wrote:

Jim et al,

1) change sentence:

To:

Jim> agreed and reflected in the new charter text.

Jim> agreed and reflected in the new charter text.

s/invoked/applied/  ???

Jim> agreed.

Old:

better:

Jim> I did not use this text as I believe consensus on the layering issue was reached on the alias and the original text reflects this consensus.

Old:

New:

Jim> agreed and reflected in new charter text.

Better:

Jim> yep.

_______________________________________________
nsc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nsc

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 26 Sep 2013 14:09:01 +0000

Tom, et al.,

we should keep open the option of having a solution that specifies how metadata data is carried but does not dictate how the service chain path is realized. 
So I vote for changing the language in the charter for item 3): "A document will describe the single service-level data plane encapsulation format ...", as it is solution-specific. Maybe the easiest would be to remove this item from the charter.

Maria

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 26 Sep 2013 14:12:45 +0000

Hi Maria,

Hope you are well. I do not believe the new charter text prevents the
realization of a service chain *without* metadata/context information.

On 9/25/13 5:48 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>I believe the NSC architecture should not preclude the service chain
>path/topology from being realized with some existing (and standard ;-)
>network overlay (=virtual network) technique. But if the decision is made
>that it does then this should be clearly stated in the charter.
>What must be common to the service chain path solutions is, IMO, the
>method for carrying the metadata/context information.
>
>Maria
>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 26 Sep 2013 14:27:24 +0000

Jim,

I said the opposite, i.e., how to carry metadata should be part of the charter but how to carry the metadata should not necessarily dictate how the service chain path itself is realized.

Maria

> Sent: Thursday, September 26, 2013 10:13 AM
> To: NAPIERALA, MARIA H; Thomas Narten
> Cc: [email-masked]
> >> > In my opinion, we should open the door for more than one solution
> to
> >> > service chaining.
> >>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 26 Sep 2013 14:31:18 +0000

Yes and I believe the following text from the charter covers that -> "The
Service Function Chaining (SFC) working group will develop new approaches
to service delivery and deployment. It will produce a framework for
service function chaining that includes the necessary protocols or
protocol extensions to convey the service path and service path
information to nodes that implement service functions, as well as
mechanisms for steering traffic through service functions."

On 9/26/13 10:27 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>Jim,
>
>I said the opposite, i.e., how to carry metadata should be part of the
>charter but how to carry the metadata should not necessarily dictate how
>the service chain path itself is realized.
>
>Maria
>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 26 Sep 2013 14:48:27 +0000

This paragraph is good.

I was pointing out that the item 3 (under "Specifically, the SFC WG is chartered to deliver the following" heading) is implying a specific solution (which is fine but it should not be the only one...):

"3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions..."

Maria

> Sent: Thursday, September 26, 2013 10:31 AM
> To: NAPIERALA, MARIA H
> Cc: [email-masked]
> >> >network overlay (=virtual network) technique. But if the decision
> is
> >> made
> >> >> one. I'm understand the concern about writing that into the
> charter
> >> in
> >> >> or, if folk think this is not good enough, we could add text
> saying
> >> we
> >> >> then recharter. We shouldn't look at rechartering as
> "impossible".
> >> We
> >> >> necessary. If we can do that, I wouldn't think rechartering would
> be
> >> a
> >> >> big deal.
> >> >>
> >> >> Thomas
> >> >
> >

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 26 Sep 2013 14:51:15 +0000

That is talking about context information - notice all the *and's* in the
sentence ;-) 

On 9/26/13 10:48 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>This paragraph is good.
>
>I was pointing out that the item 3 (under "Specifically, the SFC WG is
>chartered to deliver the following" heading) is implying a specific
>solution (which is fine but it should not be the only one...):
>
>"3) Generic Service Function Chaining Encapsulation: A document will
>describe the single service-level data plane encapsulation format for
>conveying the service function chain and the service function path, and
>for communicating context information between nodes that implement
>service functions..."
>
>
>Maria
>

---

From: Ian Smith <[email-masked]>
Date: Thu, 26 Sep 2013 14:59:31 +0000

>for communicating context information between nodes that implement

I think you are trying to say this:

3) Generic Service Function Chaining Encapsulation: A document will
describe a uniform service-level data plane encapsulation format for both:
 a) conveying the service function chain and the service function path, and
 b) for communicating context information between nodes that implement
service functions...

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jim Guichard (jguichar) [[email-masked]]
Sent: Thursday, September 26, 2013 10:51 AM
To: NAPIERALA, MARIA H
Cc: [email-masked]
Subject: Re: [nsc] New NSC WG Charter

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 26 Sep 2013 15:02:15 +0000

Yes, that is more accurately put Ian.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 26 Sep 2013 15:34:37 +0000

I understand.
Why such document is specifically singled out in the charter? Let's leave it to the solutions.

Maria

> >> >charter but how to carry the metadata should not necessarily
> dictate
> >> how
> >> >> >path/topology from being realized with some existing (and
> standard
> >> ;-)
> >> >> >> > But then is states that a document will be developed such
> that
> >> it
> >> >> >> >  encapsulation format for conveying the service function
> chain
> >> and
> >> >> >> I think for the service plane data encapsulation, we should
> aim
> >> for
> >> >> >> absolute terms, as I think the WG should have room to discuss
> and
> >> it
> >> >> >> reason, we should have one encap. (BTW, nothing new here..
> this
> >> is
> >> >> >> normal IETF.)
> >> >> >>
> >> >> >> But personally, I think it would be fine to have the charter
> say
> >> one

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Sep 2013 23:01:22 +0100

I have to pile in here :-(

Maria, I think you want to say "Don't require me to use a service-level
encapsulation to achieve this function". 
I don't believe you want to say "Allow me to have more than one service-level
encapsulation to achieve this function."

The text does not in any way preclude having other mechanisms for doing stuff. 
In particular, configuring service chains at service nodes is an obvious
approach. Similarly the service chain information might be distributed (ahead of
time) by some other protocol.

The text does say that there will be at most one service-level encapsulation.
Because setting out to have more than one new encapsulation protocol to do the
same thing.

Text also says that there will be a service-level encapsulation.
Why does it do that?
Because, if this WG goes off and decides to tweak every protocol that is out
there to make a special way to carry service chain information in that protocol,
it will be a disaster (IMNSHO).

If this doesn't address your concern, Maria, perhaps rather than try to change
the text or comment on what you think the text implies, you could say what it is
you want to be able to do. That way we can say whether it is in or out of scope
of the current text.

Thanks,
Adrian

> NAPIERALA, MARIA H
> Sent: 26 September 2013 16:35
> Why such document is specifically singled out in the charter? Let's leave it
to the
> solutions.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 26 Sep 2013 22:23:20 +0000

I thought I said it already: the ability to carry the metadata without requiring to also carry service chain information (quote from the charter's write up: "conveying the service function chain and the service function path") in the data packet.
If you think this is already in the charter or it is outside of the charter, I would like to know.  I cannot infer it from the write-up.

Maria

> Sent: Thursday, September 26, 2013 6:01 PM
> To: NAPIERALA, MARIA H; 'Jim Guichard (jguichar)'
> Cc: [email-masked]
> > > That is talking about context information - notice all the *and's*
> in
> > > the
> > > sentence ;-)
> > >
> > > >conveying the service function chain and the service function
> path,
> > > and
> > > >> Yes and I believe the following text from the charter covers
> that ->
> > > >> "The
> > > >> >I said the opposite, i.e., how to carry metadata should be part
> of
> > > the
> > > >> >> Hope you are well. I do not believe the new charter text
> prevents
> > > >> the
> > > >> >> >I believe the NSC architecture should not preclude the
> service
> > > >> chain
> > > >> >> >What must be common to the service chain path solutions is,
> IMO,
> > > >> the
> > > >> >> >> > Chaining (SFC) working group will develop new approaches
> to
> > > >> >> service
> > > >> >> >> > delivery ..." (i.e., not one "approach" but
> "approaches",
> > > which
> > > >> >> >> > means more than one).
> > > >> >> >>
> > > >> >> >> >  the service function path associated with data packets,
> and
> > > >> for
> > > >> >> >> >  carrying context information between nodes that
> implement
> > > >> service
> > > >> >> >> >  functions".
> > > >> >> >>
> > > >> >> >> That said, I don't see the need for more than one encap.
> Does
> > > >> anyone
> > > >> >> >> Ah, "solution to service chaining" (to me) is more than
> the
> > > >> encap,
> > > >> >> >> including the control plane and related stuff. So even if
> we
> > > >> develop
> > > >> >> >> "solution". So the inconsistency may not be quite as
> strong as
> > > >> first
> > > >> >> >> seems.
> > > >> >> >>
> > > >> >> >> Suggestion. change:
> > > >> >> >>
> > > >> >> >> this is a bit weaker, but still does (implicitely) suggest
> one
> > > >> >> encap.
> > > >> >> >>
> > > >> >> >> encap, and if the WG concludes that one encap isn't what
> is
> > > >> needed,
> > > >> >> >> just need to be able to make the case that more than one
> encap
> > > is
> > > >> >> >> necessary. If we can do that, I wouldn't think
> rechartering
> > > would
> > > >> be
> > > >> >> a
> > > >> >> >> big deal.
> > > >> >> >>
> > > >> >> >> Thomas
> > > >> >> >
> > > >> >
> > > >
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Sep 2013 23:39:47 +0100

It is unequivocally in the charter.

The text that bothers you is:
   A document will describe the single service-level data plane
   encapsulation format for conveying the service function chain
   and the service function path, and for communicating context
   information between nodes that implement service functions. 

The use of "and" does not always mean that you MUST do both things. It means you
can do both.

Silly example:
The English language allows an English speaker to order food at lunchtime and to
make proposals of marriage.
This does not require me to propose to the waiter each time I ask for a burrito.

In the text in the draft charter it says:
We will make one encapsulation protocol.
You can use this protocol to carry the service function chain. 
You can also use this protocol to carry the service function path. 
You can also use this protocol to carry metadata.

OK?

Adrian

> From: NAPIERALA, MARIA H [mailto:[email-masked]]
> Sent: 26 September 2013 23:23
> To: [email-masked]; 'Jim Guichard (jguichar)'
> Cc: [email-masked]
> I thought I said it already: the ability to carry the metadata without
requiring to
> also carry service chain information (quote from the charter's write up:
> "conveying the service function chain and the service function path") in the
data
> packet.
> If you think this is already in the charter or it is outside of the charter, I
would like
> to know.  I cannot infer it from the write-up.
> 
> Maria
>

---

From: John E Drake <[email-masked]>
Date: Thu, 26 Sep 2013 22:49:51 +0000

Comment inline

Yours Irrespectively,

John

> Adrian Farrel
> Sent: Thursday, September 26, 2013 3:40 PM
> To: 'NAPIERALA, MARIA H'; 'Jim Guichard (jguichar)'
> Cc: [email-masked]
> The use of "and" does not always mean that you MUST do both things. It
> means you can do both.
> 
> Silly example:
> The English language allows an English speaker to order food at lunchtime
> and to make proposals of marriage.

[JD]  Although, I have seen this happen.

> > > Maria, I think you want to say "Don't require me to use a
> > > service-level encapsulation to achieve this function".
> > > I don't believe you want to say "Allow me to have more than one
> > > service-level encapsulation to achieve this function."
> > >
> > > In particular, configuring service chains at service nodes is an
> > > obvious approach. Similarly the service chain information might be
> > > distributed (ahead of
> > > Because setting out to have more than one new encapsulation protocol
> > > to do the same thing.
> > >
> > > Because, if this WG goes off and decides to tweak every protocol
> > > that is out there to make a special way to carry service chain
> > > information in that protocol, it will be a disaster (IMNSHO).
> > >
> > > If this doesn't address your concern, Maria, perhaps rather than try
> > > to change the text or comment on what you think the text implies,
> > > you could say what it is you want to be able to do. That way we can
> > > say whether it is in or out of scope of the current text.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >
> > > > From: [email-masked] [mailto:[email-masked]] On Behalf
> > > > Of NAPIERALA, MARIA H
> > > > Why such document is specifically singled out in the charter?
> > > > Let's
> > > leave it
> > > to the
> > > > solutions.
> > > >
> > > > Maria
> > > >
> > > > > >I was pointing out that the item 3 (under "Specifically, the
> > > > > >SFC
> > > WG is
> > > > > >for communicating context information between nodes that
> > > > > >implement service functions..."
> > > > > >
> > > > > >
> > > > > >Maria
> > > > > >
> > > > > >> Service Function Chaining (SFC) working group will develop
> > > > > >> new approaches to service delivery and deployment. It will
> > > > > >> produce a framework
> > > for
> > > > > >> service function chaining that includes the necessary
> > > > > >> protocols
> > > or
> > > > > >> protocol extensions to convey the service path and service
> > > > > >> path information to nodes that implement service functions,
> > > > > >> as well
> > > as
> > > > > >> >> On 9/25/13 5:48 PM, "NAPIERALA, MARIA H"
> <[email-masked]>
> > > wrote:
> > > > > >> >>
> > > > > >> >> >> >  "will describe *the(?) single* service-level data
> > > > > >> >> >> > plane  encapsulation format for conveying the service
> > > > > >> >> >> > function
> > > > > chain
> > > > > >> and
> > > > > >> >> >> Note: this inconsistency existed in the earlier
> > > > > >> >> >> charter, I
> > > > > didn't
> > > > > >> >> >> introduce it. :-)
> > > > > >> >> >>
> > > > > >> >> >> > In my opinion, we should open the door for more than
> > > > > >> >> >> > one
> > > > > >> solution
> > > > > >> >> to
> > > > > >> >> >> > service chaining.
> > > > > >> >> >>
> > > > > >> >> >> one encap, that doesn't necessarily mean there is only
> > > > > >> >> >> one "solution". So the inconsistency may not be quite
> > > > > >> >> >> as
> > > strong as
> > > > > >> first
> > > > > >> >> >> seems.
> > > > > >> >> >>
> > > > > >> >> >> Suggestion. change:
> > > > > >> >> >>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 26 Sep 2013 23:20:12 +0000

> The use of "and" does not always mean that you MUST do both things. It

Not always, but it might. And in the text above this distinction is not clear.

> means you

> This does not require me to propose to the waiter each time I ask for a

So let's change the text as follows (to avoid explaining what "and" means):

"A document will describe the single service-level data plane
encapsulation format for conveying information such as
service function chain ID, service function path, or for communicating context
information between nodes that implement service functions."

> > > The text does not in any way preclude having other mechanisms for
> doing
> > > stuff.
> > > obvious
> > > approach. Similarly the service chain information might be
> distributed
> > > (ahead of
> > > Because setting out to have more than one new encapsulation
> protocol to
> > > do the
> > > same thing.
> > >
> > > is out
> > > there to make a special way to carry service chain information in
> that
> > > protocol,
> > > If this doesn't address your concern, Maria, perhaps rather than
> try to
> > > change
> > > the text or comment on what you think the text implies, you could
> say
> > > what it is
> > > you want to be able to do. That way we can say whether it is in or
> out
> > > of scope
> > > of the current text.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >
> > > > > >"3) Generic Service Function Chaining Encapsulation: A
> document
> > > will
> new
> > > > > >> approaches
> > > > > >> to service delivery and deployment. It will produce a
> framework
> > > for
> path
> > > > > >> information to nodes that implement service functions, as
> well
> > > as
> plane
> > > > > >> >> >> one. I'm understand the concern about writing that
> into
> > > the
> > > > > >> charter
> > > > > >> >> in
> > > > > >> >> >>  A document will describe the single service-level
> data
> > > plane
> > > > > >> >> >>  encapsulation format ...
> > > > > >> >> >>
> > > > > >> >> >> To:
> > > > > >> >> >>
> > > > > >> >> >> or, if folk think this is not good enough, we could
> add
> > > text
> > > > > >> saying
> > > > > >> >> we

---

From: Ken Gray <[email-masked]>
Date: Thu, 26 Sep 2013 23:29:25 +0000

+1 

>> > >> Yes and I believe the following text from the charter covers that
>>->
>> > >> "The
>> > >> >> >> "solution". So the inconsistency may not be quite as strong
>>as
>> > >> first
>> > >> >> >> seems.
>> > >> >> >>
>> > >> >> >> Suggestion. change:
>> > >> >> >>

---

From: Ken Gray <[email-masked]>
Date: Thu, 26 Sep 2013 23:57:13 +0000

Hate to be a wet blanket, but since we're niggling over the word "and",
the proposed text could be interpreted as any one of "service function
chain ID, service function path, or for communicating context" but not
more than one at the same time.  Replacing "and" with "or" didn't make it
any clearer for me.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 27 Sep 2013 00:41:23 +0000

It does make a difference if you think in terms of mathematical logic.
Otherwise, replace "or" with a grammatical "and/or."

Maria

> Sent: Thursday, September 26, 2013 7:57 PM
> To: NAPIERALA, MARIA H; [email-masked]; 'Jim Guichard (jguichar)'
> Cc: [email-masked]
> >Not always, but it might. And in the text above this distinction is
> not
> >clear.
> >
> >> means you
> >> can do both.
> >
> >>
> >> Silly example:
> >> This does not require me to propose to the waiter each time I ask
> for a
> >> burrito.
> >
> >> > also carry service chain information (quote from the charter's
> write
> >> up:
> >> > "conveying the service function chain and the service function
> path")
> >> in the
> >> data
> >> > packet.
> >> > If you think this is already in the charter or it is outside of
> the
> >> charter, I
> >> would like
> service-
> >> level
> >> > > > > >> On 9/26/13 10:27 AM, "NAPIERALA, MARIA H"
> <[email-masked]>
> >> > > wrote:
> >> > > > > >>
> >> > > > > >> >Jim,
> >> > > > > >> >
> >> > > > > >> >I said the opposite, i.e., how to carry metadata should
> be
> >> part
> >> > > of
> >> > > > > the
> >> > > > > >> >> realization of a service chain *without*
> metadata/context
> >> > > > > >> information.
> >> > > > > >> >>
> >> > > > > >> >> >network overlay (=virtual network) technique. But if
> the
> >> > > > > decision
> >> > > > > >> is
> >> > > > > >> >> made
> >> > > > > >> >> >that it does then this should be clearly stated in
> the
> >> > > charter.
> >> > > > > >> >> >What must be common to the service chain path
> solutions
> >> is,
> >> > > IMO,
> >> > > > > >> the
> >> > > > > >> >> >> > The group charter's write-up says that: "The
> Service
> >> > > > > Function
> >> > > > > >> >> >> > But then is states that a document will be
> developed
> >> > > such
> >> > > > > that
> >> > > > > >> it
> >> > > > > >> >> >> I think for the service plane data encapsulation,
> we
> >> > > should
> >> > > > > aim
> >> > > > > >> for
> >> > > > > >> >> >> absolute terms, as I think the WG should have room
> to
> >> > > discuss
> >> > > > > and
> >> > > > > >> it
> >> > > > > >> >> >> may be too early to be definitive. But unless there
> is
> >> > > > > compelling
> >> > > > > >> >> >> including the control plane and related stuff. So
> even
> >> if
> >> > > we
> >> > > > > >> develop
> >> > > > > >> >> >>  A document will describe a service-level data
> plane
> >> > > > > >> encapsulation
> >> > > > > >> >> >>  format ...
> >> > > > > >> >> >>
> >> > > > > >> >> >> But personally, I think it would be fine to have
> the
> >> > > charter
> >> > > > > say
> >> > > > > >> one
> >> > > > > >> >> >> just need to be able to make the case that more
> than
> >> one
> >> > > encap
> >> > > > > is

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Sep 2013 10:18:24 +0100

Ken took the words out of my mouth.
If we treat English as "mathematical logic" then using "or" as you propose is
equally unhelpful.

At this point I would like to continue to write our charters in the subset of
English that is common in the US and the UK.

Let me do it this way...

Does anyone else on this mailing list have a problem with the words of the
following text subject to the explanation I provided?

> information between nodes that implement service functions

If we have rough consensus we will move on.
If there is a body of people who find the text ambiguous as Maria does, then we
will wheel out a lawyer to make it water-tight.

Thanks,
Adrian

> Sent: 27 September 2013 00:57

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 27 Sep 2013 09:30:19 -0400

> it will be a disaster (IMNSHO).

	Agreed. This is very important to be clear on.

	--Tom

---

From: Ron Parker <[email-masked]>
Date: Fri, 27 Sep 2013 13:47:59 +0000

Sorry, but I'll jump in, too.

I couldn't agree more that a single service header definition is necessary to make this effort successful in terms of adoption and deployment and I support stating that requirement up front, in the charter.   Whether or not the service header is fixed length, variable length, TLV, AVP, carries this kind of metadata or that, does not have to be in the charter.

Another related topic that perhaps isn't quite as fundamental as to be included in the charter, but will quickly come to the fore during discussion of our actual deliverables is whether a single "transport" encapsulation is to be utilized.   For much the same reason that Tom describes about tweaking many protocols to describe the service header, if we need to tweak many protocols for how to transport our new unified service header we'll run into the same issue (i.e., special ethertypes, special MPLS labels, etc, etc.).

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Friday, September 27, 2013 9:30 AM
To: [email-masked]
Cc: [email-masked]; 'Jim Guichard (jguichar)'; 'NAPIERALA, MARIA H'
Subject: Re: [nsc] New NSC WG Charter

On Sep 26, 2013:6:01 PM, at 6:01 PM, "Adrian Farrel" <[email-masked]> wrote:

> Because, if this WG goes off and decides to tweak every protocol that 
> is out there to make a special way to carry service chain information 
> in that protocol, it will be a disaster (IMNSHO).

	--Tom

> to change the text or comment on what you think the text implies, you 
> could say what it is you want to be able to do. That way we can say 
> whether it is in or out of scope of the current text.
> 
> Thanks,
> Adrian
> 
> 
>>> in the sentence ;-)
>>>> I was pointing out that the item 3 (under "Specifically, the SFC WG 
>>>> is chartered to deliver the following" heading) is implying a 
>>>> specific solution (which is fine but it should not be the only one...):
>>>> 
>>>> "3) Generic Service Function Chaining Encapsulation: A document 
>>>> will describe the single service-level data plane encapsulation 
>>>> format for conveying the service function chain and the service 
>>>> function path,
>>> and
>>>>> -> "The Service Function Chaining (SFC) working group will develop 
>>>>> new approaches to service delivery and deployment. It will produce 
>>>>> a framework for service function chaining that includes the 
>>>>> necessary protocols or protocol extensions to convey the service 
>>>>> path and service path information to nodes that implement service 
>>>>> service functions."

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 27 Sep 2013 13:58:44 +0000

Hi Ron,

It is certainly true that each transport will need some mechanism to
indicate that our service header is present and there are 3 relevant
drafts for this already written and associated with our WG efforts.
However, an indication in the transport is much easier than trying to fit
all of the "stuff" we need for services into each and every transport
protocol. 

On 9/27/13 9:47 AM, "Ron Parker" <[email-masked]> wrote:

>I couldn't agree more that a single service header definition is
>necessary to make this effort successful in terms of adoption and
>deployment and I support stating that requirement up front, in the
>charter.   Whether or not the service header is fixed length, variable
>length, TLV, AVP, carries this kind of metadata or that, does not have to
>be in the charter.
>
>Another related topic that perhaps isn't quite as fundamental as to be
>included in the charter, but will quickly come to the fore during
>discussion of our actual deliverables is whether a single "transport"
>encapsulation is to be utilized.   For much the same reason that Tom
>describes about tweaking many protocols to describe the service header,
>if we need to tweak many protocols for how to transport our new unified
>service header we'll run into the same issue (i.e., special ethertypes,
>special MPLS labels, etc, etc.).
>
>   Ron
>
>
>Thomas Nadeau

---

From: Ron Parker <[email-masked]>
Date: Fri, 27 Sep 2013 14:06:21 +0000

Thanks, Jim.

I agree and for that reason feel that we can and should take the transport encapsulation issue up during WG discussions and not burden the charter with this.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Friday, September 27, 2013 9:59 AM
To: Ron Parker; Thomas Nadeau; [email-masked]
Cc: [email-masked]; 'NAPIERALA, MARIA H'
Subject: Re: [nsc] New NSC WG Charter

Hi Ron,

It is certainly true that each transport will need some mechanism to indicate that our service header is present and there are 3 relevant drafts for this already written and associated with our WG efforts.
However, an indication in the transport is much easier than trying to fit all of the "stuff" we need for services into each and every transport protocol. 

On 9/27/13 9:47 AM, "Ron Parker" <[email-masked]> wrote:

>length, TLV, AVP, carries this kind of metadata or that, does not have 
>to be in the charter.
>
>>doing stuff.
>>>>> I was pointing out that the item 3 (under "Specifically, the SFC 
>>>>>WG  is chartered to deliver the following" heading) is implying a  
>>>>>> -> "The Service Function Chaining (SFC) working group will 
>>>>>> -> develop
>>>>>> produce a framework for service function chaining that includes 
>>>>>> the necessary protocols or protocol extensions to convey the 
>>>>>> service path and service path information to nodes that implement 
>>>>>> service functions, as well as mechanisms for steering traffic 
>>>>>> through service functions."
>>>>>>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 27 Sep 2013 14:14:15 +0000

Ron,

> length, TLV, AVP, carries this kind of metadata or that, does not have

I agree. But currently the charter lists some specific pieces of header information like service function chain ID and the service function path. IMO, this should not be part of the charter. This belongs to the solutions. 

Maria

> Of
> WG
> produce

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 27 Sep 2013 14:26:19 +0000

Hi Maria,

The charter does not specify "service function chain ID" but rather says
"encapsulation format for conveying the service function chain and the
service function path" - in other words it does not specify the format of
the encapsulation but simply states that it will carry information
pertaining to the SFC and SFP.

On 9/27/13 10:14 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>I agree. But currently the charter lists some specific pieces of header
>information like service function chain ID and the service function path.
>IMO, this should not be part of the charter. This belongs to the
>solutions. 
>
>Maria
>
>>
>> 
>>

---

From: Ron Parker <[email-masked]>
Date: Fri, 27 Sep 2013 14:30:34 +0000

Hi, Maria.

I do think that a certain baseline of capability in the service header is within bounds to state as mandatory in the charter.    A certain amount of data is required to allow (non-classifying) service nodes to know how to progress the traffic to the next service node, or whether the service node in question is at the end of the chain.    I realize that even this concept is controversial when evaluated against SDN techniques.   But we've also stated that the service nodes must be reachable over arbitrary topologies and not restricted to a single data center, for example. 

   Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Friday, September 27, 2013 10:14 AM
To: Ron Parker; Thomas Nadeau; [email-masked]
Cc: [email-masked]; 'Jim Guichard (jguichar)'
Subject: RE: [nsc] New NSC WG Charter

Ron,

Maria

> >>>>> path and service path information to nodes that implement

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 27 Sep 2013 14:33:46 +0000

Jim,

there might be solutions where such information is not needed to be carried in the data plane. 
So, what I am proposing is not to list it explicitly in the charter.

Maria

> Sent: Friday, September 27, 2013 10:26 AM
> To: NAPIERALA, MARIA H; Ron Parker; Thomas Nadeau; [email-masked]
> Cc: [email-masked]
> protocol
> try
> you
> strong

---

From: Ken Gray <[email-masked]>
Date: Fri, 27 Sep 2013 15:13:14 +0000

I would propose that we work out that detail in the WG and not the
charter.  The charter isn't supposed to work out all the use cases.

The consensus seems (to me) that passing the information listed in the
charter is valuable (at least in some cases) as part and parcel of
building service chains and we therefor do need a header.

I think the WG docs can take up "transparency" of the header that passes
that information (you can always ignore it, but the idea is multi-vendor
interop) and the format of that header (even if it's the NULL set of what
is listed in the charter).

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 27 Sep 2013 11:26:48 -0400

> charter.  The charter isn't supposed to work out all the use cases.

	Precisely; its sufficient to say, "work on X use cases, produce a document by date Y."

> is listed in the charter).

	This is an important point to put into the charter though. If the statement of "The WG will work on transparency issues" or something isn't there, we might debate whether or not documents are valid. Putting it into the charter now makes it an explicitly valid thing to work on. Remember, the charter is a "ring fence" that sets boundaries for the WG.  This is why I think it should explicitly go in there.

	--Tom