Subject: [nsc] NSC Working Group Charter Proposal

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

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 19:49:52 +0000

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]
Subject: [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 16:05:14 +0200

Hi Jim,

Thank you for preparing the text.

I fully agree that, for the sake of interoperability, one standard track solution must be specified by the working group. I'm fully supportive to mention this in the charter and avoid that during the lifetime of the working group multiple solutions are envisaged.

I have some comments about the proposed deliverables and the proposed timing:

(1) I don't think it is a good idea to split the requirements into multiple documents. For the sake of consistency and also to have the big picture, I suggest only one single document be chartered to record the requirements. The requirements document should include functional requirements, manageability requirements (as per RFC5706) and security requirements. The full set of requirements should be taken into account during the design phase.

(2) The specification effort should start once the requirements are almost stable, not before.

(3) I would remove the word "metadata" from the milestones.

(4) I personally don't see a value to add dedicated items for detailed use cases. There is already an undergoing effort in other fora; no need to have redundant effort in this space. Having an abstract description level in the Problem Statement is sufficient IMHO.

(5) I suggest to add a "Analysis and Design Choices" document: Details rated to design motivations and justifications will be recorded in the analysis document while the specification document(s) focuses exclusively on the specification part. Past experience has shown that some questions are raised multiple times during the lifetime of the wg and it is not sometimes obvious to find where the decision was made and for what reason. This kind of details are hard (sometime) to find: either you need to check mailing list archives, or contact the authors. I see the design analysis document as a formal tool to record the consensus on controversial design issues. The document can also answer to "why not my favourite solution" solve the problem(s).

(6) We don't know at this stage how many specification documents will be needed. Perhaps only one Standard Track document will be required. I suggest we leave the decision on the exact number of Standard Track documents open.

To sum up: my suggestion is to go for this set of deliverables:

(a) Problem Statement document
(b) Framework document (terminology, functional elements, architecture, and overall procedure)
(c) Requirements document
(d) Design Analysis document
(e) Specification document(s)

I wouldn't object if the first charter of the future WG covers only items (a) to (d). An updated charter can be envisaged once the future WG has more visibility on the detailed set of specification documents.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mardi 3 septembre 2013 18:01
À : [email-masked]
Objet : [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 17:00:20 +0200

Dear all,

Thanks to Jim for this proposal. A few comments from my side inline, in addition to those that were recently submitted by Med (and which I agree with).
[snip]
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.
[CJ] I would smooth the first statement a bit (mostly because it depends on the nature and the number of the functions involved, as well as the networking environment). Something like: "...deployment techniques fail to address new challenging requirements raised by the introduction of emerging techniques such as multi-tenancy, virtualization, etc." I would suppress the "modern network architectures" quotation of the sentence.
Networks, servers,[CJ]  and other storage[CJ]  technologies, [CJ] let alone applications, have all undergone significant change in recent years: virtualization, network overlays, and orchestration [CJ] have increasingly become techniques that count and sometimes prevail. All of these have profound effects on network and services design.

Today, deploying new services, or making changes to existing services, often requires network topology changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading to mostly-static service definitions.
[CJ] maybe "...leading to massively static configuration procedures for network service delivery or update purposes."
New service insertion and deployment techniques
[CJ] Maybe "The structuring and the delivery of new network services assume the (smart) combination of various service functions as shared resources, and enable..."
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 invoked. 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 [CJ] according to 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.
[CJ] I don't understand the previous sentence, including the kind of causality effect between classification outcomes and shared information. Did you mean: "For example, the combined and ordered activation of a set of service functions possibly located in different regions of the network (or different network elements) is an information that will be distributed to the network elements for the sake of optimized service function and resource usage."?

The Network Service Chaining (NSC) working group focuses on new approaches to[CJ]  network service [CJ] structuring and deployment, providing a framework for the construction of services [CJ] based upon the construction of service [CJ] function chains. The WG focuses on the necessary protocols for the creation of service chains, and the [CJ] transmission of service-specific information from the network to service functions, and between service functions. When possible, the WG will extend existing protocols to provide service chaining functionality, and any protocol extensions will be reviewed by both the Network Service Chaining WG and by the WG responsible for the protocol being extended.

CJ: as already mentioned by Med, I don't think the terminology effort should be part of the PS document, but rather the framework document.

CJ: requirements should be described in a specific document.

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.
CJ: this wording is too specific and somewhat speculative (because it implicitly assumes some kind of encapsulation is needed anyway). I would relax the objective a bit, and derive the specification effort according to the contents of the Framework document that basically corresponds to Point #2 above. Likewise, I share Jerome's comment (hello Jérôme :)) about the control plane. This should be explicitly investigated as part of the Framework document, and derive the possible specification effort accordingly (for example, dynamic SF discovery capabilities may involve control plane features).

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.
CJ: corresponding manageability considerations should be documented first in the Framework.

Proposed Milestones:

Mar 2014 Request publication of informational documents defining the system architecture including protocol requirements and framework to the IESG
[CJ] Clearly distinguish between a Requirements document and a Framework document, which should not be available at the same time presumably (I would target June 2014 for the Framework document).

May 2014 Request publication of an informational document specifying Service Chaining Control Plane requirements to IESG
[CJ] Not sure I understand the difference in nature between the data plane and the control plane documents (standard vs. informational). Also, I think a gap analysis effort needs to be conducted and documented prior to any consideration about publishing that kind of specification (as also suggested by Med). This gap analysis document should be available some time in March/April, presumably.

Dec 2014 Request publication of informational documents defining Service Chaining manageability requirements including MIBs, OAM, and information models to IESG
[CJ] You should delete "requirements" from the above sentence. Not sure I would be that specific at this stage (e.g., the YANG modules mentioned earlier have disappeared from the list above) and maybe stick to the PS/Requirements/Gap analysis/Framework list of WG deliverables for the time being.

Cheers,

Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 15:55:37 +0000

Hi Christian,

Thanks for the thorough review. I am working through your comments but have one comment below in response ..

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 4, 2013 11:00 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: NSC Working Group Charter Proposal

Dear all,

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.
[CJ] I would smooth the first statement a bit (mostly because it depends on the nature and the number of the functions involved, as well as the networking environment). Something like: “…deployment techniques fail to address new challenging requirements raised by the introduction of emerging techniques such as multi-tenancy, virtualization, etc.” I would suppress the “modern network architectures” quotation of the sentence.
Networks, servers,[CJ]  and other storage[CJ]  technologies, [CJ] let alone applications, have all undergone significant change in recent years: virtualization, network overlays, and orchestration [CJ] have increasingly become techniques that count and sometimes prevail. All of these have profound effects on network and services design.

Today, deploying new services, or making changes to existing services, often requires network topology changes. Adding and removing service functions is a complex, risky task, that is tied to operationalizing topological changes leading to mostly-static service definitions.
[CJ] maybe “…leading to massively static configuration procedures for network service delivery or update purposes.”
New service insertion and deployment techniques
[CJ] Maybe “The structuring and the delivery of new network services assume the (smart) combination of various service functions as shared resources, and enable…”
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 invoked. 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 [CJ] according to 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.
[CJ] I don’t understand the previous sentence, including the kind of causality effect between classification outcomes and shared information. Did you mean: “For example, the combined and ordered activation of a set of service functions possibly located in different regions of the network (or different network elements) is an information that will be distributed to the network elements for the sake of optimized service function and resource usage.”?

Jim> no. This last sentence basically means that a service function might perform a specific action, the result of which may be useful to one or more service functions further down the chain. The example given is classification; the results of this classification might be passed to a downstream service function so that it need not perform said classification again but rather glean the results of the initial classification from the upstream service function. Given this do you have any suggested text changes to make this clearer?

CJ: as already mentioned by Med, I don’t think the terminology effort should be part of the PS document, but rather the framework document.

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.
CJ: this wording is too specific and somewhat speculative (because it implicitly assumes some kind of encapsulation is needed anyway). I would relax the objective a bit, and derive the specification effort according to the contents of the Framework document that basically corresponds to Point #2 above. Likewise, I share Jerome’s comment (hello Jérôme :)) about the control plane. This should be explicitly investigated as part of the Framework document, and derive the possible specification effort accordingly (for example, dynamic SF discovery capabilities may involve control plane features).

Proposed Milestones:

Dec 2014 Request publication of informational documents defining Service Chaining manageability requirements including MIBs, OAM, and information models to IESG
[CJ] You should delete “requirements” from the above sentence. Not sure I would be that specific at this stage (e.g., the YANG modules mentioned earlier have disappeared from the list above) and maybe stick to the PS/Requirements/Gap analysis/Framework list of WG deliverables for the time being.

Cheers,

Christian.

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 18:02:43 +0200

Hello Jim,

Thanks for the clarification.
[snip]
Jim> no. This last sentence basically means that a service function might perform a specific action, the result of which may be useful to one or more service functions further down the chain. The example given is classification; the results of this classification might be passed to a downstream service function so that it need not perform said classification again but rather glean the results of the initial classification from the upstream service function. Given this do you have any suggested text changes to make this clearer?
[CJ] I guess I would use your explanation as the illustrative sentence: "For example, the results of a classification might be passed to a downstream function..."

Cheers,

Christian.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 16:06:46 +0000

Hi Christian,

How about "For example, shared information, such as the results of a classification function, may be passed to downstream service functions to enable the offloading of service function processing or to share information that would otherwise be hard to glean" - does that work?

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 4, 2013 12:02 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: NSC Working Group Charter Proposal

Hello Jim,

Thanks for the clarification.
[snip]
Jim> no. This last sentence basically means that a service function might perform a specific action, the result of which may be useful to one or more service functions further down the chain. The example given is classification; the results of this classification might be passed to a downstream service function so that it need not perform said classification again but rather glean the results of the initial classification from the upstream service function. Given this do you have any suggested text changes to make this clearer?
[CJ] I guess I would use your explanation as the illustrative sentence: “For example, the results of a classification might be passed to a downstream function…”

Cheers,

Christian.

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 18:07:52 +0200

Yes - thanks.

Cheers,

Christian.

De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mercredi 4 septembre 2013 18:07
À : JACQUENET Christian IMT/OLN; [email-masked]
Objet : Re: NSC Working Group Charter Proposal

Hi Christian,

Hello Jim,

Cheers,

Christian.

Thank you.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 17:37:01 +0000

Hi Med,

Comment inline ..

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 4, 2013 10:05 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: NSC Working Group Charter Proposal

Hi Jim,

I fully agree that, for the sake of interoperability, one standard track solution must be specified by the working group. I’m fully supportive to mention this in the charter and avoid that during the lifetime of the working group multiple solutions are envisaged.

(1) I don’t think it is a good idea to split the requirements into multiple documents. For the sake of consistency and also to have the big picture, I suggest only one single document be chartered to record the requirements. The requirements document should include functional requirements, manageability requirements (as per RFC5706) and security requirements. The full set of requirements should be taken into account during the design phase.

(3) I would remove the word “metadata” from the milestones.

Jim> this wording is directly associated to REQ#24 of draft-boucadair-chaining-requirements so would a replacement of "metadata" with "context data" work for you? If not please suggest an alternative, other than removal ;-).

(4) I personally don’t see a value to add dedicated items for detailed use cases. There is already an undergoing effort in other fora; no need to have redundant effort in this space. Having an abstract description level in the Problem Statement is sufficient IMHO.

(5) I suggest to add a “Analysis and Design Choices” document: Details rated to design motivations and justifications will be recorded in the analysis document while the specification document(s) focuses exclusively on the specification part. Past experience has shown that some questions are raised multiple times during the lifetime of the wg and it is not sometimes obvious to find where the decision was made and for what reason. This kind of details are hard (sometime) to find: either you need to check mailing list archives, or contact the authors. I see the design analysis document as a formal tool to record the consensus on controversial design issues. The document can also answer to “why not my favourite solution” solve the problem(s).

(6) We don’t know at this stage how many specification documents will be needed. Perhaps only one Standard Track document will be required. I suggest we leave the decision on the exact number of Standard Track documents open.

I wouldn’t object if the first charter of the future WG covers only items (a) to (d). An updated charter can be envisaged once the future WG has more visibility on the detailed set of specification documents.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mardi 3 septembre 2013 18:01
À : [email-masked]<mailto:[email-masked]>
Objet : [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 4 Sep 2013 17:48:45 +0000

Hi Med,

Comments inline…

Thanks!
Paul

On Sep 4, 2013, at 7:05 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Jim,

PQ>  This space is moving quickly, with a lot of vendor and operator activity.  We need this WG to be at the forefront of service chaining, consequently, we should focus on a few, focused deliverables.  Between the problem statement and the requirements documents (along with use cases as needed), we have plenty to drive the designs.

PQ>  I think the current charter defines the one we know we need now.  This can certainly certainly evolve over time but the WG must be chartered to deliver protocol documents to be truly effective at driving interoperability.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Jim Guichard (jguichar)
Envoyé : mardi 3 septembre 2013 18:01
À : [email-masked]<mailto:[email-masked]>
Objet : [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Sep 2013 14:33:05 -0400

Clipping for focus...

> Thank you for preparing the text.
...
> I wouldn’t object if the first charter of the future WG covers only
> items (a) to (d). An updated charter can be envisaged once the future WG
> has more visibility on the detailed set of specification documents.
>
> Cheers,
>
> Med

I find this list difficult to understand.  And the omissions of certain 
items from the previous proposal cause me personally some concern.

Separating the problem statement, framework, requirements, and "design 
analysis" produces a multiplicity of documents which will divide the WGs 
efforts without, as far as I can tell, improving clarity.

I also find the notion of a Design Analysis odd.  What we need is an 
architecture or design to drive the protocol effort.  From where I sit, 
we need to pick an approach to the problem, and document that pick.  In 
many ways, it is quite likely that we will have to pick simply because a 
choice is needed, not because one is universally better than another.  I 
would strongly prefer that the focus of the document be on the actual 
answer.

Similarly, while I find use case drafts useful information for the WG to 
consider, I think that arguing about which use cases we should put in an 
RFC, would not be a good use of the WGs time and energy.  Some 
discussion of importance is inevitable as we decide which pieces of the 
problem to solve well, which pieces to solve awkwardly, and which pieces 
not to solve.

Yours,
Joel

---

From: "Joachimpillai, Damascene M" <[email-masked]>
Date: Wed, 4 Sep 2013 14:41:33 -0400

I completely concur with Joel here. I think we need two things:
1) A clear problem statement
2) An Architecture that addresses the problem 

Once these two are established then we can go into the details of how.

-- DJ

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 04, 2013 2:33 PM
To: [email-masked]
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] NSC Working Group Charter Proposal

Clipping for focus...

...
> I wouldn't object if the first charter of the future WG covers only 
> items (a) to (d). An updated charter can be envisaged once the future 
> WG has more visibility on the detailed set of specification documents.
>
> Cheers,
>
> Med

I find this list difficult to understand.  And the omissions of certain items from the previous proposal cause me personally some concern.

Separating the problem statement, framework, requirements, and "design analysis" produces a multiplicity of documents which will divide the WGs efforts without, as far as I can tell, improving clarity.

I also find the notion of a Design Analysis odd.  What we need is an architecture or design to drive the protocol effort.  From where I sit, we need to pick an approach to the problem, and document that pick.  In many ways, it is quite likely that we will have to pick simply because a choice is needed, not because one is universally better than another.  I would strongly prefer that the focus of the document be on the actual answer.

Similarly, while I find use case drafts useful information for the WG to consider, I think that arguing about which use cases we should put in an RFC, would not be a good use of the WGs time and energy.  Some discussion of importance is inevitable as we decide which pieces of the problem to solve well, which pieces to solve awkwardly, and which pieces not to solve.

Yours,
Joel
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 04 Sep 2013 10:58:38 -0800

> efforts without, as far as I can tell, improving clarity.

I agree quite strongly with this.

> RFC, would not be a good use of the WGs time and energy.  

I'm not sure.  Noting the feeding frenzy in this space, it may
be worthwhile to define a few use cases that must be satisfied
as a way to bring order to the chaos.  On the other hand, getting
the use cases laid out may bring about a slugfest of its own.
I'm ambivalent about this but I do think it's worth trying to
anticipate process issues and to think about how to avoid this
turning into another nvo3.  Use cases may or may not be helpful.

Melinda

---

From: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 19:55:47 +0000

"Feeding frenzy" is apt.  I'm personally hoping we can constrain the
use-case love-fest within it's own document or any document in the WG to
those that illustrate/support specific requirements relevant to the
general specifications of the WG - that is, those that make the case for
specific metadata needs, site relevance to the header discussion, etc ...

I expect these could be paragraph-to-page length summaries with pointers
to relevant architectures, drawings, related work (if they are included in
a document at all) - versus sweeping architectural disgorgement wherein
one or two points are actually salient/pertinent to the overall discussion
at hand.

Having READ the various/numerous/copious use-case whitepapers in other
SDOs/quasi-SDOs/study_groups, I personally think anything longer goes in
the round, can-shaped object on my desktop.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Sep 2013 20:45:21 +0000

One clarification on Work Item #3:
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.

Is it really "A single encapsulation"?
The encapsulation should depend on the underlay networks. Underlay network could be IP based, MPLS based, or Ethernet based.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, September 03, 2013 11:01 AM
To: [email-masked]
Subject: [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 21:27:08 +0000

Linda,

I think that is a fundamental issue for the group to decide.   If the goal is a single encapsulation, then IMO it would have to be IP-based, since that is the most common denominator.

   Ron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 4:45 PM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Linda

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

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

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

Our approach with the charter has been to document a couple of high-level
use cases within the problem statement if only to educate folks on what
the heck we are talking about. Outside of this we have avoided putting use
cases in the charter as specific work items and taken the approach that if
folks want to write use case I-D's and submit them to the WG for
consideration then they are free to do so. I believe this is the right and
most productive approach for the WG to take.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Sep 2013 21:36:02 +0000

IMO, "single encapsulation" is too  limiting. Many of today's service provider networks are MPLS based. In addition, there are even Ethernet based networks (if you  venture into IEEE802 or CEF).

How about: "A single encapsulation per underlay network will be selected.."?

Linda

From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, September 04, 2013 4:27 PM
To: Linda Dunbar; Jim Guichard (jguichar); [email-masked]
Subject: RE: NSC Working Group Charter Proposal

Linda,

   Ron

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Lucy yong <[email-masked]>
Date: Wed, 4 Sep 2013 21:38:10 +0000

The first charter should focus on the problem statement, architecture, use case, and requirement;  Not on specifying one solution. Therefore, work item #3 should not be in the first charter.

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Sep 2013 21:41:30 +0000

Agree.

Linda

From: Lucy yong
Sent: Wednesday, September 04, 2013 4:38 PM
To: Linda Dunbar; Jim Guichard (jguichar); [email-masked]
Subject: RE: NSC Working Group Charter Proposal

Lucy

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 4 Sep 2013 21:42:47 +0000

Ron,

The encapsulation in this context refers to the service chain specific dataplane encapsulation (i.e. a service header) used for chaining.  That in turn is wrapped in the overlay (we will strive to be overlay agnostic), which in turn is carried via the underlay (we are agnostic here as well).

Let's revise the proposed charter to make sure that it is clear on this point.

Paul

On Sep 4, 2013, at 2:27 PM, Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:

Linda,

   Ron

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 4:45 PM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] NSC Working Group Charter Proposal

Is it really “A single encapsulation”?
The encapsulation should depend on the underlay networks. Underlay network could be IP based, MPLS based, or Ethernet based.

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Lucy yong <[email-masked]>
Date: Wed, 4 Sep 2013 21:44:34 +0000

Service chaining scenarios is not clear to me yet. The problem statement draft (v03) has the section but not content. Suggest giving clear use case first before spending a lot of time on charter text. If we all clear what is the use case and problem, will be much easy to agree on the charter scope.

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, September 04, 2013 4:30 PM
To: Ken Gray; Melinda Shore; [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Our approach with the charter has been to document a couple of high-level use cases within the problem statement if only to educate folks on what the heck we are talking about. Outside of this we have avoided putting use cases in the charter as specific work items and taken the approach that if folks want to write use case I-D's and submit them to the WG for consideration then they are free to do so. I believe this is the right and most productive approach for the WG to take.

On 9/4/13 3:55 PM, "Ken Gray" <[email-masked]> wrote:

>use-case love-fest within it's own document or any document in the WG 
>to those that illustrate/support specific requirements relevant to the 
>general specifications of the WG - that is, those that make the case 
>for specific metadata needs, site relevance to the header discussion, etc ...
>
>I expect these could be paragraph-to-page length summaries with 
>pointers to relevant architectures, drawings, related work (if they are 
>included in a document at all) - versus sweeping architectural 
>disgorgement wherein one or two points are actually salient/pertinent 
>to the overall discussion at hand.
>
>SDOs/quasi-SDOs/study_groups, I personally think anything longer goes 
>in the round, can-shaped object on my desktop.
>
>
>
>>> Separating the problem statement, framework, requirements, and 
>>>"design  analysis" produces a multiplicity of documents which will 
>>>divide the WGs  efforts without, as far as I can tell, improving 
>>>clarity.
>>
>>> Similarly, while I find use case drafts useful information for the 
>>>WG to  consider, I think that arguing about which use cases we should 
>>>put in an  RFC, would not be a good use of the WGs time and energy.
>>
>>I'm not sure.  Noting the feeding frenzy in this space, it may be 
>>worthwhile to define a few use cases that must be satisfied as a way 
>>to bring order to the chaos.  On the other hand, getting the use cases 
>>laid out may bring about a slugfest of its own.
>>anticipate process issues and to think about how to avoid this turning 
>>into another nvo3.  Use cases may or may not be helpful.
>>
>>Melinda
>>
>>

---

From: Lucy yong <[email-masked]>
Date: Wed, 4 Sep 2013 21:51:21 +0000

I don't think that this belongs to the first charter. This can be captured in the requirement, but not a work item in the first charter.
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Wednesday, September 04, 2013 4:43 PM
To: Ron Parker
Cc: [email-masked]; Jim Guichard (jguichar); Linda Dunbar
Subject: Re: [nsc] NSC Working Group Charter Proposal

Ron,

Paul

Linda,

   Ron

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 21:57:33 +0000

Thanks, Paul.   I was thinking of the overlay + chain-specific when I was thinking "encapsulation" (e.g., a GRE-with-key like construct).

   Ron

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Wednesday, September 04, 2013 5:43 PM
To: Ron Parker
Cc: Linda Dunbar; Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Ron,

Paul

Linda,

   Ron

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 22:02:55 +0000

I disagree, this working group must be focused on solutions and not pontification over terminology or a laundry list of use cases. Having said that you will note in the milestones that the problem statement and requirements are the first work items to be delivered followed by the data plane that will support both. It is perfectly acceptable to provide a planned outline of the WG activities and this is reflected in the charter.

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 4, 2013 5:38 PM
To: 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] NSC Working Group Charter Proposal

Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] NSC Working Group Charter Proposal

Linda

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

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Lucy yong <[email-masked]>
Date: Wed, 4 Sep 2013 22:12:03 +0000

Not many people well understand the problem and use case yet. The bof in IETF87 does not convey the issues clearly. So the first charter should solve that first before to work on the solution. The work items listed in the charter do not indicate has the order. The time table clear indicates they will be worked at the same time.  I agree that we should standardize one data plane solution, but don't think the schedule is proper.

Lucy

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, September 04, 2013 5:03 PM
To: Lucy yong; Linda Dunbar; [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Lucy

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 22:38:17 +0000

Please, count me out of "not many people".

For the members of "not many people", help save us a year of introspection and please see the huge amount of use case  and best practice gorge in ETSI documentation or mailing lists, regurgitation in IEEE special work groups and ONF special work groups, numerous articles restating the position papers therein.  All easily accessible by using Google, Bing or other engines to search for "NFV".  This may appear sarcastic, but … really, it's not intended to be overly so (I think "tired of hearing this" is more appropriate) …you will be amazed at what has already been writ, spoken and debated in the name of Service Chaining and Service Virtualization.

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Wed, 4 Sep 2013 22:12:03 +0000
To: "Jim Guichard (jguichar)" <[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] NSC Working Group Charter Proposal

Not many people well understand the problem and use case yet. The bof in IETF87 does not convey the issues clearly. So the first charter should solve that first before to work on the solution. The work items listed in the charter do not indicate has the order. The time table clear indicates they will be worked at the same time.  I agree that we should standardize one data plane solution, but don’t think the schedule is proper.

Lucy

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, September 04, 2013 5:03 PM
To: Lucy yong; Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] NSC Working Group Charter Proposal

Lucy

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, September 04, 2013 3:45 PM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] NSC Working Group Charter Proposal

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 04 Sep 2013 16:25:25 -0800

On 9/4/13 1:36 PM, Linda Dunbar wrote:
> IMO, “single encapsulation” is too  limiting. Many of today’s service
> provider networks are MPLS based. In addition, there are even Ethernet
> based networks (if you  venture into IEEE802 or CEF).

I think this would be an extraordinary mistake, in the absence
of a clear, explicit need.  That is to say, somebody needs to
explain, with SPECIFICS, why a particular encapsulation is not
going to work on a given network.  Just because someone's
using MPLS for transport doesn't mean that a TCP, UDP, IP,
SCTP, or whateverP won't be useful and won't work.  This
should be no more complicated than necessary.

Melinda

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 4 Sep 2013 20:45:14 -0400

I'm with Ken in this one. I was just baffled about that comment. As I said earlier, there are real working examples of NFV for sale //now//.  one goal is to definitely help them work together rather than trying to have them look like some theoretical thing.

Tom 

Von meinem iPhone gesendet

On Sep 4, 2013, at 6:38 PM, Ken Gray <[email-masked]> wrote:

> From: Lucy yong <[email-masked]>
> To: "Jim Guichard (jguichar)" <[email-masked]>, Linda Dunbar <[email-masked]>, "[email-masked]" <[email-masked]>
> From: Lucy yong <[email-masked]>
> To: Linda Dunbar <[email-masked]>, Microsoft Office User <[email-masked]>, "[email-masked]" <[email-masked]>
> From:[email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
> From:[email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 5 Sep 2013 03:41:22 +0000

Hi Jim,

Thanks for the hard work on drafting the charter.

In the proposed NSC charter, it says:

"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."

Firstly, the relation of "operation, monitoring and troubleshooting" and "OAM" is not very clear to me.

Secondly, though YANG module is a good piece of work, I don't think it should be put in the list of NSC deliverables, since YANG related specification used to belong to OPS area. We can transfer it to OPS (after information models are mature enough) and the expertise should be readily found there.

I would like to propose the following texts:

4) Manageability: this document will address service chaining management including relevant service chaining MIBs and information models, and service chaining OAM.

Splitting OAM into a separate item seems another option as it mainly solves traceability of service chaining.

Finally,  the proposed timeline is not very practical IMHO (plus one year for each item in the Milestone?).

Regards,
Yuanlong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, September 04, 2013 12:01 AM
To: [email-masked]
Subject: [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 11:40:19 +0000

Hi Yuanlong,

Many thanks for this and I agree it could be clearer. I have updated the charter to reflect your inputs.

From: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 4, 2013 11:41 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Zhuhengjun <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jim,

“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.”

Firstly, the relation of “operation, monitoring and troubleshooting” and “OAM” is not very clear to me.

Secondly, though YANG module is a good piece of work, I don’t think it should be put in the list of NSC deliverables, since YANG related specification used to belong to OPS area. We can transfer it to OPS (after information models are mature enough) and the expertise should be readily found there.

Regards,
Yuanlong

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 11:56:39 +0000

Greetings,

I have updated the charter as follows based on all comments received thus far. There have been lots of inputs and this charter may not reflect all of them (hopefully it is pretty close). Please take time to review and continue the discussion.

Proposed NSC WG Charter – Take two

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

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

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

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

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

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

Proposed Milestones:

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

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Sep 2013 08:05:32 -0400

Small clarification.
While all YANG models have been done by netmod to date, it seems 
extremely unlikely that anyone expects taht to remain the case. 
Certainly and YANG modules produced would need review by YANG experts, 
but just as SNMP MIB modules are normally produced by the topic group, 
not an SNMP working group, a similar approach makes sense for YANG modules.

Yours,
Joel

On 9/4/13 11:41 PM, Jiangyuanlong wrote:
> “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.”
>
> Secondly, though YANG module is a good piece of work, I don’t think it
> should be put in the list of NSC deliverables, since YANG related
> specification used to belong to OPS area. We can transfer it to OPS
> (after information models are mature enough) and the expertise should be
> readily found there.
>
> 4) Manageability: this document will address service chaining management
> including relevant service chaining MIBs and information models, and
> service chaining OAM.
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of
> *Jim Guichard (jguichar)
> *Sent:* Wednesday, September 04, 2013 12:01 AM
> *To:* [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.
>
> 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: Thu, 5 Sep 2013 08:19:59 -0400

> Secondly, though YANG module is a good piece of work, I don’t think it should be put in the list of NSC deliverables, since YANG related specification used to belong to OPS area. We can transfer it…

	It is included because Yang modules, like MIB modules, are very appropriate for any working group to deliver as part of their work items.

> Finally,  the proposed timeline is not very practical IMHO (plus one year for each item in the Milestone?).

	The timelines are not set in stone and are ultimately decided by the ADs; they are just place holders now.

	--Tom

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 5 Sep 2013 12:56:50 +0000

Hi Joel,

Not sure what happened during the last few weeks, but at least the minutes of NETMOD WG in IETF 87th clearly showed it is too early to say "extremely unlikely that anyone expects taht to remain the case ".  

Regards,
Yuanlong

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, September 05, 2013 8:06 PM
To: Jiangyuanlong
Cc: Jim Guichard (jguichar); [email-masked]; Zhuhengjun
Subject: Re: [nsc] NSC Working Group Charter Proposal

Small clarification.

Yours,
Joel

On 9/4/13 11:41 PM, Jiangyuanlong wrote:
> "4) Manageability: this document will address service chaining
> capabilities and how they are realized."
>
> Secondly, though YANG module is a good piece of work, I don't think it

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Sep 2013 13:03:52 +0000

Although I far prefer the expressiveness and readability of YANG, it is certainly possible to create semantically equivalent MIBs and YANG modules.

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiangyuanlong
Sent: Thursday, September 05, 2013 8:57 AM
To: Joel M. Halpern
Cc: [email-masked]; Jim Guichard (jguichar); Zhuhengjun
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Joel,

Regards,
Yuanlong

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, September 05, 2013 8:06 PM
To: Jiangyuanlong
Cc: Jim Guichard (jguichar); [email-masked]; Zhuhengjun
Subject: Re: [nsc] NSC Working Group Charter Proposal

Small clarification.
While all YANG models have been done by netmod to date, it seems extremely unlikely that anyone expects taht to remain the case. 
Certainly and YANG modules produced would need review by YANG experts, but just as SNMP MIB modules are normally produced by the topic group, not an SNMP working group, a similar approach makes sense for YANG modules.

Yours,
Joel

On 9/4/13 11:41 PM, Jiangyuanlong wrote:
> (after information models are mature enough) and the expertise should 
> be readily found there.
>
> 4) Manageability: this document will address service chaining 
> management including relevant service chaining MIBs and information 
> models, and service chaining OAM.
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Jim Guichard (jguichar)
> 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.
>
> Existing service insertion and deployment techniques have not evolved 
> to meet modern network architectures and do not reflect multi-tenancy, 
> overlays, and orchestration are increasingly the norm. All of these 
> have profound effects on network and services design.
>
> 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.
>
> 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.
>
> extensions will be reviewed by both the Network Service Chaining WG 
> and by the WG responsible for the protocol being extended.
>
> 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 
> system architecture including protocol requirements and framework to 
> the IESG
>
> Dec 2014 Request publication of informational documents defining 
> Service Chaining manageability requirements including MIBs, OAM, and 
> information models to IESG
>
>
>

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 5 Sep 2013 13:10:43 +0000

From: Thomas Nadeau [mailto:[email-masked]]
Sent: Thursday, September 05, 2013 8:20 PM
To: Jiangyuanlong
Cc: Jim Guichard (jguichar); [email-masked]; Zhuhengjun
Subject: Re: [nsc] NSC Working Group Charter Proposal

On Sep 4, 2013:11:41 PM, at 11:41 PM, Jiangyuanlong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jim,

       It is included because Yang modules, like MIB modules, are very appropriate for any working group to deliver as part of their work items.
[JY] Just as Joel said, unlike MIB, Yang modules are used to be specified in NETMOD WG.

       The timelines are not set in stone and are ultimately decided by the ADs; they are just place holders now.
[JY] Yes, I understand the whole charter is not set in stone, but maybe we can save our ADs some work as they have been so busy already:)

       --Tom

Regards,
Yuanlong

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, September 04, 2013 12:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 5 Sep 2013 14:24:04 +0000

I like Tom's suggestion of splitting OAM from Manageability. I see Manageability as ways to conveniently configure the chaining of services, whereas OAM is more for monitoring and trouble shooting.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Thursday, September 05, 2013 7:20 AM
To: Jiangyuanlong
Cc: [email-masked]; Jim Guichard (jguichar); Zhuhengjun
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jim,

          --Tom

Regards,
Yuanlong

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 5 Sep 2013 14:45:07 +0000

Jim,

This version hasn't addressed the comments on Bullet 3 of requiring a single encapsulation being too limiting or may not even be realistic.

Several people on other email thread (i.e. "outcome of NSC BoF") stated that the "services" in the NSC context can be Layer 2-3 services or Layer 4-7 services.

For Layer 2-3 services, IETF has standardized Explicit Routing Object (ERO) to dictate data flows traversing a pre-determined sequence of Layer 3 nodes, or using BGP control plane to dictate next hop.

I am not advocating that policy based routing (e.g. ERO)  should be in the scope of NSC.  But I can't see how the current proposed scope excludes  those policy based routing schemes that have been deployed in the industry.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 6:57 AM
To: [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter - Take two

Proposed Milestones:

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 16:50:49 +0200

Hi Jim,

I have nothing against the word "metadata" itself.
You can maintain it if you prefer, but it seems odd to call only that technical aspect for that milestone.

Cheers,
Med

De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mercredi 4 septembre 2013 19:37
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: NSC Working Group Charter Proposal

Hi Med,

Comment inline ..

Hi Jim,

Cheers,
Med

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 16:56:29 +0200

Hi Paul,

Please see inline.
Cheers,
Med

De : Paul Quinn (paulq) [mailto:[email-masked]]
Envoyé : mercredi 4 septembre 2013 19:49
À : BOUCADAIR Mohamed IMT/OLN
Cc : Jim Guichard (jguichar); [email-masked]
Objet : Re: [nsc] NSC Working Group Charter Proposal

Hi Med,

Comments inline...

Thanks!
Paul

Hi Jim,

PQ>  This space is moving quickly, with a lot of vendor and operator activity.  We need this WG to be at the forefront of service chaining, consequently, we should focus on a few, focused deliverables.  Between the problem statement and the requirements documents (along with use cases as needed), we have plenty to drive the designs.
[Med] As I mentioned above, I don't see a need to have detailed use case documents (this is already done in other for a). We will need anyway some kind of analysis to agree on the design choice as I'm naively assuming that the group will be open to other proposals than what we have on the table and there will be a need to answer to "why not my favorite approach". The analysis document is a tool to help in advancing the specification effort. In order to better see what I have in mind for the analysis document, you may refer to this effort we initiated with Ron: http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00.

Cheers,
Med

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 17:03:05 +0200

Hi Joel,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Joel M. Halpern [mailto:[email-masked]]
>Envoyé : mercredi 4 septembre 2013 20:33
>I also find the notion of a Design Analysis odd.

[Med] The motivation for such analysis document are explained in the core of my message. But to have something concrete, what I have in mind is something close to the effort available at: http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00. 

  What we need is an
>architecture or design to drive the protocol effort. 

[Med] We are in full agreement here. This is what I meant by the framework document. 

 From where I sit,
>RFC, would not be a good use of the WGs time and energy. 

[Med] My suggestion is not charter any item for the use cases.. but provide a high level description in the problem statement.

 Some
>problem to solve well, which pieces to solve awkwardly, and which pieces

[Med] That's part of the design considerations & analysis effort imho.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Sep 2013 11:05:01 -0400

While it is true that manageability and OAM are two different things, 
that does not inevitably lead to the conclusion that we need two 
documents.  In fact, the two are related, and my guess is that we would 
be better served with one document describing both.

If we have to develop new OAM protocol mechanisms then that would 
probably mean we need separate documents.  It would also suggest we are 
making mistakes.

Yours,
Joel

On 9/5/13 10:24 AM, Linda Dunbar wrote:
> I like Tom’s suggestion of splitting OAM from Manageability. I see
> Manageability as ways to conveniently configure the chaining of
> services, whereas OAM is more for monitoring and trouble shooting.
>
> Linda
>
> *Thomas Nadeau
> *Sent:* Thursday, September 05, 2013 7:20 AM
> *To:* Jiangyuanlong
> *Cc:* [email-masked]; Jim Guichard (jguichar); Zhuhengjun
> *Subject:* Re: [nsc] NSC Working Group Charter Proposal
>
> On Sep 4, 2013:11:41 PM, at 11:41 PM, Jiangyuanlong
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
> Hi Jim,
>
> It is included because Yang modules, like MIB modules, are very
> appropriate for any working group to deliver as part of their work items.
>
>
>
> *From:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]
> <mailto:[email-masked]>]*On Behalf Of*Jim Guichard (jguichar)
> *Sent:*Wednesday, September 04, 2013 12:01 AM
> *To:[email-masked] <mailto:[email-masked]>
> *Subject:*[nsc] NSC Working Group Charter Proposal
>
> Greetings,
>
> functionsis a complex, risky task, that is tied to operationalizing
> Chaining manageability requirements including MIBs, OAM, and
> informationmodels to IESG
>
> [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 17:05:02 +0200

Hi Linda,

For the sake of interoperability, I vote for having one single encapsulation scheme in the standard track. Opening the door for multiple alternatives will induce an extra complexity. We should avoid that.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Linda Dunbar
Envoyé : mercredi 4 septembre 2013 23:36
À : Ron Parker; Jim Guichard (jguichar); [email-masked]
Objet : Re: [nsc] NSC Working Group Charter Proposal

Linda

From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, September 04, 2013 4:27 PM
To: Linda Dunbar; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: RE: NSC Working Group Charter Proposal

Linda,

   Ron

Linda

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Sep 2013 11:07:44 -0400

From this note, it sounds like you want to fold the actual architecture 
into the Framework.  I suppose that we could call it "Framework and 
Architecture".  My thought in calling it "Architecture was to focus on 
the part we really need to deliver, and not title the document about the 
supporting material.

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 17:13:06 +0200

Re-,

Yes, "Framework and Architecture" is better. 

Thanks Joel.

Cheers,
Med

>Envoyé : jeudi 5 septembre 2013 17:08
>WG
>> [Med] The motivation for such analysis document are explained in the core
>of my message. But to have something concrete, what I have in mind is
>something close to the effort available at:
>http://tools.ietf.org/html/draft-boucadair-chaining-design-analysis-00.
>>
>>
>>    What we need is an
>> [Med] My suggestion is not charter any item for the use cases.. but
>provide a high level description in the problem statement.
>>
>>
>>   Some

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 16:00:35 +0000

Linda,

The service chaining effort has nothing to do with traffic engineering and I am puzzled as to why you would think so. We have been back and forth on the discussion of layering and from what I can see there is consensus on the list that we need not stall this effort through pontification of terminology or causing confusion where there is none to the majority of participants on the alias.

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 5, 2013 10:45 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nsc] NSC Working Group Charter Proposal

Jim,

This version hasn’t addressed the comments on Bullet 3 of requiring a single encapsulation being too limiting or may not even be realistic.

Several people on other email thread (i.e. “outcome of NSC BoF”) stated that the “services” in the NSC context can be Layer 2-3 services or Layer 4-7 services.

I am not advocating that policy based routing (e.g. ERO)  should be in the scope of NSC.  But I can’t see how the current proposed scope excludes  those policy based routing schemes that have been deployed in the industry.

Linda

Greetings,

Proposed Milestones:

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 5 Sep 2013 16:21:55 +0000

Jim,

The service chaining effort has nothing to do with traffic engineering and I am puzzled as to why you would think so.

[Linda]No, I don't believe that service chaining effort is about chaining Layer2/3 links & nodes across network.  That is why I sent several emails on the other email threads to advocate the necessity of differentiating the "Services" in the context of NSC from typical Layer2/3 services.
However, some people on the other thread stated that Layer 2/3 nodes chaining shouldn't be excluded.

I simply want to point out that the current scope doesn't have clear definition about "services".  Therefore, the current scope doesn't preclude chaining Layer 2/3 nodes based on control plane policy. (I am not saying that I want to do so).

Linda

Jim,

Linda

Greetings,

Proposed Milestones:

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Sep 2013 08:57:30 -0800

On 9/5/13 6:45 AM, Linda Dunbar wrote:
> This version hasn’t addressed the comments on Bullet 3 of requiring a
> single encapsulation being too limiting or may not even be realistic.

There's no agreement that that's the case.

Melinda

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Sep 2013 17:44:17 +0000

I apologize if I'm being thick on this, but I'm still having trouble with the meaning of "encapsulation" here.   It has been pointed out that it is the thing that carries information like chain id, hop index, and possibly metadata about the flow, but excludes the "overlay" encapsulation.    So if I think about something that resembles GRE, when we say encapsulation, we are meaning the part of GRE that has the key but not the part of GRE that adds another IP header.    Where I really get twisted around the axle is if I think about this information being embedded in an IPv4 option or IPv6 extension header.   Not that we're necessarily choosing those, but if we did, would we call that "encapsulation"?

Thanks.

    Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Thursday, September 05, 2013 12:58 PM
To: [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

On 9/5/13 6:45 AM, Linda Dunbar wrote:
> This version hasn't addressed the comments on Bullet 3 of requiring a 

Melinda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 17:48:30 +0000

Hi Ron,

By encapsulation we mean something inserted between the transport
encapsulation and the original packet payload. There are two things that
need to happen; (1) identify that "service chaining" information follows
the transport header, and (2) encapsulate the actual service chaining
information. Now you could go down the path of trying to force fit the
service chaining information into the transport but that imho is a mistake
we should avoid.

On 9/5/13 1:44 PM, "Ron Parker" <[email-masked]> wrote:

>I apologize if I'm being thick on this, but I'm still having trouble with
>the meaning of "encapsulation" here.   It has been pointed out that it is
>the thing that carries information like chain id, hop index, and possibly
>metadata about the flow, but excludes the "overlay" encapsulation.    So
>if I think about something that resembles GRE, when we say encapsulation,
>we are meaning the part of GRE that has the key but not the part of GRE
>that adds another IP header.    Where I really get twisted around the
>axle is if I think about this information being embedded in an IPv4
>option or IPv6 extension header.   Not that we're necessarily choosing
>those, but if we did, would we call that "encapsulation"?
>
>Thanks.
>
>    Ron
>
>

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 5 Sep 2013 18:14:15 +0000

As previously mentioned, the control plane is a bit missing.

Let me suggest you just amend point 3) to say:

==>

3) Service Chaining Data & Control 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. Supporting control plane protocol elements will be added as needs be (as a separate document).

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 7:57 AM
To: [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed Milestones:

---

From: Rob Shakir <[email-masked]>
Date: Thu, 5 Sep 2013 19:41:46 +0100

Linda,

I'm afraid to say that I agree that there is not a clear need for clarification on which layers are targetede. We should allow both L2-3 chaining and L4-7. Restricting at this time breaks use cases such as those L4-7 services which are implemented as a "bump in the wire" rather than being explicitly individual hops (which does not clearly fit into either of your definitions below).

Mechanisms that allow TE may also allow chaining of services -- since both may be about steering through explicit paths in the network. The key thing is that the problem statement here is trying to do this for reasons *other* than those that are typical of TE solutions.

Kind regards,
r.

On 5 Sep 2013, at 17:21, Linda Dunbar <[email-masked]> wrote:

> [Linda]No, I don’t believe that service chaining effort is about chaining Layer2/3 links & nodes across network.  That is why I sent several emails on the other email threads to advocate the necessity of differentiating the “Services” in the context of NSC from typical Layer2/3 services.
> However, some people on the other thread stated that Layer 2/3 nodes chaining shouldn’t be excluded.
>  
> I simply want to point out that the current scope doesn’t have clear definition about “services”.  Therefore, the current scope doesn’t preclude chaining Layer 2/3 nodes based on control plane policy. (I am not saying that I want to do so).
>  
>  
> Linda
>  
>  
> From: Linda Dunbar <[email-masked]>
> To: Microsoft Office User <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Sep 2013 14:44:54 -0400

From where I sit, I think that vague may well be good.
For example, I think that there are ways to use MPLS labels or VLAN tags 
as part of the process of directing packets through service chains.  If 
we agreed on such an approach, that would be part of what we would 
describe.  (Heck, I've seen some strange things.  Maybe an IP address 
can identify a chain?)

That does leda to questions of how can we define "one".  I am concerned 
that if we do not at least aim for a single answer, it will be very 
difficult to get interoperation.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Sep 2013 18:52:26 +0000

Thanks for your patience, Jim!

Does your description pre-suppose that there is always another IP header applied?   For example, an original TCP segment could look like this (assuming UDP-based encap for this example):

	Outer-ip/udp/nsc/inner-ip/tcp/payload

I can definitely get my head around that as it is a universal solution that presumes an IP network, only.

I may be misinterpreting but I suspect that some on this thread aren't on the same page (at least yet) and may be thinking that in certain network topologies the outer IP can/should be avoided.     If that is the case, I can't see how the nsc information can be inserted after the transport, which would create something that looks like this:

	Ip/tcp/nsc/payload

Thanks.

    Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Thursday, September 05, 2013 1:49 PM
To: Ron Parker; Melinda Shore; [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Ron,

By encapsulation we mean something inserted between the transport encapsulation and the original packet payload. There are two things that need to happen; (1) identify that "service chaining" information follows the transport header, and (2) encapsulate the actual service chaining information. Now you could go down the path of trying to force fit the service chaining information into the transport but that imho is a mistake we should avoid.

On 9/5/13 1:44 PM, "Ron Parker" <[email-masked]> wrote:

>if I think about something that resembles GRE, when we say 
>encapsulation, we are meaning the part of GRE that has the key but not the part of GRE

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 5 Sep 2013 19:03:46 +0000

Just to add, for clarity(hopefully).

This is the intent: [Transport-Encapsulation/Header |
Service-Encapsulaiton/Header | Original-payload]
Where,
Original-payload        : an IP packet without the layer-2 header or it
could be a frame with the L2-header. This depends on the interception
layer.
Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN, UDP/UDP-lite, Š
Service Encap           : is where the service-path-identifier/... Is
carried in order to be able to identify the chain or the forwarding path.

Surendra.

On 9/5/13 11:52 AM, "Ron Parker" <[email-masked]> wrote:

>Does your description pre-suppose that there is always another IP header
>applied?   For example, an original TCP segment could look like this
>(assuming UDP-based encap for this example):
>
>I may be misinterpreting but I suspect that some on this thread aren't on
>the same page (at least yet) and may be thinking that in certain network
>topologies the outer IP can/should be avoided.     If that is the case, I
>can't see how the nsc information can be inserted after the transport,
>which would create something that looks like this:
>
>	Ip/tcp/nsc/payload
>
>Thanks.
>
>    Ron
>
>
>service chaining information into the transport but that imho is a
>mistake we should avoid.
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 19:11:42 +0000

Yes, this is what I have in mind exactly. Ron, let me know if this does
not make sense.

---

From: "Joachimpillai, Damascene M" <[email-masked]>
Date: Thu, 5 Sep 2013 15:17:44 -0400

Isnt all of these lead to carrying Metadata from application to application?

-- DJ

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, September 05, 2013 3:12 PM
To: Surendra Kumar (smkumar); Ron Parker; Melinda Shore; [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Yes, this is what I have in mind exactly. Ron, let me know if this does not make sense.

On 9/5/13 3:03 PM, "Surendra Kumar (smkumar)" <[email-masked]> wrote:

>Service-Encapsulaiton/Header | Original-payload] Where,
>>I may be misinterpreting but I suspect that some on this thread aren't 
>>on the same page (at least yet) and may be thinking that in certain network
>>encapsulation and the original packet payload. There are two things 
>>that need to happen; (1) identify that "service chaining" information 
>>follows the transport header, and (2) encapsulate the actual service 
>>chaining information. Now you could go down the path of trying to 
>>force fit the service chaining information into the transport but that 
>>imho is a mistake we should avoid.
>>
>>>> This version hasn't addressed the comments on Bullet 3 of requiring 
>>>> a single encapsulation being too limiting or may not even be realistic.
>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 19:22:17 +0000

That is certainly one possibility (although not required for all services)
and the data plane should enable that functionality yes.

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Sep 2013 19:22:29 +0000

Yes, that makes sense.   I think I was stuck on "transport" as "layer 4".   The term is used more broadly, here.   So when we say a single encapsulation, we are really saying a single service-encapsulation/header and we are not saying a single complete transformation of the original IP packet, as that would be dependent on the choice of "transport".

Thanks, all.

   Ron

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 19:25:14 +0000

Yes exactly. The point being the service encapsulation should be
*independent* of the transport so that we don't get into the game of
trying to retrofit all possible transport encapsulations.

On 9/5/13 3:22 PM, "Ron Parker" <[email-masked]> wrote:

>Yes, that makes sense.   I think I was stuck on "transport" as "layer 4".
>  The term is used more broadly, here.   So when we say a single
>encapsulation, we are really saying a single service-encapsulation/header
>and we are not saying a single complete transformation of the original IP
>packet, as that would be dependent on the choice of "transport".
>
>Thanks, all.
>
>   Ron
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Sep 2013 15:29:59 -0400

We are getting into details of the archtiecture which I would like to 
debate once we have a charter.

But just to put  stake in the ground, it seems to me that we want to at 
least enable the transport-encaps to carry service-chain forwarding 
information, particularly so that we can use existing forwarding 
hardware whenever possible.

Yes, we can assume architecturally that the IP / Ethernet headers merely 
identify the next hop in the chain and chain identification is always 
encapsulated.  But it seems at least premature to make that assumption.

Yours,
Joel

PS: Note, I do understand that we need to carry other information in the 
packet to assist in the service / chaining.  For example, I have 
applications where I need to retain subscriber identity as metadata.

---

From: "Joachimpillai, Damascene M" <[email-masked]>
Date: Thu, 5 Sep 2013 15:31:38 -0400

So what is the encapsulation carrying?

-- DJ

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Thursday, September 05, 2013 3:22 PM
To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron Parker; Melinda Shore; [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

That is certainly one possibility (although not required for all services) and the data plane should enable that functionality yes.

On 9/5/13 3:17 PM, "Joachimpillai, Damascene M"
<[email-masked]> wrote:

>>>I can definitely get my head around that as it is a universal 
>>>solution that presumes an IP network, only.
>>>
>>>I may be misinterpreting but I suspect that some on this thread 
>>>aren't on the same page (at least yet) and may be thinking that in 
>>>certain network
>>>can't see how the nsc information can be inserted after the 
>>>transport, which would create something that looks like this:
>>>
>>>	Ip/tcp/nsc/payload
>>>
>>>Thanks.
>>>
>>>    Ron
>>>
>>>
>>>force fit the service chaining information into the transport but 
>>>that imho is a mistake we should avoid.
>>>
>>>>the thing that carries information like chain id, hop index, and 
>>>>possibly metadata about the flow, but excludes the "overlay" 
>>>>encapsulation.
>>>>So
>>>>> This version hasn't addressed the comments on Bullet 3 of 
>>>>>requiring  a single encapsulation being too limiting or may not 
>>>>>even be realistic.
>>>>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Sep 2013 11:31:49 -0800

> carried in order to be able to identify the chain or the forwarding path.

I think this is quite helpful, actually.  I think some of the
discussion of layering, or at least some of the discussion of
layering, has been a little too fuzzy.  The IP stack does not
break down that cleanly into OSI layers and so when someone says
"Layer 4" it's not always clear what they mean.  Bringing
specificity to the discussion is extremely useful.

Melinda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 19:35:49 +0000

That's something that we would debate within the WG and as Joel said it is
perhaps premature to be discussing it now. However, to answer your
question, in the absence of metadata the minimum would be to carry a
service path identifier (that is used to identify a given service chain)
and I would argue an index into the service chain (so that a receiving
network node is able to identify which of the service functions within the
service chain it should apply). An example of what I am thinking is given
in draft-quinn-nsh.

On 9/5/13 3:31 PM, "Joachimpillai, Damascene M"
<[email-masked]> wrote:

>That is certainly one possibility (although not required for all
>services) and the data plane should enable that functionality yes.
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Sep 2013 20:18:35 +0000

Hi Jerome,

I have updated 3) as follows:

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

Does this reflect your view accurately?

From: Jerome Moisand <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 5, 2013 2:14 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nsc] NSC Working Group Charter Proposal

==>

Greetings,

Proposed Milestones:

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 5 Sep 2013 20:38:40 +0000

Perfect. Thank you.

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Thursday, September 05, 2013 4:19 PM
To: Jerome Moisand; [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jerome,

==>

Greetings,

Proposed Milestones:

---

From: Ken Gray <[email-masked]>
Date: Thu, 5 Sep 2013 20:39:24 +0000

It gets clearer when we get beyond the charter and into the piecework.
For example, Paul's NSH doc makes this part pretty clear.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 5 Sep 2013 20:59:30 +0000

Ken,

I agree with that and (in IMHO) this simple, conceptual statement was missing from the use case discussions in Berlin - so I can see where there is some confusion among people who have not read the piecework yet.

-Darrel

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 5 Sep 2013 21:19:03 +0000

I can see the need for this "NSC" header inserted to the packets, and occasionally needing an "outer-ip" encapsulation to by-pass nodes that can't parse the "NSC" header. 

Can someone explain why it is necessary to always have the "outer-ip" header? 

Linda

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Sep 2013 23:16:18 +0000

Hi, Linda.

As it was recently explained on this thread, I don't think it needs to be necessary to always have it if we are willing to allow multiple overall "transport"+service encapsulations.   For example:  

/enet/ip/udp/nsc/ip/tcp/...
/enet/ip/gre/nsc/ip/tcp/...
/enet/llc-snap/nsc/ip/tcp/...
/enet/mpls/nsc/ip/tcp/...

As much as I don't think we'll end up there, I do find a single overall universal transformation very attractive and any flavor that is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet or different subnet, l2 switches and/or l3 routers in between , OpenFlow or not OpenFlow, MPLS or not MPLS, ...     The argument against this will be that the packets are bigger than they need to be for some network topologies/protocols.   Simplicity or efficiency?

   Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Thursday, September 05, 2013 5:19 PM
To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; [email-masked]
Subject: RE: [nsc] NSC Working Group Charter Proposal

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Sep 2013 14:17:24 +0000

Ron, 

Great!  I am glad to see that we go down this path. 
We should also allow: /enet/ip/udp or tcp/nsc/...
i.e. not necessarily having an inner IP. 

Linda

> Sent: Thursday, September 05, 2013 6:16 PM
> To: Linda Dunbar; Jim Guichard (jguichar); Melinda Shore; [email-masked]
> As it was recently explained on this thread, I don't think it needs to
> be necessary to always have it if we are willing to allow multiple
> overall "transport"+service encapsulations.   For example:
> 
> As much as I don't think we'll end up there, I do find a single overall
> universal transformation very attractive and any flavor that is
> /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet or
> different subnet, l2 switches and/or l3 routers in between , OpenFlow
> or not OpenFlow, MPLS or not MPLS, ...     The argument against this
> will be that the packets are bigger than they need to be for some
> network topologies/protocols.   Simplicity or efficiency?
> 
>    Ron
> 
> 
> 
> I can see the need for this "NSC" header inserted to the packets, and
> occasionally needing an "outer-ip" encapsulation to by-pass nodes that
> can't parse the "NSC" header.
>

---

From: Ron Parker <[email-masked]>
Date: Fri, 6 Sep 2013 14:38:14 +0000

Hi, Linda, 

When I referenced an inner IP, I more properly should have referenced "original packet", which I think you are pointing out, correctly, is not necessarily IP.    Even in this case, I think it is important to state whether a new "transport" is always required in front of the "original packet" or not. 

So if we exemplify this with a layer 2 "transport" and a layer 2 original packet, we might have something like:

	/encaps-enet/llc-snap/nsc-header/original-enet/payload

If we take another example of a layer 2/3/4 "transport" and a layer 2 original packet, we might have something like:

	/encaps-enet/ip/udp/nsc-header/original-enet/payload

The reason I am being pedantic here is that these approaches contrast to other possible solutions where an outer "transport" is not added.   For example, if we were entertaining mapping the nsc-header to a new IPv4 option and new IPv6 extension header for use only when the "original packet" is an IPv4 or IPv6 packet, then an encapsulating "transport" would not necessarily be required.   Again, we come to simplicity/universality vs. efficiency (at least in terms of packet size if not necessarily processing requirements).

This is obviously an important area to cover in the WG.   Some of this analysis is presented in draft-boucadair-chaining-design-analysis and we intend to add more of this pros/cons analysis wrt the overall encapsulation issue in an upcoming revision.

I would like to take the opportunity to back previous suggestions that a design choices analysis document become a part of the WG chartered deliverables as it encourages a more open and transparent process and ultimately provides a better record of how the eventual recommendations are arrived at.

   Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Friday, September 06, 2013 10:17 AM
To: Ron Parker; Jim Guichard (jguichar); Melinda Shore; [email-masked]
Subject: RE: [nsc] NSC Working Group Charter Proposal

Ron, 

Linda

> As much as I don't think we'll end up there, I do find a single 
> overall universal transformation very attractive and any flavor that 
> is /{l2}/ip/xxx/ip/tcp would be universally applicable -- same subnet 
> or different subnet, l2 switches and/or l3 routers in between , OpenFlow

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Sep 2013 15:23:27 +0000

Lucy,

To add to this, and commenting only for completeness for the record, you say "The bof in IETF87 does not convey the issues clearly."

However, the sponsoring AD's summary said the contrary:
I believe that the BoF delivered what the IESG had hoped to see. That is, it
allowed a number of network operators from a broad spectrum of network types to
describe the problem space that they are interested in.
Certainly a small number of use cases to complete and exemplify the problem statement are appropriate and useful. That said, there is no strict sequentiality implied in having to finish a laundry list of use cases to start working on a solution.

Thanks,

-- Carlos.

On Sep 4, 2013, at 6:38 PM, Ken Gray <[email-masked]> wrote:

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Sep 2013 15:25:37 +0000

Hi, Linda,

I have to admit that I am a bit lost with this comment or a couple of previous ones. Consequently, I wanted to send a (hopefully) clarifying summary.

The goal is to send a packet (original-payload from a service perspective) with added service context to a service node. This is a two-step approach: we can call the steps 1. service (inner), 2. transport.

A service chain defines a set of services applied to an original payload. To provide chain context, service path id, classification info, etc., a service-level encapsulation/header is added. This should be encapsulating-layer (transport-layer) agnostic. Second, in order get that to a service node, it gets further encapsulated (in IP, IP/GRE, IP/UDP, VXLAN, MPLS, etc) for delivery.

Being a graphical person, I also really like what Surendra shared at http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html

HTH,

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Sep 2013 15:28:15 +0000

> There's no agreement that that's the case.

I disagree that aiming for a single service-level encap is too limiting. Much on the contrary, I think it should be a clear explicit goal if we are to aim for interoperability.

I think the most recent version sent by Jim is good:

--->8---
--->8---

-- Carlos.

---

From: Ken Gray <[email-masked]>
Date: Fri, 6 Sep 2013 15:32:24 +0000

Hey, Ron.

I tend to agree with the charter proposal as is.  Those four documents
should be more than adequate.

The design/analysis document could be used as a strawman for the
discussion of the decisions imbedded in the ultimate architecture
document, but doesn't have to have a life of it's own ...those discussions
can/would typically be archived in the WG mailer (THIS mailer) for anyone
who would want to catch up on the discussion, IMO.

(I had to capitalize the THIS because I also don't believe we need more
than THIS list to discuss WG business. This has nothing to do with Ron,
btw, I'm editorializing.)

On 9/6/13 10:38 AM, "Ron Parker" <[email-masked]> wrote:

>Hi, Linda, 
>
>When I referenced an inner IP, I more properly should have referenced
>"original packet", which I think you are pointing out, correctly, is not
>necessarily IP.    Even in this case, I think it is important to state
>whether a new "transport" is always required in front of the "original
>packet" or not. 
>
>If we take another example of a layer 2/3/4 "transport" and a layer 2
>original packet, we might have something like:
>
>The reason I am being pedantic here is that these approaches contrast to
>other possible solutions where an outer "transport" is not added.   For
>example, if we were entertaining mapping the nsc-header to a new IPv4
>option and new IPv6 extension header for use only when the "original
>packet" is an IPv4 or IPv6 packet, then an encapsulating "transport"
>would not necessarily be required.   Again, we come to
>simplicity/universality vs. efficiency (at least in terms of packet size
>if not necessarily processing requirements).
>
>This is obviously an important area to cover in the WG.   Some of this
>analysis is presented in draft-boucadair-chaining-design-analysis and we
>intend to add more of this pros/cons analysis wrt the overall
>encapsulation issue in an upcoming revision.
>
>I would like to take the opportunity to back previous suggestions that a
>design choices analysis document become a part of the WG chartered
>deliverables as it encourages a more open and transparent process and
>ultimately provides a better record of how the eventual recommendations
>are arrived at.
>
>   Ron
>
>	
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Sep 2013 15:36:33 +0000

Carlos, 

I agree that you have to use Outer Transport Layer to pass information among Service Nodes. 

However, I think that we need to acknowledge that many of today's Service Nodes, e.g. FW, LB, etc, especially the ones that are one link away from Forwarding nodes, don't even use any addresses. If the Forwarding nodes have the needed traffic clarification means, they can direct the selective traffic that need the "Service" to the service nodes.

It is not "one size" fits all for all Service nodes. 

Linda  

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Carlos Pignataro (cpignata)
> Sent: Friday, September 06, 2013 10:26 AM
> To: Linda Dunbar
> Cc: [email-masked]; Jim Guichard (jguichar); Melinda Shore; Ron Parker
> I have to admit that I am a bit lost with this comment or a couple of
> previous ones. Consequently, I wanted to send a (hopefully) clarifying
> summary.
> 
> The goal is to send a packet (original-payload from a service
> perspective) with added service context to a service node. This is a
> two-step approach: we can call the steps 1. service (inner), 2.
> transport.
> 
> A service chain defines a set of services applied to an original
> payload. To provide chain context, service path id, classification info,
> etc., a service-level encapsulation/header is added. This should be
> encapsulating-layer (transport-layer) agnostic. Second, in order get
> that to a service node, it gets further encapsulated (in IP, IP/GRE,
> IP/UDP, VXLAN, MPLS, etc) for delivery.
> 
> Being a graphical person, I also really like what Surendra shared at
> http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html
> 
> HTH,
> 
> -- Carlos.
> 
> >> As it was recently explained on this thread, I don't think it needs
> >> to be necessary to always have it if we are willing to allow
> multiple
> >> occasionally needing an "outer-ip" encapsulation to by-pass nodes
> >> that can't parse the "NSC" header.
> >>
> >> Can someone explain why it is necessary to always have the "outer-
> ip"
> >> header?
> >>
> >>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 6 Sep 2013 15:42:56 +0000

Linda,

I don¹t think anyone is saying that you use outer transport layer for
passing information among service nodes; to the contrary, the outer
transport layer is simply used to get packets from point A to point B and
*nothing* more. If point B happens to be a service node that is acting on
behalf of an attached service function then point B may use the
service-encapsulation to figure out how to forward the packet to the right
service function.  

On 9/6/13 11:36 AM, "Linda Dunbar" <[email-masked]> wrote:

>However, I think that we need to acknowledge that many of today's Service
>Nodes, e.g. FW, LB, etc, especially the ones that are one link away from
>Forwarding nodes, don't even use any addresses. If the Forwarding nodes
>have the needed traffic clarification means, they can direct the
>selective traffic that need the "Service" to the service nodes.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Sep 2013 15:46:24 +0000

Linda,

What Jim said.

-- Carlos.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Sep 2013 15:54:31 +0000

Jim, 

What if "A" and "B" in your example are today's existing nodes, (they are not aware of NSC header) and the traffic between "A" and "B" needs a sequence of service functions?

Some service functions are one link away from forwarding nodes (or co-located), which may not require another layer of encapsulation. But some service functions are accessible via multiple nodes, then there is need for another layer encapsulation. 

Linda

> Jim Guichard (jguichar)
> Sent: Friday, September 06, 2013 10:43 AM
> To: Linda Dunbar; Carlos Pignataro (cpignata)
> Cc: [email-masked]; Melinda Shore; Ron Parker

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 6 Sep 2013 15:56:57 +0000

Then use routing.

On 9/6/13 11:54 AM, "Linda Dunbar" <[email-masked]> wrote:

>Jim, 
>
>What if "A" and "B" in your example are today's existing nodes, (they are
>not aware of NSC header) and the traffic between "A" and "B" needs a
>sequence of service functions?
>
>Some service functions are one link away from forwarding nodes (or
>co-located), which may not require another layer of encapsulation. But
>some service functions are accessible via multiple nodes, then there is
>need for another layer encapsulation.
>
>Linda
>
>

---

From: Jerome Moisand <[email-masked]>
Date: Fri, 6 Sep 2013 16:00:54 +0000

Guys, could we please keep this discussion for later? We're supposed to discuss a charter here. Not a specific solution. 

Fair enough?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 06, 2013 11:57 AM
To: Linda Dunbar; Carlos Pignataro (cpignata)
Cc: [email-masked]; Melinda Shore; Ron Parker
Subject: Re: [nsc] NSC Working Group Charter Proposal

Then use routing.

On 9/6/13 11:54 AM, "Linda Dunbar" <[email-masked]> wrote:

>Jim,
>
>What if "A" and "B" in your example are today's existing nodes, (they 
>are not aware of NSC header) and the traffic between "A" and "B" needs 
>a sequence of service functions?
>
>> *nothing* more. If point B happens to be a service node that is 
>> acting on behalf of an attached service function then point B may use 
>> the service-encapsulation to figure out how to forward the packet to 
>> the right service function.
>> 
>> >> perspective) with added service context to a service node. This is 
>> >> a two-step approach: we can call the steps 1. service (inner), 2.
>> >> transport.
>> >>
>> >> etc., a service-level encapsulation/header is added. This should 
>> >> be encapsulating-layer (transport-layer) agnostic. Second, in 
>> >> order get that to a service node, it gets further encapsulated (in 
>> >> IP, IP/GRE, IP/UDP, VXLAN, MPLS, etc) for delivery.
>> >>
>> >> Being a graphical person, I also really like what Surendra shared 
>> >> at http://www.ietf.org/mail-archive/web/nsc/current/msg00312.html
>> >>
>> >> HTH,
>> >>
>> >> -- Carlos.
>> >>
>> >> >> I can see the need for this "NSC" header inserted to the 
>> >> >> packets,
>> >> and
>> >> >> occasionally needing an "outer-ip" encapsulation to by-pass 
>> >> >> nodes that can't parse the "NSC" header.
>> >> >>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 6 Sep 2013 16:03:37 +0000

Zip ;-)

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

>Guys, could we please keep this discussion for later? We're supposed to
>discuss a charter here. Not a specific solution.
>
>Fair enough?
>

---

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

On 9/6/13 8:54 AM, "Linda Dunbar" <[email-masked]> wrote:

>co-located), which may not require another layer of encapsulation.
SK> Is true only in physical environments not in virtual or hybrid.

Surendra.
>But some service functions are accessible via multiple nodes, then there
>is need for another layer encapsulation.
>
>Linda
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Sep 2013 16:21:10 +0000

The discussion is about using "A Single Encapsulation.." in the Charter. 

Even though it is ideal and everyone (myself included) loves it, but I am afraid that not every Service Chain case will need outer encapsulation. 

Linda
> Jerome Moisand
> Sent: Friday, September 06, 2013 11:01 AM
> To: [email-masked]
> >> transport layer is simply used to get packets from point A to point
> B
> >> and
> >> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >> >> I have to admit that I am a bit lost with this comment or a
> couple
> >> of
> >> >> payload. To provide chain context, service path id,
> classification
> >> info,
> >> >> >> overall universal transformation very attractive and any
> flavor
> >> that
> >> >> >> or not OpenFlow, MPLS or not MPLS, ...     The argument
> against
> >> this

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Sep 2013 12:29:25 -0400

I am somewhat confused between the musts and the mays.
I do think that there are circumstances where the outer ("transport" 
header can carry and use with existing forwarding information that 
identifies / directs the service chaining.
I equally agree that we don't need to mandate that.
And I have little problem duplicating any such information in a 
consistent a reusable intermediate encapsulation header so that it can 
be handled in other ways.

Yours,
Joel

---

From: Ken Gray <[email-masked]>
Date: Fri, 6 Sep 2013 16:29:22 +0000

+1 

There are documents extant on the other topics and a time will come to
comment on them.  Let's do the darn charter first.  We're polluting the
subject line.

Linda, the sentence is "A single encapsulation will be selected in order
to enable interoperability of data plane components."  It has ALREADY been
noted that various components of an overall encapsulation will or won't be
used as appropriate.  For an abstract statement, I don't think Jim can get
more vague.

More charter comments, anyone?

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 6 Sep 2013 16:30:47 +0000

Jim, et al.,

Service chaining solutions are currently being deployed without carrying, so called, metadata.
I believe the proposal for carrying the metadata should cover the interoperability with the existing service chaining infrastructures.

Maria

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 05, 2013 10:51 AM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jim,

Cheers,
Med

De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mercredi 4 septembre 2013 19:37
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : Re: NSC Working Group Charter Proposal

Hi Med,

Comment inline ..

Hi Jim,

Cheers,
Med

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Sep 2013 16:31:27 +0000

Linda,

Several dozen emails ago, Jim sent the following -- what is your take?

--->8---

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

Thanks,

-- Carlos.

On 9/6/13 12:21 PM, "Linda Dunbar" <[email-masked]> wrote:

>Even though it is ideal and everyone (myself included) loves it, but I am
>afraid that not every Service Chain case will need outer encapsulation.
>
>
>Linda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 6 Sep 2013 16:38:37 +0000

Hi Joel,

Both are valid and I believe item 3) in the charter is written in such a
way as to put both in-scope.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Sep 2013 16:50:36 +0000

If the second sentence can be modified a little, (suggested below), then it would be easier for new solutions to interoperate with today's service chain:

A service-level header or a header field inserted into existing transport header will be specified in order to enable interoperability of data plane components over existing networks (e.g., IP, MPLS, or others).

Linda

> Sent: Friday, September 06, 2013 11:31 AM
> To: Linda Dunbar; Jerome Moisand; [email-masked]
> But
> >> >some service functions are accessible via multiple nodes, then
> there
> >> is
> >> >> >However, I think that we need to acknowledge that many of
> today's
> >> >> Service
> >> >> >Nodes, e.g. FW, LB, etc, especially the ones that are one link
> away
> >> >> from
> >> >> >Forwarding nodes, don't even use any addresses. If the
> Forwarding
> >> >> nodes
> >> >> >> perspective) with added service context to a service node.
> This
> >> is
> >> >> >> >> As it was recently explained on this thread, I don't think
> it
> >> >> needs
> >> >> >> >> is /{l2}/ip/xxx/ip/tcp would be universally applicable --
> same
> >> >> >> subnet
> >> >> >> >> or different subnet, l2 switches and/or l3 routers in
> between ,
> >> >> >> OpenFlow
> >> >> >> >> will be that the packets are bigger than they need to be
> for
> >> some

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 6 Sep 2013 16:55:59 +0000

Service chain identifier is not absolutely necessary. Such information can be implicit in the chain.
Hence, carrying or not such an identifier should be made a matter of choice.

Maria

> Sent: Thursday, September 05, 2013 3:36 PM
> >>>>topologies the outer IP can/should be avoided.     If that is the
> case,
> >>>>I
> >>>>>I apologize if I'm being thick on this, but I'm still having
> trouble
> >>>>>with
> >>>>>the meaning of "encapsulation" here.   It has been pointed out
> that it
> >>>>>is

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Sep 2013 17:06:27 +0000

Agree strongly of Maria's statement. 

The existing identifiers, like MPSL tag, etc., can also be used to identify Service Chain for cases of service functions that don't need to pass information among them or to the forwarding nodes. 

Linda

> NAPIERALA, MARIA H
> Sent: Friday, September 06, 2013 11:56 AM
> To: Jim Guichard (jguichar); Joachimpillai, Damascene M; Surendra Kumar
> (smkumar); Ron Parker; Melinda Shore; [email-masked]
> > That's something that we would debate within the WG and as Joel said
> it
> > is
> > network node is able to identify which of the service functions
> within
> > the
> > >>>Original-payload        : an IP packet without the layer-2 header
> or
> > it
> > >>>carried in order to be able to identify the chain or the
> forwarding
> > >>>path.
> > >>>
> > >>>Surendra.
> > >>>
> > >>>>>encapsulation, we are meaning the part of GRE that has the key
> but
> > >>>>>not the part of GRE
> > >>>>>that adds another IP header.    Where I really get twisted
> around
> > the
> > >>>>>Of Melinda Shore

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Sep 2013 09:18:53 -0800

On 9/6/13 9:06 AM, Linda Dunbar wrote:
> The existing identifiers, like MPSL tag, etc., can also be used to
> identify Service Chain for cases of service functions that don't need
> to pass information among them or to the forwarding nodes.

In the IETF we often talk about complexity being one of
the primary sources of various kinds of protocol problems -
interoperability problems, security problems, implementation
difficulty, the need to profile, etc.  Providing options
that are not *required* to solve the problem at hand is one
obvious source of complexity.

Melinda

---

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

The current wording of the first sentence of work item 3) is imo adequate
to address this. 

On 9/6/13 12:50 PM, "Linda Dunbar" <[email-masked]> wrote:

>If the second sentence can be modified a little, (suggested below), then
>it would be easier for new solutions to interoperate with today's service
>chain:
>
>
>A service-level header or a header field inserted into existing transport
>header will be specified in order to enable interoperability of data
>plane components over existing networks (e.g., IP, MPLS, or others).
>
>
>Linda
>
>

---

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

Maria,

That's fine and as far as I can tell nothing in the charter prevents this.

From: <NAPIERALA>, MARIA H <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 6, 2013 12:30 PM
To: "[email-masked]<mailto:[email-masked]>" <[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 Working Group Charter Proposal

Jim, et al.,

Maria

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, September 05, 2013 10:51 AM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] NSC Working Group Charter Proposal

Hi Jim,

I have nothing against the word “metadata” itself.
You can maintain it if you prefer, but it seems odd to call only that technical aspect for that milestone.

Cheers,
Med

Hi Med,

Comment inline ..

Hi Jim,

Cheers,
Med

De :[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mardi 3 septembre 2013 18:01
À : [email-masked]<mailto:[email-masked]>
Objet : [nsc] NSC Working Group Charter Proposal

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

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

Everyone,

As requested by several other folks, may I respectfully ask that this
discussion be shelved for a later time so that we can focus simply on the
charter. Debating the pros and cons of encapsulations, while interesting,
is not helpful to moving our discussion of the charter forward. From a
charter perspective I believe the current wording does not prevent
anyone's favorite encapsulation solution and therefore once our WG is up
and running they are free and welcome to write and submit I-D's to the WG
for consideration. 

On 9/6/13 1:06 PM, "Linda Dunbar" <[email-masked]> wrote:

>identify Service Chain for cases of service functions that don't need to
>pass information among them or to the forwarding nodes.
>
>Linda
>

---

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

Good.
Let me make it a little more precise, namely, that adding the metadata should not necessarily require changing a deployed service chain infrastructure.

Thanks.

Maria

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Friday, September 06, 2013 1:21 PM
To: NAPIERALA, MARIA H; [email-masked]; [email-masked]
Subject: Re: NSC Working Group Charter Proposal

Maria,

Jim, et al.,

Maria

Hi Jim,

Cheers,
Med

Hi Med,

Comment inline ..

Hi Jim,

Cheers,
Med

Greetings,

Proposed NSC WG Charter

Proposed Milestones:

---

From: Ken Gray <[email-masked]>
Date: Fri, 6 Sep 2013 17:34:13 +0000

+1

On 9/6/13 1:26 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>>> > >To: Joachimpillai, Damascene M; Surendra Kumar (smkumar); Ron
>>>Parker;
>>> > >Melinda Shore; [email-masked]
>>> > >>>Transport Encap examples: LLC/SNAP, GRE/NVGRE, VXLAN,
>>>UDP/UDP-lite,
>>> > Š

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 6 Sep 2013 16:35:55 -0400

I agree. This is the same model that was chosen for PWs.  In fact, there is ample evidence around NOT meddling with the packets as they are inside the "NFV tunnel" that can be gathered from other "tunneling" efforts past and present at the IETF.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 6 Sep 2013 16:36:30 -0400

Oui!

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 10:32:56 +0200

Hi Ken,

I still think there is a value to include an explicit charter item for the design choice analysis document, at least for the following reasons:

* The mailing list archives can be used to retrieve some of the justifications for some design choices, but the result is not guaranteed, the data is not structured, etc. 

* There are even some WGs that do not publish the meeting minutes...and for those WGs it is hard to find when and why a design choice was made. 

* IESG review may sometimes conflict with the WG consensus. Authors are invited to engage in discussions to explain the motivations and provide justification for the choices recorded in the draft. For the context of the nsc effort, I do think that energy (time to resolve concerns) can be optimized if a formal tool was provided by the working group: (1) simple specification document + (2) a companion document that motivates the design choices and the candidates solutions that were considered. 

* Given the aggressive proposed milestones for nsc, we need the work to be focused so as to be able to produce the expected deliverables while being open to any proposal that can put on the table. 

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de Ken
>Gray
>Envoyé : vendredi 6 septembre 2013 17:32
>À : Ron Parker; Linda Dunbar; Jim Guichard (jguichar); Melinda Shore;
>[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Sep 2013 05:13:53 -0400

I agree that capturing architecture / design rationale is very useful.
I don't want it in a separate from the architecture / design that it is 
supporting.

Also, we should be careful not to get to wrapped up in getting the 
perfect explanation of the decisions.  We need good explanations, not 
perfect ones with all the nuances.

Yours,
Joel

On 9/9/13 4:32 AM, [email-masked] wrote:
> Hi Ken,
>
> I still think there is a value to include an explicit charter item
> for the design choice analysis document, at least for the following
> reasons:
>
> * The mailing list archives can be used to retrieve some of the
> justifications for some design choices, but the result is not
> guaranteed, the data is not structured, etc.
>
> * There are even some WGs that do not publish the meeting
> minutes...and for those WGs it is hard to find when and why a design
> choice was made.
>
> * IESG review may sometimes conflict with the WG consensus. Authors
> are invited to engage in discussions to explain the motivations and
> provide justification for the choices recorded in the draft. For the
> context of the nsc effort, I do think that energy (time to resolve
> concerns) can be optimized if a formal tool was provided by the
> working group: (1) simple specification document + (2) a companion
> document that motivates the design choices and the candidates
> solutions that were considered.
>
> * Given the aggressive proposed milestones for nsc, we need the work
> to be focused so as to be able to produce the expected deliverables
> while being open to any proposal that can put on the table.
>
> Cheers, Med
>
>> -----Message d'origine----- De : [email-masked]
>> [mailto:[email-masked]] De la part de Ken Gray Envoyé :
>> vendredi 6 septembre 2013 17:32 À : Ron Parker; Linda Dunbar; Jim
>> Guichard (jguichar); Melinda Shore; [email-masked] Objet : Re: [nsc]
>> NSC Working Group Charter Proposal
>>
>> Hey, Ron.
>>
>> I tend to agree with the charter proposal as is.  Those four
>> documents should be more than adequate.
>>
>> document, but doesn't have to have a life of it's own ...those
>> discussions can/would typically be archived in the WG mailer (THIS
>> mailer) for anyone who would want to catch up on the discussion,
>> IMO.
>>
>> (I had to capitalize the THIS because I also don't believe we need
>> more than THIS list to discuss WG business. This has nothing to do
>> with Ron, btw, I'm editorializing.)
>>
>>
>>> When I referenced an inner IP, I more properly should have
>>> referenced "original packet", which I think you are pointing out,
>>> correctly, is not necessarily IP.    Even in this case, I think
>>> it is important to state whether a new "transport" is always
>>> required in front of the "original packet" or not.
>>>
>>> So if we exemplify this with a layer 2 "transport" and a layer 2
>>> If we take another example of a layer 2/3/4 "transport" and a
>>> layer 2 original packet, we might have something like:
>>>
>>> The reason I am being pedantic here is that these approaches
>>> contrast to other possible solutions where an outer "transport"
>>> is not added.   For example, if we were entertaining mapping the
>>> nsc-header to a new IPv4 option and new IPv6 extension header for
>>> use only when the "original packet" is an IPv4 or IPv6 packet,
>>> then an encapsulating "transport" would not necessarily be
>>> required.   Again, we come to simplicity/universality vs.
>>> efficiency (at least in terms of packet size if not necessarily
>>> processing requirements).
>>>
>>> This is obviously an important area to cover in the WG.   Some of
>>> this analysis is presented in
>>> draft-boucadair-chaining-design-analysis and we intend to add
>>> more of this pros/cons analysis wrt the overall encapsulation
>>> issue in an upcoming revision.
>>>
>>> I would like to take the opportunity to back previous suggestions
>>> that a design choices analysis document become a part of the WG
>>> chartered deliverables as it encourages a more open and
>>> transparent process and ultimately provides a better record of
>>> how the eventual recommendations are arrived at.
>>>
>>> Ron
>>>
>>>
>>>
>>> -----Original Message----- From: Linda Dunbar
>>> [mailto:[email-masked]] Sent: Friday, September 06, 2013
>>> 10:17 AM To: Ron Parker; Jim Guichard (jguichar); Melinda Shore;
>>> [email-masked] Subject: RE: [nsc] NSC Working Group Charter
>>> Proposal
>>>
>>> Ron,
>>>
>>> Great!  I am glad to see that we go down this path. We should
>>> also allow: /enet/ip/udp or tcp/nsc/... i.e. not necessarily
>>> having an inner IP.
>>>
>>> Linda
>>>
>>>
>>>> -----Original Message----- From: Ron Parker
>>>> [mailto:[email-masked]] Sent: Thursday,
>>>> September 05, 2013 6:16 PM To: Linda Dunbar; Jim Guichard
>>>> (jguichar); Melinda Shore; [email-masked] Subject: RE: [nsc] NSC
>>>> Working Group Charter Proposal
>>>>
>>>> Hi, Linda.
>>>>
>>>> As it was recently explained on this thread, I don't think it
>>>> needs to be necessary to always have it if we are willing to
>>>> allow multiple overall "transport"+service encapsulations.
>>>> For example:
>>>>
>>>> /enet/ip/udp/nsc/ip/tcp/... /enet/ip/gre/nsc/ip/tcp/...
>>>> /enet/llc-snap/nsc/ip/tcp/... /enet/mpls/nsc/ip/tcp/...
>>>>
>>>> As much as I don't think we'll end up there, I do find a
>>>> single overall universal transformation very attractive and any
>>>> flavor that is /{l2}/ip/xxx/ip/tcp would be universally
>>>> applicable -- same subnet or different subnet, l2 switches
>>>> and/or l3 routers in between , OpenFlow or not OpenFlow, MPLS
>>>> or not MPLS, ...     The argument against this will be that the
>>>> packets are bigger than they need to be for some network
>>>> topologies/protocols.   Simplicity or efficiency?
>>>>
>>>> Ron
>>>>
>>>>
>>>>
>>>> -----Original Message----- From: Linda Dunbar
>>>> [mailto:[email-masked]] Sent: Thursday, September 05,
>>>> 2013 5:19 PM To: Ron Parker; Jim Guichard (jguichar); Melinda
>>>> Shore; [email-masked] Subject: RE: [nsc] NSC Working Group
>>>> Charter Proposal
>>>>
>>>> packets, and occasionally needing an "outer-ip" encapsulation
>>>> to by-pass nodes that can't parse the "NSC" header.
>>>>
>>> _______________________________________________ nsc mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>>>
>>>
>>
>>
>> _______________________________________________ nsc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________ nsc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>

---

From: Ken Gray <[email-masked]>
Date: Mon, 9 Sep 2013 14:44:31 +0000

Med, your arguments FOR doing this seem (to me) to be couched in
correcting the way the IETF generally works within THIS workgroup.

If there are shortcomings in the way we collect discussions/data (e.g. a
need for structured data for research purposes), then they should be
addressed at a higher level than within a single workgroup.  The same can
be said for any perceived historical mismatch between IESG review and
consensus.  

As to meeting notes, again, failures to publish should be noted to the
chairs.

On 9/9/13 4:32 AM, "[email-masked]"
<[email-masked]> wrote:

>Hi Ken,
>
>I still think there is a value to include an explicit charter item for
>the design choice analysis document, at least for the following reasons:
>
>justifications for some design choices, but the result is not guaranteed,
>the data is not structured, etc.
>
>* There are even some WGs that do not publish the meeting minutes...and
>for those WGs it is hard to find when and why a design choice was made.
>
>* IESG review may sometimes conflict with the WG consensus. Authors are
>invited to engage in discussions to explain the motivations and provide
>justification for the choices recorded in the draft. For the context of
>the nsc effort, I do think that energy (time to resolve concerns) can be
>optimized if a formal tool was provided by the working group: (1) simple
>specification document + (2) a companion document that motivates the
>design choices and the candidates solutions that were considered.
>
>* Given the aggressive proposed milestones for nsc, we need the work to
>be focused so as to be able to produce the expected deliverables while
>being open to any proposal that can put on the table.
>
>Cheers,
>Med
>
>>discussions

---

From: "Joachimpillai, Damascene M" <[email-masked]>
Date: Wed, 4 Sep 2013 14:36:33 -0400

-- DJ

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 04, 2013 2:33 PM
To: [email-masked]
Cc: [email-masked]; Jim Guichard (jguichar)
Subject: Re: [nsc] NSC Working Group Charter Proposal

Clipping for focus...

...

Yours,
Joel

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 10 Sep 2013 03:09:00 +0000

If VXLAN header is used as a transport header, does that mean the existing VXLAN header should be modified so as to have a protocol type field in it?

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Surendra
> Kumar (smkumar)
> 发送时间: 2013年9月6日 3:04
> 收件人: Ron Parker; Jim Guichard (jguichar); Melinda Shore; [email-masked]
> 主题: Re: [nsc] NSC Working Group Charter Proposal
> 
> >>Melinda Shore

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 10 Sep 2013 08:17:40 -0400

I'd second that. We shouldn't get caught up in documenting things in unnecessarily heavyweight ways.  If someone wants to write an informational draft that captures this information, that is totally cool - and I'd imagine the WG would encourage it - but an explicit charter item seems like overkill to me. 

	--Tom

On Sep 9, 2013:5:13 AM, at 5:13 AM, "Joel M. Halpern" <[email-masked]> wrote:

> I don't want it in a separate from the architecture / design that it is supporting.
> 
> Also, we should be careful not to get to wrapped up in getting the perfect explanation of the decisions.  We need good explanations, not perfect ones with all the nuances.
> 
> Yours,
> Joel
>