Subject: Re: [nsc] NSC Working Group Charter Proposal

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 3 Sep 2013 21:00:26 +0000

Hello Jerome,
A couple of comments on this point:
>As to the milestones, something about documenting use cases would seem in order. As you probably know, both BBF SIMR >and ETSI NFV have such ongoing activities,

My reading of the proposed charter is that the Problem Statement is going to include also the use cases:

1) Problem Statement: this document will provide a summary of the problem space to be addressed by the Network Service Chaining WG including terminology and sample use cases

Regarding leveraging BBF work: I fully agree with you we should not replicate the same work in different SDOs. However, based on my previous experience in BBF, I think it may be difficult to refer in internet drafts to BBF  work in progress documents because these documents are not public  until they are published, so only BBF members have access to them. It could be useful to have a liaison from BBF to nsc WG that summarizes the uses cases already agreed in BBF.

Best Regards
Roberta
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jerome Moisand
Sent: Tuesday, September 03, 2013 3:50 PM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jim and al.

This sounds like a nice start.

From my first pass, something seems missing: there is a reference to a Service Chaining Control Plane at the very end, in the list of milestones, but nothing in the text alludes to it. And this is clearly NOT the same thing as Manageability. I do agree we need to think hard to such control plane matters, and this should be made more explicit in the charter.

As to the milestones, something about documenting use cases would seem in order. As you probably know, both BBF SIMR and ETSI NFV have such ongoing activities, albeit very new, and this should be leveraged, no point re-inventing the wheel. I can be used as point of contact on the BBF side, by the way. Anyhoo, I would just suggest to add a milestone about collecting use cases, either directly or via other standard bodies and industry forums.

Tx
Jerome

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Tuesday, September 03, 2013 12:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] NSC Working Group Charter Proposal

Greetings,

As we look forward to the formation of a working group that will focus on network service chaining, I would like to propose a discussion on this alias to try and reach consensus on an initial charter as requested by the routing area AD's. The following is a first draft of the charter and I invite you to actively participate and provide inputs into this process.

Proposed NSC WG Charter

Existing service insertion and deployment techniques have not evolved to meet modern network architectures and do not reflect multi-tenancy, virtualization, elasticity, rich classification, and other network requirements. Networks, servers, storage, and applications, have all undergone significant change in recent years: virtualization, network overlays, and orchestration are increasingly the norm. All of these have profound effects on network and services design.

Today, deploying new services, or making changes to existing services, often requires network topology changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading to mostly-static service definitions. New service insertion and deployment techniques must enable the concept of service functions as shared resources, and enable the linkage of these resources using service chains that represent the abstracted view of the required service functions, and define the order in which they should be applied. When a service chain is instantiated in a network, specific instances of service functions are selected, and a service topology is created and used for forwarding packets through the service chain.

A basic service chain might simply utilize an existing overlay technology to force traffic through the necessary service functions. However, additional information enables a richer service chain for more advanced composite services. For example, shared information (e.g., the result of classification) can be used to offload service function processing or inform other service functions about information that would otherwise be hard to glean.

The Network Service Chaining (NSC) working group focuses on new approaches to service insertion and deployment, providing a framework for the construction of services built using service chains. The WG focuses on the necessary protocols for the creation of service chains, and the passing of metadata from the network to service functions, and between service functions. When possible, the WG will extend existing protocols to provide service chaining functionality, and any protocol extensions will be reviewed by both the Network Service Chaining WG and by the WG responsible for the protocol being extended.

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

1) Problem Statement: this document will provide a summary of the problem space to be addressed by the Network Service Chaining WG including terminology and sample use cases.  Additionally, the WG will normalize on nomenclature and definitions for Network Service Chaining.

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

3) Service Chaining Data Plane: this document will describe on the wire data plane encapsulation in support of (2).  A single encapsulation will be selected in order to enable interoperability of data plane components.

4) Manageability: this document will address service chaining operation, monitoring and troubleshooting including relevant service chaining models such as MIBs or YANG modules, along with relevant OAM capabilities and how they are realized.

Proposed Milestones:

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

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

May 2014 Request publication of a Standards Track document specifying the data-plane (including metadata) for Service Chaining to IESG

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

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

---

From: Jerome Moisand <[email-masked]>
Date: Tue, 3 Sep 2013 22:10:05 +0000

Hi Roberta,

Small world… ;-)

Use cases: seems to me we should separate the problem statement from the use cases, the former could be spelled out at a high level and hopefully agreed upon, while gathering (and beefing up) a good collection of use cases will probably take longer. This is why I suggested a separate milestone, sorry I wasn’t clear.

BBF: yes, agreed with you about the challenges of using references and the need for a liaison. But given that many of us know each other from past experiences, we should be able to make it less formal and more directly collaborative. I’ll test the waters in this respect at the next BBF (in a couple of weeks). I’m co-editor of the BBF SIMR study document on service chaining, by the way, if this didn’t cross your radar. Goal is essentially... to gather (broadband-centric) use cases!

Cheers,
Jerome

From: Roberta Maglione (robmgl) [mailto:[email-masked]] 
Sent: Tuesday, September 03, 2013 5:00 PM
To: Jerome Moisand; Jim Guichard (jguichar); [email-masked]
Subject: RE: [nsc] NSC Working Group Charter Proposal

Hello Jerome,

 
 
Best Regards
Roberta
 
Hi Jim and al.

 
 
Tx
Jerome

To: [email-masked]
 
Greetings,

Proposed NSC WG Charter

 

 

 
 
Proposed Milestones:

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 3 Sep 2013 22:18:46 +0000

Hi Jerome,

On the use cases front we only intend to have high-level examples in the
problem statement. More detailed use cases, for example mobility, should
be separate I-D's as you pointed out and I would fully expect to see a
number of them as we move forward with this work. Not sure that we can add
this as a milestone though (?)

On 9/3/13 6:10 PM, "Jerome Moisand" <[email-masked]> wrote:

>Hi Roberta,
>
>Small worldŠ ;-)
>
>Use cases: seems to me we should separate the problem statement from the
>use cases, the former could be spelled out at a high level and hopefully
>agreed upon, while gathering (and beefing up) a good collection of use
>cases will probably take longer. This is why I suggested a separate
>milestone, sorry I wasn¹t clear.
>
>BBF: yes, agreed with you about the challenges of using references and
>the need for a liaison. But given that many of us know each other from
>past experiences, we should be able to make it less formal and more
>directly collaborative. I¹ll test the waters in this respect at the next
>BBF (in a couple of weeks). I¹m co-editor of the BBF SIMR study document
>on service chaining, by the way, if this didn¹t cross your radar. Goal is
>essentially... to gather (broadband-centric) use cases!
>
>Cheers,
>Jerome
>
>
>>As to the milestones, something about documenting use cases would seem
>>in order. As you probably know, both BBF SIMR >and ETSI NFV have such
>>ongoing activities,
> 
>1) Problem Statement: this document will provide a summary of the problem
>space to be addressed by the Network Service Chaining WG including
>terminology and sample use cases
> 
>Regarding leveraging BBF work: I fully agree with you we should not
>replicate the same work in different SDOs. However, based on my previous
>experience in BBF, I think it may be difficult to refer in internet
>drafts to BBF  work in progress documents because these documents are not
>public  until they are published, so only BBF members have access to
>them. It could be useful to have a liaison from BBF to nsc WG that
>summarizes the uses cases already agreed in BBF.
> 
>Best Regards
>Roberta
>From my first pass, something seems missing: there is a reference to a
>Service Chaining Control Plane at the very end, in the list of
>milestones, but nothing in the text alludes to it. And this is clearly
>NOT the same thing as Manageability. I do agree we need to think hard to
>such control plane matters, and this should be made more explicit in the
>charter.
> 
>As to the milestones, something about documenting use cases would seem in
>order. As you probably know, both BBF SIMR and ETSI NFV have such ongoing
>activities, albeit very new, and this should be leveraged, no point
>re-inventing the wheel. I can be used as point of contact on the BBF
>side, by the way. Anyhoo, I would just suggest to add a milestone about
>collecting use cases, either directly or via other standard bodies and
>industry forums.
> 
>Tx
>Jerome
> 
> 
>As we look forward to the formation of a working group that will focus on
>network service chaining, I would like to propose a discussion on this
>alias to try and reach consensus on an initial charter as requested by
>the routing area AD's. The following is a first draft of the charter and
>I invite you to actively participate and provide inputs into this process.
> 
>Proposed NSC WG Charter
> 
>Existing service insertion and deployment techniques have not evolved to
>meet modern network architectures and do not reflect multi-tenancy,
>virtualization, elasticity, rich classification, and other network
>requirements. Networks, servers, storage, and applications, have all
>undergone significant change in recent years: virtualization, network
>overlays, and orchestration are increasingly the norm. All of these have
>profound effects on network and services design.
> 
>Today, deploying new services, or making changes to existing services,
>often requires network topology changes. Adding and removing service
>functions is a complex, risky task, that is tied to operationalizing
>topological changes leading to mostly-static service definitions. New
>service insertion and deployment techniques must enable the concept of
>service functions as shared resources, and enable the linkage of these
>resources using service chains that represent the abstracted view of the
>required service functions, and define the order in which they should be
>applied. When a service chain is instantiated in a network, specific
>instances of service functions are selected, and a service topology is
>created and used for forwarding packets through the service chain.
> 
>A basic service chain might simply utilize an existing overlay technology
>to force traffic through the necessary service functions. However,
>additional information enables a richer service chain for more advanced
>composite services. For example, shared information (e.g., the result of
>classification) can be used to offload service function processing or
>inform other service functions about information that would otherwise be
>hard to glean. 
> 
>The Network Service Chaining (NSC) working group focuses on new
>approaches to service insertion and deployment, providing a framework for
>the construction of services built using service chains. The WG focuses
>on the necessary protocols for the creation of service chains, and the
>passing of metadata from the network to service functions, and between
>service functions. When possible, the WG will extend existing protocols
>to provide service chaining functionality, and any protocol extensions
>will be reviewed by both the Network Service Chaining WG and by the WG
>responsible for the protocol being extended.
> 
>1) Problem Statement: this document will provide a summary of the problem
>space to be addressed by the Network Service Chaining WG including
>terminology and sample use cases.  Additionally, the WG will normalize on
>nomenclature and definitions for Network Service Chaining.
> 
>2) System Architecture: this set of documents will provide a description
>of the architecture building blocks and their relationships including
>interconnection, placement of capabilities, and security models, as well
>as requirements on the control mechanisms and data plane encapsulation.
> 
>3) Service Chaining Data Plane: this document will describe on the wire
>data plane encapsulation in support of (2).  A single encapsulation will
>be selected in order to enable interoperability of data plane components.
> 
>4) Manageability: this document will address service chaining operation,
>monitoring and troubleshooting including relevant service chaining models
>such as MIBs or YANG modules, along with relevant OAM capabilities and
>how they are realized.
> 
>Proposed Milestones:
> 
>Dec 2013 Request publication of an Informational document defining the
>Network Service Chaining problem statement to the IESG
> 
>Mar 2014 Request publication of informational documents defining the
>system architecture including protocol requirements and framework to the
>IESG
> 
>May 2014 Request publication of a Standards Track document specifying the
>data-plane (including metadata) for Service Chaining to IESG
> 
>May 2014 Request publication of an informational document specifying
>Service Chaining Control Plane requirements to IESG
> 
>Dec 2014 Request publication of informational documents defining Service
>Chaining manageability requirements including MIBs, OAM, and information
>models to IESG 
> 
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Sep 2013 18:21:46 -0400

> Use cases: seems to me we should separate the problem statement from the use cases, the former could be spelled out at a high level and hopefully agreed upon, while gathering (and beefing up) a goo…

	Bonjour!

	I agree; this is for its own document. But for the moment as a means of illustrating the problem space, we put some high level examples in here. Of course, these can be moved to a problem statement draft(s) later.

	--Tom

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 Sep 2013 23:28:23 +0000

Hi Jerome,

Please find one comment inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> Use cases: seems to me we should separate the problem statement from the use cases, the former could be spelled out at a high level and hopefully agreed upon, while gathering (and beefing up) a goo…

My sense is that at this point a focused approach with a small number of milestones can yield faster and more productive results to the WG-to-be. 

I completely agree with you on the usefulness of more detailed use cases -- but at the same time those seem second order that use cases high-level enough to move the core documents forward. 

That also does not prevent start the work on separate documents with specific use cases on service chaining for mobility, broadband access, etc. but are not needed as initial WG milestones. 

Thanks!

Carlos.

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 4 Sep 2013 03:15:09 +0000

Hi Carlos, Jerome and all,

Actually I think it makes more sense to separate the problem statement from the use cases completely, since a standalone suite of use cases is easier to be aligned, otherwise, if high level use cases are coupled with problem statements and published, we can hardly change it (as I am aware, no detailed use cases is available yet).
  
Thanks,
Yuanlong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Wednesday, September 04, 2013 7:28 AM
To: Jerome Moisand
Cc: [email-masked]; Jim Guichard (jguichar); Roberta Maglione (robmgl)
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jerome,

On Sep 3, 2013, at 6:10 PM, "Jerome Moisand" <[email-masked]> wrote:

> Hi Roberta,
> 
> Small world... ;-)
> 
> Use cases: seems to me we should separate the problem statement from the use cases, the former could be spelled out at a high level and hopefully agreed upon, while gathering (and beefing up) a good collection of use cases will probably take longer. This is why I suggested a separate milestone, sorry I wasn't clear.

Thanks!

Carlos. 

> 
> BBF: yes, agreed with you about the challenges of using references and the need for a liaison. But given that many of us know each other from past experiences, we should be able to make it less formal and more directly collaborative. I'll test the waters in this respect at the next BBF (in a couple of weeks). I'm co-editor of the BBF SIMR study document on service chaining, by the way, if this didn't cross your radar. Goal is essentially... to gather (broadband-centric) use cases!
> 
> Cheers,
> Jerome
> 
>

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 4 Sep 2013 03:26:19 +0000

Hi Jim,

Given the complexity of the use cases as we had discussed in the mailing list and the reason I gave in the previous email, I think it is fair enough to add a bullet of "Informational document(s) defining Network Service Chaining use cases" as a milestone.

Thanks,
Yuanlong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, September 04, 2013 6:19 AM
To: Jerome Moisand; Roberta Maglione (robmgl); [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jerome,

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 13:04:11 +0000

Hi Yuanlong,

Yes, I think there is consensus (or at least lack of protest) that we
should include separate I-D's that specify specific use cases and as I
said before I fully expect these to be presented to the WG for
consideration as we move forward with this work.

On 9/3/13 11:26 PM, "Jiangyuanlong" <[email-masked]> wrote:

>Hi Jim,
>
>Given the complexity of the use cases as we had discussed in the mailing
>list and the reason I gave in the previous email, I think it is fair
>enough to add a bullet of "Informational document(s) defining Network
>Service Chaining use cases" as a milestone.
>
>Thanks,
>Yuanlong
>
>