Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

From: "Elzur, Uri" <[email-masked]>
Date: Tue, 17 Sep 2013 11:09:08 +0000

Bullet 3 below suggests "it is intended that the encapsulation be agnostic to the network layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service"
This makes me wonder. I assume the intention of the nsc WG is to provide services to some network nodes that reside in some domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the service at that layer? It seems like the number of cases where a service is centralized or offered across different admin domain than that of the consuming nodes, may be dwarfed by the cases where they co-reside, maybe in the same row, maybe in the same rack or even on the same server. The incentive may be to localize the service close to its consumer to reduce the network burden of carrying traffic unnecessarily over some distance. Virtualization and Virtual appliances may enable such phenomenon.
It seems like a by-product of creating an independent Service layer with full encapsulation (i.e. header with some routing info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways everywhere an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the "service layer" .
The WG can achieve the same goal by defining the structure of the SFC headers to be added and make that format universal across any network layer. i.e. let's suggest some headers containing meta-data and service graph. The same structure can be applied to any network layer, in essence extending its functionality, by the IETF WG that owns that layer, prime candidates will be overlays used in the context of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for those who wish it, but does nothing to restrict the WG to such Service layer ONLY.
while I'd like to refrain judgement which approach is advantageous, I'd expect the WG will at least discuss it. The above text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted? Has the pre-WG participants already determine a separate layer is a MUST?

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: [email-masked]
Subject: [nsc] New NSC WG Charter
Importance: High

Greetings,

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

Proposed Service Function Chaining (SFC) WG Charter

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

---

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

Hi Uri,

Inline ..

From: <Elzur>, Uri <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 17, 2013 7:09 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Bullet 3 below suggests “it is intended that the encapsulation be agnostic to the network layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realised at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service”
This makes me wonder. I assume the intention of the nsc WG is to provide services to some network nodes that reside in some domain e.g. an overlay, or in some (single?) admin domain. Would it not be simpler and more natural to provide the service at that layer? It seems like the number of cases where a service is centralized or offered across different admin domain than that of the consuming nodes, may be dwarfed by the cases where they co-reside, maybe in the same row, maybe in the same rack or even on the same server. The incentive may be to localize the service close to its consumer to reduce the network burden of carrying traffic unnecessarily over some distance. Virtualization and Virtual appliances may enable such phenomenon.
Jim>  it is certainly true that different administrative domains may be present within a particular operators network and indeed those domains may be separately managed and therefore services may need to span multiple domains. However, I am confused by your use of the term "layer". Within the charter when we refer to a layer we mean a layer of the protocol stack and not a layer of the network. We certainly don't mean to imply any form of network boundary or delineation. In addition, nothing in the above prevents the service functions to be co-resident with workloads. It just makes it general enough to address the broad range of deployment scenarios. Given that "migration" is a killer-app of virtualization, service-overlay becomes critical.

It seems like a by-product of creating an independent Service layer with full encapsulation (i.e. header with some routing info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways everywhere an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the “service layer” .
Jim> again I think this may simply be a terminology mismatch. The overlay is simply the transport used to get packets to/from service functions and this overlay may or may not span administrative domains. Gateways may be necessary if translation at the service encapsulation layer is needed between domains. It is worth noting that the initial task of the WG will be to work on single domain use cases only before tackling any inter-domain dependencies.

The WG can achieve the same goal by defining the structure of the SFC headers to be added and make that format universal across any network layer. i.e. let’s suggest some headers containing meta-data and service graph. The same structure can be applied to any network layer, in essence extending its functionality, by the IETF WG that owns that layer, prime candidates will be overlays used in the context of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for those who wish it, but does nothing to restrict the WG to such Service layer ONLY.
Jim> I think we are talking the same language and indeed draft-quinn-nsh takes this exact approach.

while I’d like to refrain judgement which approach is advantageous, I’d expect the WG will at least discuss it. The above text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted? Has the pre-WG participants already determine a separate layer is a MUST?
Jim> there seems to general consensus to postpone discussion beyond the charter until after the WG is formed.

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] New NSC WG Charter
Importance: High

Greetings,

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

---

From: "Elzur, Uri" <[email-masked]>
Date: Tue, 17 Sep 2013 20:26:10 +0000

Hi Jim

Thx for the quick response. Pls see below [UE]

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Tuesday, September 17, 2013 10:49 AM
To: Elzur, Uri; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Hi Uri,

Inline ..

[UE] let me try to be more specific. I'd like to make sure the Service Function Chain can be integrated within the entity that provides the Network Overlay (for example for the simple case of a single Admin domain and a single Network Overlay deployed here)
I'm not trying to imply that the proposed charter presents the SFC as  a Network Layer. I'm concerned about a separate name space for Services (on top of that used for a Network Overlay or any Transport already in use). Such use may increase the storage required in the network (Switch, Router, vSwitch etc.) and in the Service devices.  Another concern relates to the SFC header location. If it is a separate entity, it may mean that more info like routing info be required, which may be separate from and duplicate of the routing info provided by a Tunnel/Overlay). I'd like to suggest the WG charter keeps the door open for extending an existing Overly header to include the SFC info (which I think, the consensus is that it is needed), as long as we talk about Service graph, service index etc.

It seems like a by-product of creating an independent Service layer with full encapsulation (i.e. header with some routing info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways everywhere an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the "service layer" .
Jim> again I think this may simply be a terminology mismatch. The overlay is simply the transport used to get packets to/from service functions and this overlay may or may not span administrative domains. Gateways may be necessary if translation at the service encapsulation layer is needed between domains. It is worth noting that the initial task of the WG will be to work on single domain use cases only before tackling any inter-domain dependencies.
[UE] Jim, not sure what "overlay is simply the transport" is referred to in your comment above (existing Transport or a new one for the Services). Pls see my comment above, I hope we can include the case where the Transport for the SFC may also be a Transport already in use (e.g. extending an overlay like VXLAN to become VXLAN+ or GRE => GRE+ etc.) vs. a completely new Transport

The WG can achieve the same goal by defining the structure of the SFC headers to be added and make that format universal across any network layer. i.e. let's suggest some headers containing meta-data and service graph. The same structure can be applied to any network layer, in essence extending its functionality, by the IETF WG that owns that layer, prime candidates will be overlays used in the context of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for those who wish it, but does nothing to restrict the WG to such Service layer ONLY.
Jim> I think we are talking the same language and indeed draft-quinn-nsh takes this exact approach.
[UE] I've looked at rev 01 and was not sure as it is not specific enough. Between the definitions of the Service Path, Network Platform Context and Service Platform Context provided in the draft and the GRE example, I was not able to tell how close it is to the direction suggested above. If indeed we are on the same page, I rest my case (and the associated email thread :))

while I'd like to refrain judgement which approach is advantageous, I'd expect the WG will at least discuss it. The above text in the proposed charter seems to stand against reviewing/discussing this point. Is this discussion not warranted? Has the pre-WG participants already determine a separate layer is a MUST?
Jim> there seems to general consensus to postpone discussion beyond the charter until after the WG is formed.
[UE] just trying to ensure the charter ALLOWS for the above outlined option. The architectural discussion can follow later

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568

Greetings,

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 18 Sep 2013 19:03:53 +0000

Uri,

There has been consensus to postpone the discussion that you are bringing (as I understand it) until after the WG is formed. At the risk of inviting the wrath of Jim, comment inline.

Surendra.

From: <Elzur>, Uri <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 17, 2013 1:26 PM
To: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Hi Jim

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Tuesday, September 17, 2013 10:49 AM
To: Elzur, Uri; [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Hi Uri,

Inline ..

[UE] let me try to be more specific. I’d like to make sure the Service Function Chain can be integrated within the entity that provides the Network Overlay (for example for the simple case of a single Admin domain and a single Network Overlay deployed here)
I’m not trying to imply that the proposed charter presents the SFC as  a Network Layer. I’m concerned about a separate name space for Services (on top of that used for a Network Overlay or any Transport already in use). Such use may increase the storage required in the network (Switch, Router, vSwitch etc.) and in the Service devices.  Another concern relates to the SFC header location. If it is a separate entity, it may mean that more info like routing info be required, which may be separate from and duplicate of the routing info provided by a Tunnel/Overlay). I’d like to suggest the WG charter keeps the door open for extending an existing Overly header to include the SFC info (which I think, the consensus is that it is needed), as long as we talk about Service graph, service index etc.
SK> If you are talking about absorbing the service-specific information (or service-header to use a term for clarity) into the transports, such as integrating all that into VXLAN header, it may be too early to talk about it. However, it did come up earlier in the discussion as well and it is not the idea that we should be pursuing as it is fraught with issues and many attempts in the past have not succeeded in similar efforts.

It seems like a by-product of creating an independent Service layer with full encapsulation (i.e. header with some routing info as well as other info related to the service graph and potentially service index number as proposed on the list) may cause a need for gateways everywhere an overlay is used or everywhere the traffic needs to traverse those separate domains to get into the “service layer” .
Jim> again I think this may simply be a terminology mismatch. The overlay is simply the transport used to get packets to/from service functions and this overlay may or may not span administrative domains. Gateways may be necessary if translation at the service encapsulation layer is needed between domains. It is worth noting that the initial task of the WG will be to work on single domain use cases only before tackling any inter-domain dependencies.
[UE] Jim, not sure what “overlay is simply the transport” is referred to in your comment above (existing Transport or a new one for the Services). Pls see my comment above, I hope we can include the case where the Transport for the SFC may also be a Transport already in use (e.g. extending an overlay like VXLAN to become VXLAN+ or GRE => GRE+ etc.) vs. a completely new Transport

The WG can achieve the same goal by defining the structure of the SFC headers to be added and make that format universal across any network layer. i.e. let’s suggest some headers containing meta-data and service graph. The same structure can be applied to any network layer, in essence extending its functionality, by the IETF WG that owns that layer, prime candidates will be overlays used in the context of Network Virtualization e.g. added to VXLAN, NVGRE, GRE or any other layer. It can also allow creation of a dedicated Service layer OUTSIDE of such Transports or Overlays for those who wish it, but does nothing to restrict the WG to such Service layer ONLY.
Jim> I think we are talking the same language and indeed draft-quinn-nsh takes this exact approach.
[UE] I’ve looked at rev 01 and was not sure as it is not specific enough. Between the definitions of the Service Path, Network Platform Context and Service Platform Context provided in the draft and the GRE example, I was not able to tell how close it is to the direction suggested above. If indeed we are on the same page, I rest my case (and the associated email thread :))

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, September 13, 2013 7:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nsc] New NSC WG Charter
Importance: High

Greetings,

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 20 Sep 2013 15:20:05 +0000

Surendra, All
I'm not trying to have that discussion now. All I'm asking is to get the CHARTER such that it will allow it in the future
Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, September 18, 2013 12:04 PM
To: Elzur, Uri; Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Uri,

Surendra.

Hi Jim

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568

Hi Uri,

Inline ..

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568

Greetings,

---

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

Hi Uri,
I see no reason why the current charter does not allow for the points that you have raised.

Sent from my iPhone

On Sep 20, 2013, at 11:20 AM, "Elzur, Uri" <[email-masked]<mailto:[email-masked]>> wrote:

Surendra, All
I’m not trying to have that discussion now. All I’m asking is to get the CHARTER such that it will allow it in the future
Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Wednesday, September 18, 2013 12:04 PM
To: Elzur, Uri; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Uri,

Surendra.

Hi Jim

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568

Hi Uri,

Inline ..

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568

Greetings,

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 20 Sep 2013 12:34:00 -0700

My interpretation of the following line:
A document will describe the single service-level encapsulation protocol
for conveying the service function chain and the service function path
is that there will be a single encapsulation protocol at the "service
layer". Are we saying that there could be more than one way of carrying
this header but that the contents would be the same?

Would the output of this WG would allow the creation of a service chain
even when overlays are not in use?  (This is not clear from reading the
charter.)

Finally, is the work intended to support chains of both transparent and
non-transparent appliances, or is the focus mainly on transparent
appliances?  I ask because there may be interesting layering issues with
respect to the placement of this header, especially if we have a
combination of transparent and non-transparent appliances.

Anoop

On Fri, Sep 20, 2013 at 8:58 AM, Jim Guichard (jguichar) <[email-masked]
> wrote:

> On Sep 20, 2013, at 11:20 AM, "Elzur, Uri" <[email-masked]> wrote:
>
>   Surendra, All****
>
> I’m not trying to have that discussion now. All I’m asking is to get the
> CHARTER such that it will allow it in the future****
>
> Thx****
>
>  ****
>
> Uri ("Oo-Ree")****
>
> O: (949)-567-4519****
>
> C: (949)-378-7568****
>
> *From:* Surendra Kumar (smkumar) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Wednesday, September 18, 2013 12:04 PM
> *To:* Elzur, Uri; Jim Guichard (jguichar); [email-masked]
> *Subject:* Re: [nsc] New NSC WG Charter - charter bullet #3****
>
> ** **
>
> Uri,****
>
> ** **
>
> There has been consensus to postpone the discussion that you are bringing
> (as I understand it) until after the WG is formed. At the risk of inviting
> the wrath of Jim, comment inline.****
>
> ** **
>
> Surendra.****
>
> ** **
>
> *From: *<Elzur>, Uri <[email-masked]>
> *Date: *Tuesday, September 17, 2013 1:26 PM
> *To: *"Jim Guichard (jguichar)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [nsc] New NSC WG Charter - charter bullet #3****
>
> ** **
>
> Hi Jim****
>
>  ****
>
> Thx for the quick response. Pls see below [UE]****
>
>  ****
>
> Thx****
>
>  ****
>
> Uri ("Oo-Ree")****
>
> O: (949)-567-4519****
>
> C: (949)-378-7568****
>
> *From:* Jim Guichard (jguichar) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, September 17, 2013 10:49 AM
> *To:* Elzur, Uri; [email-masked]
> *Subject:* Re: [nsc] New NSC WG Charter - charter bullet #3****
>
>  ****
>
> Hi Uri,****
>
>  ****
>
> Inline ..****
>
>  ****
>
> *From: *<Elzur>, Uri <[email-masked]>
> *Date: *Tuesday, September 17, 2013 7:09 AM
> *To: *Microsoft Office User <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [nsc] New NSC WG Charter - charter bullet #3****
>
>  ****
>
> Bullet 3 below suggests “it is intended that the encapsulation be agnostic
> to the network layer at which it is applied and the service that is being
> constructed. That is, the same encapsulation may be used on a service
> function path realised at the network layer or at any other layer, and the
> same encapsulation will apply for the construction of service function
> paths regardless of the actual service”****
>
> This makes me wonder. I assume the intention of the nsc WG is to provide
> services to some network nodes that reside in some domain e.g. an overlay,
> or in some (single?) admin domain. Would it not be simpler and more natural
> to provide the service * at that layer*? It seems like the number of
> cases where a service is centralized or offered across different admin
> domain than that of the consuming nodes, may be dwarfed by the cases where
> they co-reside, maybe in the same row, maybe in the same rack or even on
> the same server. The incentive may be to localize the service close to its
> consumer to reduce the network burden of carrying traffic unnecessarily
> over some distance. Virtualization and Virtual appliances may enable such
> phenomenon.****
>
> Jim>  it is certainly true that different administrative domains may be
> present within a particular operators network and indeed those domains may
> be separately managed and therefore services may need to span multiple
> domains. However, I am confused by your use of the term "layer". Within the
> charter when we refer to a layer we mean a layer of the protocol stack and
> not a layer of the network. We certainly don't mean to imply any form of
> network boundary or delineation. In addition, nothing in the above
> prevents the service functions to be co-resident with workloads. It just
> makes it general enough to address the broad range of deployment scenarios.
> Given that "migration" is a killer-app of virtualization, service-overlay
> becomes critical.****
>
>  ****
>
> [UE] let me try to be more specific. I’d like to make sure the Service
> Function Chain can be integrated within the entity that provides the
> Network Overlay (for example for the simple case of a single Admin domain
> and a single Network Overlay deployed here)****
>
> I’m not trying to imply that the proposed charter presents the SFC as  a
> Network Layer. I’m concerned about a separate name space for Services (on
> top of that used for a Network Overlay or any Transport already in use).
> Such use may increase the storage required in the network (Switch, Router,
> vSwitch etc.) and in the Service devices.  Another concern relates to the
> SFC header location. If it is a separate entity, it may mean that more info
> like routing info be required, which may be separate from and duplicate of
> the routing info provided by a Tunnel/Overlay). I’d like to suggest the WG
> charter keeps the door open for extending an existing Overly header to
> include the SFC info (which I think, the consensus is that it is needed),
> as long as we talk about Service graph, service index etc.****
>
> SK> If you are talking about absorbing the service-specific information
> (or service-header to use a term for clarity) into the transports, such as
> integrating all that into VXLAN header, it may be too early to talk about
> it. However, it did come up earlier in the discussion as well and it is not
> the idea that we should be pursuing as it is fraught with issues and many
> attempts in the past have not succeeded in similar efforts.****
>
>  ****
>
> It seems like a by-product of creating an independent Service layer with
> full encapsulation (i.e. header with some routing info as well as other
> info related to the service graph and potentially service index number as proposed
> on the list) may cause a need for gateways everywhere an overlay is used or
> everywhere the traffic needs to traverse those separate domains to get into
> the “service layer” .****
>
> Jim> again I think this may simply be a terminology mismatch. The overlay
> is simply the transport used to get packets to/from service functions and
> this overlay may or may not span administrative domains. Gateways may be
> necessary if translation at the service encapsulation layer is needed
> between domains. It is worth noting that the initial task of the WG will be
> to work on single domain use cases only before tackling any inter-domain
> dependencies.****
>
> [UE] Jim, not sure what “overlay is simply the transport” is referred to
> in your comment above (existing Transport or a new one for the Services).
> Pls see my comment above, I hope we can include the case where the
> Transport for the SFC may also be a Transport already in use (e.g.
> extending an overlay like VXLAN to become VXLAN+ or GRE => GRE+ etc.) vs. a
> completely new Transport****
>
>  ****
>
>  ****
>
> The WG can achieve the same goal by defining the structure of the SFC
> headers to be added and make that format universal across any network
> layer. i.e. let’s suggest some headers containing meta-data and service
> graph. The same structure can be applied to *any* network layer, in
> essence extending its functionality, by the IETF WG that owns that layer,
> prime candidates will be overlays used in the context of Network
> Virtualization e.g. added to VXLAN, NVGRE, GRE or any other layer. It can
> also allow creation of a dedicated Service layer OUTSIDE of such Transports
> or Overlays for those who wish it, but does nothing to restrict the WG to
> such Service layer ONLY. ****
>
> Jim> I think we are talking the same language and indeed draft-quinn-nsh
> takes this exact approach. ****
>
> [UE] I’ve looked at rev 01 and was not sure as it is not specific enough.
> Between the definitions of the Service Path, Network Platform Context and
> Service Platform Context provided in the draft and the GRE example, I was
> not able to tell how close it is to the direction suggested above. If
> indeed we are on the same page, I rest my case (and the associated email
> thread J)****
>
>  ****
>
> while I’d like to refrain judgement which approach is advantageous, I’d
> expect the WG will at least discuss it. The above text in the proposed
> charter seems to stand against reviewing/discussing this point. Is this
> discussion not warranted? Has the pre-WG participants already determine a
> separate layer is a MUST?****
>
> Jim> there seems to general consensus to postpone discussion beyond the
> charter until after the WG is formed. ****
>
> [UE] just trying to ensure the charter ALLOWS for the above outlined
> option. The architectural discussion can follow later****
>
>  ****
>
> Thx****
>
>  ****
>
> Uri ("Oo-Ree")****
>
> O: (949)-567-4519****
>
> C: (949)-378-7568****
>
> *From:[email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Jim Guichard (jguichar)
> *Sent:* Friday, September 13, 2013 7:08 AM
> *To:* [email-masked]
> *Subject:* [nsc] New NSC WG Charter
> *Importance:* High****
>
>  ****
>
> Greetings,****
>
>  ****
>
> We have been working with the routing area AD's and our IAB shepherd Joel
> Halpern over the last few days to refine the NSC WG charter. The following
> is our proposal to the community for review and comment. Please note that
> as an outcome of the various discussions on the list we are proposing that
> the WG name change from "Network Service Chaining (NSC)" to "Service
> Function Chaining (SFC)". ****
>
>  ****
>
> *Proposed Service Function Chaining (SFC) WG Charter*****
>
>  ****
>
> Networks, servers, storage technologies, and applications, have all
> undergone significant change in recent years with the introduction of
> virtualization, network overlays, and orchestration. The process of service
> delivery is changing from the physical insertion of equipment on the path
> into a mechanism for causing the path or data to transit specific physical
> or virtual nodes on which the service functions are performed. Services are
> typically implemented by the ordered combination of a number of service
> functions that may be implemented at different points within the
> network.Service delivery is currently both a technical and organisational
> challenge that involves significant modification to the network
> configuration.****
>
> For a given service, the abstracted view of the required service functions
> and the order in which they are to be invoked is called a Service Function
> Chain (SFC). Since a given service function may be available on more than
> one node within a network, a ServiceFunction Chain is instantiated via the
> selection of specific service function instances and the network nodes on
> which they are provided, thereby forming a servicetopology: this is called
> a Service Function Path. The service functions may be applied at a specific
> layer within the network protocol stack (network layer, application layer,
> etc.).****
>
> The Service Function Chaining (SFC) working group will develop new
> approaches to service delivery and deployment, by providing a framework for
> service function chaining and the necessary protocols or protocol
> extensions to convey the service path and for communication between nodes
> that implement service functions.  The working group will also examine what
> information needs to be gathered from the network and service functions in
> support of service function chaining and how that information may be made
> available to nodes that implement the service functions.****
>
> Specifically, the SFC WG is chartered to deliver the following: ****
>
> 1) Problem Statement: This document will provide a summary of the problem
> space to be addressed by the WG including example high-level use cases.
>  Additionally, the WG will normalize nomenclature and definitions for
> service function chaining.****
>
> 2) Architecture: This document will provide a description of the
> architectural building blocks and their relationships including
> interconnection, placement of capabilities, management, diagnostics, and
> security models, as well as requirements on the protocol mechanisms.****
>
> 3) Generic Service Function Chaining Encapsulation: A document will
> describe the single service-level encapsulation protocol for conveying the
> service function chain and the service function path, and for communicating
> information between nodes that implement service functions. It is intended
> that the encapsulation be agnostic to thenetwork layer at which it is
> applied and the service that is being constructed. That is, the same
> encapsulation may be used on a service function path realised at the
> network layer or at any other layer, and the same encapsulation willapply
> for the construction of service function paths regardless of the actual
> service.****
>
> 4) Control Plane Mechanisms: A set of documents will be developed to
> describe requirements and protocols necessary to convey information to
> service function implementation points. Where possible, existing IETF
> protocols will be used and extended. All protocol extensions work should be
> carried out in the working groups responsible for the protocols being
> modified in coordination with this working group, but may be done in this
> working group after agreement with all the relevant WG chairs and
> responsible ADs.****
>
> 5) Manageability: This document will address the management of service
> function chaining includingrelevant MIBs and YANG data modules, and service
> function chaining diagnostics.****
>
> Proposed Milestones (all dates TBD):****
>
> Request the IESG for publication of an Informational document defining the
> problem statement and core use cases for Service Function Chaining****
>
> Request the IESG for publication of Informational documents defining the
> architecture for SFC and describing the framework and requirements for a
> generic service function chaining encapsulation protocol.****
>
> Request the IESG for publication of a Standards Track document specifying
> the generic service function chaining encapsulation protocol.****
>
> Request the IESG for publication of Informational documents specifying
> control plane requirements in support of specific SFC use cases.****
>
> Request the IESG for publication of an Informational document defining SFC
> manageability including diagnostics, and MIB and YANG data models to IESG
> ****
>
> Request the IESG for publication of Informational applicability documents
> defining how the protocol elements developed by the WG may be combined with
> other IETF protocols to satisfy the use cases.****
>
>  ****
>
>  ****
>
>
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Sep 2013 14:11:51 +0100

Hi Anoop,

> A document will describe the single service-level encapsulation protocol for
> conveying the service function chain and the service function path
>>>
>
> is that there will be a single encapsulation protocol at the "service layer".
Are
> we saying that there could be more than one way of carrying this header but
> that the contents would be the same?

That is my interpretation.

I.e., this is an encapsulation that can be placed between the "transport" (e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

> Would the output of this WG would allow the creation of a service chain even
> when overlays are not in use?  (This is not clear from reading the charter.)

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another network?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

> Finally, is the work intended to support chains of both transparent and non-
> transparent appliances, or is the focus mainly on transparent appliances?  I
> ask because there may be interesting layering issues with respect to the
> placement of this header, especially if we have a combination of transparent
> and non-transparent appliances.

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I don't think we
know enough about the use cases and requirements to answer your question at this
stage.

But if enough people show up on the list saying that they only want to handle
one categorisation, then perhaps we can limit from day one.

Cheers,
Adrian

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 22 Sep 2013 09:33:28 -0700

Hi Adrian,

I.e., this is an encapsulation that can be placed between the "transport"
(e.g.,
IP, MPLS, TCP, HTTP....) and the payload.

OK, I think that's a bit different from what Uri was arguing for.

Well, erm, what is an "overlay"?
Isn't an overlay just a network that happens to be running over another
network?
Why would that need to be mentioned explicitly?
Why would you assume it is ruled out if it is not mentioned?

I tend to think of an overlay as one where there are multiple occurrences
of the same layer of  header in the packet., but maybe I have it wrong.
 Does the IETF have a formal definition for this?

That is probably a good question.
Personally, I would like to put it "for investigation." I.e., I don't think
we
know enough about the use cases and requirements to answer your question at
this
stage.

But if enough people show up on the list saying that they only want to
handle
one categorisation, then perhaps we can limit from day one.

I think it would make sense to add something explicit to the charter about
this.

Since I have been asked the question offline, I will go ahead and explain
what I mean by transparent vs non-transparent appliances.  With a
non-transparent appliance, the appliance appears as a "router" in the path
of the data.  As far as I'm aware this is how load balancers are deployed
and this is how firewalls are commonly deployed.  In the non-transparent
case, the address of the appliance does not appear in the packet; instead
packets are diverted to the appliance using PBR.  This used sometimes for
IDS/IPS type appliances.

Anoop

On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel <[email-masked]> wrote:

> for
> layer".
> even
> non-

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 22 Sep 2013 17:00:32 +0000

Hi, Anoop,

> That is my interpretation.

Yes.

> OK, I think that's a bit different from what Uri was arguing for.

An explicit goal is that the encapsulation carrying service information not be dependent on the transport. 

Like Jim said, the charter does not disallow (sorry for the double negative) the points on this thread, to be discussed on the WG-to-be.

> I tend to think of an overlay as one where there are multiple occurrences of the same layer of  header in the packet., but maybe I have it wrong.  Does the IETF have a formal definition for this?
> 

I am not sure if there is *a* formal definition of Network overlay, but the meaning is a network running on top of another network, regardless of the "same layer of header".

> I think it would make sense to add something explicit to the charter about this.
> 

The charter, in its lack of explicit mention, is generic to allow for this to be discussed later.

I strongly disagree with limiting this early on the on this, as I do not believe the WG discussed it to make that call.

Seems like a degree of granularity for a framework or an architecture and not a charter.

Thanks,

-- Carlos.

> Since I have been asked the question offline, I will go ahead and explain what I mean by transparent vs non-transparent appliances.  With a non-transparent appliance, the appliance appears as a "router" in the path of the data.  As far as I'm aware this is how load balancers are deployed and this is how firewalls are commonly deployed.  In the non-transparent case, the address of the appliance does not appear in the packet; instead packets are diverted to the appliance using PBR.  This used sometimes for IDS/IPS type appliances.
> 
> Anoop
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Sun, 22 Sep 2013 18:14:07 +0000

Hi Anoop,

Could you be more specific as to your definition for transparent and non-transparent appliances?

Sent from my iPhone

> On Sep 22, 2013, at 9:12 AM, "Adrian Farrel" <[email-masked]> wrote:
> 
> Hi Anoop,
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sun, 22 Sep 2013 19:23:29 +0000

Anoop,

Comments inline.

Surendra.

From: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Date: Sunday, September 22, 2013 9:33 AM
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Hi Adrian,

I tend to think of an overlay as one where there are multiple occurrences of the same layer of  header in the packet., but maybe I have it wrong.  Does the IETF have a formal definition for this?
SK> Here is an IP-in-MAC overlay or L3 packet over L2 network: [L2-LLC/SNAP| original-IPpayload—noL2Hdr] This is still an overlay although the same layer does not appear multiple times.

I think it would make sense to add something explicit to the charter about this.
SK> It is not necessary to add such detail to the charter when it is not needed.

Since I have been asked the question offline, I will go ahead and explain what I mean by transparent vs non-transparent appliances.  With a non-transparent appliance, the appliance appears as a "router" in the path of the data.  As far as I'm aware this is how load balancers are deployed and this is how firewalls are commonly deployed.  In the non-transparent case, the address of the appliance does not appear in the packet; instead packets are diverted to the appliance using PBR.  This used sometimes for IDS/IPS type appliances.
SK> That is my interpretation of transparent and terminated as well. It is also referred to as the go-to vs go-through, bridged vs routed, off-path vs in-path etc. I also would like to note that the same appliance could behave both as a transparent or a terminated. It depends on the service function.
When we speak of service chains, I really expect terminated service functions to be part of the chain and in that sense terminated should be in scope. Having said that, we can debate later.

Anoop

On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi Anoop,

Are

Cheers,
Adrian

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sun, 22 Sep 2013 19:24:26 +0000

+1

Surendra.

From: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, September 22, 2013 10:00 AM
To: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Hi, Anoop,

On Sep 22, 2013, at 12:33 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

Yes.

Thanks,

-- Carlos.

Anoop

Are

Cheers,
Adrian

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

---

From: "Elzur, Uri" <[email-masked]>
Date: Mon, 23 Sep 2013 06:40:25 +0000

My point was that given some "overlay" or "encapsulation" that is "placed between the transport" where the potential consumers of the "service" are located, the "services" should be stitched into that "overlay", as one option that is to be allowed by the charter.
Exchanges on this ml in last few days, reaffirms that the issue is resolved for now as the proposed charter allows for this combination.

(in plain text: VMs connected by an overlay [e.g. VXLAN, GRE etc. in a multitenant environment] that request services [e.g. LB/FW and other], could get the services at that overlay [extension will be required] vs. requiring a different encapsulation dedicated for services only [with no VMs])

Thx

Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Sunday, September 22, 2013 9:33 AM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Hi Adrian,

Anoop

Are

Cheers,
Adrian

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 23 Sep 2013 07:54:44 -0400

> I am not sure if there is *a* formal definition of Network overlay, but the meaning is a network running on top of another network, regardless of the "same layer of header".

	Precisely. It is my understanding that you can have "IP over IP" for example, and that should be completely valid.

	--Tom

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 23 Sep 2013 16:12:36 +0000

Adrian, 

Just want to double check your comments

> -----Original Message-----
> 

[Linda] Does it mean that using IETF already defined header for encapsulation will NOT be excluded by the NSC (or SFC) Charter if the existing header can carry the needed metadata among Service Functions?

> Why would that need to be mentioned explicitly?

[Linda] I have the same question. 
I can't tell from the wording in the charter if the charter allows the option of the "metadata" among Service Functions being carried by out-of-band methods, can it?

Linda

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Sep 2013 19:38:29 +0100

Hello Linda,

> > I.e., this is an encapsulation that can be placed between the
> > "transport" (e.g., IP, MPLS, TCP, HTTP....) and the payload.
> 
> [Linda] Does it mean that using IETF already defined header for encapsulation
will
> NOT be excluded by the NSC (or SFC) Charter if the existing header can carry
the
> needed metadata among Service Functions?

The draft charter text says:

| 3) Generic Service Function Chaining Encapsulation: A document will
| describe the single service-level encapsulation protocol for conveying
| the service function chain and the service function path, and for
| communicating information between nodes that implement service
| functions. It is intended that the encapsulation be agnostic to the
| network layer at which it is applied and the service that is being
| constructed. That is, the same encapsulation may be used on a
| service function path realized at the network layer or at any other
| layer, and the same encapsulation will apply for the construction of
| service function paths regardless of the actual service. 

It also says:

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

There is no specific exclusion of using (or overloading) fields in the
transport/tunnelling/encapsulation protocol. On the other hand, there is no
exclusion of killing elephants and having a giant barbeque.

If there is something specific you think should be in scope for the working
group I suggest that *now* is the time to raise it and the mailing list can
discuss.

For me, I have to ask:
Suppose foo is a well-known edge-to-edge tunnelling protocol. Suppose that foo
has the ability to include additional information (such as TLVs) in the
encapsulation header. Suppose there is a proposal to carry SFC information
directly in foo.
Suppose also that the WG delivers on item 3).
Now, in a foo network where I want to achieve service chaining, which mechanism
will I use?
When I need to encapsulate foo packets in bah packets, will I need to
move/copy/whatever the information from the foo header into a generic header and
insert it?
If there are many examples of foo, will implementations that support service
chaining have to understand each way of carrying chaining information in each
example of foo? Compare this with a single generic protocol. Then consider why
IP has been successful.

> I can't tell from the wording in the charter if the charter allows the option
of the
> "metadata" among Service Functions being carried by out-of-band methods, can
> it?

I think "metadata" is a particularly poor term to use here because it actually
directly means "additional data attached to something specific". So, it is
metadata when you put it in the encapsulation header on a packet, but if it is
out of band, it is what it is.

So, let's look at what you might be talking about for "metadata":
- The details of the service chain itself (e.g. the service path)
- Information that one service node wants to communicate with
  another service node (e.g. about how to perform given some
  state information)

We should also look at what you mean by out-of-band. I think here you mean
"using some information exchange protocol."

The charter says:

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

and: 

| 4) Control Plane Mechanisms: A set of documents will be
| developed to describe requirements and protocols necessary
| to convey information to service function implementation
| points. Where possible, existing IETF protocols will be used
| and extended.

This feels like out-of-band exchange of information is expected.

Adrian

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 24 Sep 2013 23:02:09 +0000

Adrian, 

Very good analysis. Thank you. 

"Metadata" has been used extensively in the NSC context. But beyond the "service chain ID", I can't find any other necessary information required to be exchanged among the "Service Functions" in all the use cases presented at the Berlin informal BoF and use cases drafts. Can anyone give some examples of the information required to be exchanged among those "Service Functions" given by the draft-quinn-nsc-arch-00?

A non-exhaustive list of Service Functions includes: firewalls,
WAN and application acceleration, Deep Packet Inspection (DPI),
server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
injection, HTTP Header Enrichment functions, TCP optimizer, etc.

Thanks, Linda 

> "using some information exchange protocol."

[Linda] Since each Service-Chain ID represents a list of service functions, it is possible to use "out-of-band" control channel to pass the information on the sequence of Service Functions associated with the ID.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 24 Sep 2013 20:17:53 -0400

> "Metadata" has been used extensively in the NSC context. But beyond the "service chain ID", I can't find any other necessary information required to be exchanged among the "Service Functions" in al…

	Some examples might be OAM, other stats, service chain descriptions, etc...

	--Tom

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 25 Sep 2013 01:50:32 +0000

There are definitely quite a few additional candidates for metadata fields of interest... But I believe we need much more work on the PROBLEM STATEMENT, and not jump to solution design. 

We really need to work much more on use cases. Some use cases may imply more 'metadata' than others. Simple problems may be solved by simple means. More complex problems may require more complex elements of solutions. Some cases could be solved by signaling means instead of data plane means. Or the reverse way around. Etc.

Let me suggest we give more priority to refining the problem statement(s) first... And not rush the design process.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 24, 2013 8:18 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

	--Tom

> A non-exhaustive list of Service Functions includes: firewalls, WAN 
> and application acceleration, Deep Packet Inspection (DPI), server 
> load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID injection, 
> HTTP Header Enrichment functions, TCP optimizer, etc.

>> I think "metadata" is a particularly poor term to use here because it 
>> actually directly means "additional data attached to something 
>> specific". So, it is metadata when you put it in the encapsulation 
>> header on a packet, but if it is out of band, it is what it is.
>> 
>> another service node (e.g. about how to perform given some  state 
>> information)
>> 
>> We should also look at what you mean by out-of-band. I think here you 
>> mean "using some information exchange protocol."
> 
>> | The Service Function Chaining (SFC) working group will develop new 
>> | approaches to service delivery and deployment, by providing a 
>> | framework for service function chaining and the necessary protocols 
>> | or protocol extensions to convey the service path and for 
>> | 4) Control Plane Mechanisms: A set of documents will be developed 
>> | to describe requirements and protocols necessary to convey 
>> | information to service function implementation points. Where 
>> | possible, existing IETF protocols will be used and extended.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Sep 2013 03:23:53 -0400

For me, the canonical example of metadata applies to the use case of a 
service chain providing residential gateway functionality with network 
resident NAT.
If the operator is choosing, due to IPv4 exhaustion, to resuse IP 
addresses across subscribers, then some field is needed to identify the 
subscriber in the service chain.
In a classic BNG, the physical port, VLAN, or incoming MAC address 
provides this function.  But those will all be lost in the service chain.

I have also seen cases where DPI service engines are separate entities 
in the chain from services which need the results of the DPI.  That 
seems a natural candidate for metadata.

Yours,
Joel

On 9/24/13 7:02 PM, Linda Dunbar wrote:
>> actually
>> mean

---

From: "Elzur, Uri" <[email-masked]>
Date: Wed, 25 Sep 2013 08:40:24 +0000

+1

Thx
 
Uri ("Oo-Ree")
O: (949)-567-4519
C: (949)-378-7568

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 24, 2013 8:18 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

	--Tom

>> - Information that one service node wants to communicate with another 
>> service node (e.g. about how to perform given some  state
>> information)
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Sep 2013 12:07:20 +0000

This, access/subscriber identification, is a good example.

Another typical example is to use metadata to share the result of ingress classification, or network information (as e.g., to be used in subscriber identification) to then be used for policy in a service function downstream the service path. One such example is VRF information.

Thanks,

-- Carlos.

On Sep 25, 2013, at 3:23 AM, Joel M. Halpern <[email-masked]> wrote:

> For me, the canonical example of metadata applies to the use case of a service chain providing residential gateway functionality with network resident NAT.
> If the operator is choosing, due to IPv4 exhaustion, to resuse IP addresses across subscribers, then some field is needed to identify the subscriber in the service chain.
> In a classic BNG, the physical port, VLAN, or incoming MAC address provides this function.  But those will all be lost in the service chain.
> 
> I have also seen cases where DPI service engines are separate entities in the chain from services which need the results of the DPI.  That seems a natural candidate for metadata.
> 
> Yours,
> Joel
>

---

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

Hi Anoop.

> packets are diverted to the appliance using PBR.  This used sometimes for

I don't quite get this. To me, SFC is all about applying service
functions to traffic flows -- but in a way that is transparent to
those traffic flows and the end points originating them. That is,
"applications" generating traffic aren't generally aware of these
service functions and they aren't really asking for them. They are
applied as the result of network policy/operations, not because the
applications need them (for correctness). E.g., load balancing and
firewalls.  Those sorts of things are applied by network operators
whether the applications want them or not. So the kinds of service
functions this group is interested in are in some sense by definition
"transparent" to applications.

[BTW, it would be useful to have a term for the endpoints of a chain
-- that is what I mean by "application" above. These are the
components of the overall service that are doing the work, i.e., the
DB, the application server, etc. They are *NOT* service functions, in
my mind.]

Service functions aren't going to be addressed by the traffic -
traffic is between the "applications", i.e., the end points of a
service chain.

Today, service functions are deployed along the path between
applications -- because that is how we know how to do it. Going
forward, we don't want to *require* that anymore. 

So back to your example of an appliance, I would call such appliances
"transparent" because they are not explicitely addressed by the
traffic flows and are in fact transparent to the applications.

Thomas

> --001a11c227eea3624604e6fb76cb
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable

> <div dir=3D"ltr">Hi Adrian,<div><br></div><div>&gt;&gt;&gt;</div><div>That =
> is my interpretation.<br><br>I.e., this is an encapsulation that can be pla=
> ced between the &quot;transport&quot; (e.g.,<br>IP, MPLS, TCP, HTTP....) an=
> d the payload.</div>
> <div>&gt;&gt;&gt;</div><div><br></div><div>OK, I think that&#39;s a bit dif=
> ferent from what Uri was arguing for.</div><div><br></div><div>&gt;&gt;&gt;=
> </div><div>Well, erm, what is an &quot;overlay&quot;?<br>Isn&#39;t an overl=
> ay just a network that happens to be running over another network?<br>
> Why would that need to be mentioned explicitly?<br>Why would you assume it =
> is ruled out if it is not mentioned?<br></div><div>&gt;&gt;&gt;</div><div><=
> br></div><div>I tend to think of an overlay as one where there are multiple=
>  occurrences of the same layer of =A0header in the packet., but maybe I hav=
> e it wrong. =A0Does the IETF have a formal definition for this?</div>
> <div><br></div><div>&gt;&gt;&gt;</div><div>That is probably a good question=
> .<br>Personally, I would like to put it &quot;for investigation.&quot; I.e.=
> , I don&#39;t think we<br>know enough about the use cases and requirements =
> to answer your question at this<br>
> stage.<br><br>But if enough people show up on the list saying that they onl=
> y want to handle<br>one categorisation, then perhaps we can limit from day =
> one.<br><div class=3D"gmail_extra">&gt;&gt;&gt;</div><div class=3D"gmail_ex=
> tra">
> <br></div><div class=3D"gmail_extra">I think it would make sense to add som=
> ething explicit to the charter about this.</div><div class=3D"gmail_extra">=
> <br></div><div class=3D"gmail_extra">Since I have been asked the question o=
> ffline, I will go ahead and explain what I mean by transparent vs non-trans=
> parent appliances. =A0With a non-transparent appliance, the appliance appea=
> rs as a &quot;router&quot; in the path of the data. =A0As far as I&#39;m aw=
> are this is how load balancers are deployed and this is how firewalls are c=
> ommonly deployed. =A0In the non-transparent case, the address of the applia=
> nce does not appear in the packet; instead packets are diverted to the appl=
> iance using PBR. =A0This used sometimes for IDS/IPS type appliances.</div>
> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Anoop<br><b=
> r><div class=3D"gmail_quote">On Sun, Sep 22, 2013 at 6:11 AM, Adrian Farrel=
>  <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=
> ank">[email-masked]</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
> left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
> adding-left:1ex">Hi Anoop,<br>
> <div class=3D"im"><br>
> &gt; My interpretation of the following line:<br>
> &gt;&gt;&gt;<br>
> &gt; A document will describe the single service-level encapsulation protoc=
> ol for<br>
> &gt; conveying the service function chain and the service function path<br>
> &gt;&gt;&gt;<br>
> &gt;<br>
> &gt; is that there will be a single encapsulation protocol at the &quot;ser=
> vice layer&quot;.<br>
> Are<br>
> &gt; we saying that there could be more than one way of carrying this heade=
> r but<br>
> &gt; that the contents would be the same?<br>
> <br>
> </div>That is my interpretation.<br>
> <br>
> I.e., this is an encapsulation that can be placed between the &quot;transpo=
> rt&quot; (e.g.,<br>
> IP, MPLS, TCP, HTTP....) and the payload.<br>
> <div class=3D"im"><br>
> &gt; Would the output of this WG would allow the creation of a service chai=
> n even<br>
> &gt; when overlays are not in use? =A0(This is not clear from reading the c=
> harter.)<br>
> <br>
> </div>Well, erm, what is an &quot;overlay&quot;?<br>
> Isn&#39;t an overlay just a network that happens to be running over another=
>  network?<br>
> Why would that need to be mentioned explicitly?<br>
> Why would you assume it is ruled out if it is not mentioned?<br>
> <div class=3D"im"><br>
> &gt; Finally, is the work intended to support chains of both transparent an=
> d non-<br>
> &gt; transparent appliances, or is the focus mainly on transparent applianc=
> es? =A0I<br>
> &gt; ask because there may be interesting layering issues with respect to t=
> he<br>
> &gt; placement of this header, especially if we have a combination of trans=
> parent<br>
> &gt; and non-transparent appliances.<br>
> <br>
> </div>That is probably a good question.<br>
> Personally, I would like to put it &quot;for investigation.&quot; I.e., I d=
> on&#39;t think we<br>
> know enough about the use cases and requirements to answer your question at=
>  this<br>
> stage.<br>
> <br>
> But if enough people show up on the list saying that they only want to hand=
> le<br>
> one categorisation, then perhaps we can limit from day one.<br>
> <br>
> Cheers,<br>
> Adrian<br>
> <br>
> </blockquote></div><br></div></div></div>

> --001a11c227eea3624604e6fb76cb--

> --===============0224793606959901704==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline

> --===============0224793606959901704==--

---

From: Ron Parker <[email-masked]>
Date: Wed, 25 Sep 2013 14:52:50 +0000

Thomas, Anoop,

It strikes me that this transparency is not wrt to the originator or addressee of the traffic, but rather between the SFC classifier and the SFC service nodes (SNs).    In particular, whether an encapsulating "transport" header (e.g., IPv4/UDP) is applied in front of the NSC/SFC "service header" (which is in front of the original packet), or not.

If an IP-layer encapsulation is applied, for example, the packets are routed/switched normally amongst the SFC classifier and SN's because the packets are explicitly IP addressed at each hop (given that the SN's would need to change the destination IP in the encapsulating header to select the "next" SN).   However, if a "transport" header is not applied, policy-based routing/switching would need to be used to steer the traffic in such a way that did not necessarily conform to traditional routing/switching decisions.

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, September 25, 2013 10:35 AM
To: Anoop Ghanwani
Cc: [email-masked]; Adrian Farrel
Subject: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

Hi Anoop.

Anoop Ghanwani <[email-masked]> writes:

> Since I have been asked the question offline, I will go ahead and 
> explain what I mean by transparent vs non-transparent appliances.  
> With a non-transparent appliance, the appliance appears as a "router" 
> in the path of the data.  As far as I'm aware this is how load 
> balancers are deployed and this is how firewalls are commonly 
> deployed.  In the non-transparent case, the address of the appliance 
> does not appear in the packet; instead packets are diverted to the 
> appliance using PBR.  This used sometimes for IDS/IPS type appliances.

I don't quite get this. To me, SFC is all about applying service functions to traffic flows -- but in a way that is transparent to those traffic flows and the end points originating them. That is, "applications" generating traffic aren't generally aware of these service functions and they aren't really asking for them. They are applied as the result of network policy/operations, not because the applications need them (for correctness). E.g., load balancing and firewalls.  Those sorts of things are applied by network operators whether the applications want them or not. So the kinds of service functions this group is interested in are in some sense by definition "transparent" to applications.

[BTW, it would be useful to have a term for the endpoints of a chain
-- that is what I mean by "application" above. These are the components of the overall service that are doing the work, i.e., the DB, the application server, etc. They are *NOT* service functions, in my mind.]

Service functions aren't going to be addressed by the traffic - traffic is between the "applications", i.e., the end points of a service chain.

Today, service functions are deployed along the path between applications -- because that is how we know how to do it. Going forward, we don't want to *require* that anymore. 

So back to your example of an appliance, I would call such appliances "transparent" because they are not explicitely addressed by the traffic flows and are in fact transparent to the applications.

Thomas

> > > we saying that there could be more than one way of carrying this 
> > > header
> > but
> > > ask because there may be interesting layering issues with respect 
> > > to the placement of this header, especially if we have a 
> > > combination of
> > transparent
> > Personally, I would like to put it "for investigation." I.e., I 
> > don't think we know enough about the use cases and requirements to 
> > answer your question at this stage.
> >
> > But if enough people show up on the list saying that they only want 
> > to handle one categorisation, then perhaps we can limit from day 
> > one.
> >
> > Cheers,
> > Adrian
> >
> >

> <div dir=3D"ltr">Hi 
> Adrian,<div><br></div><div>&gt;&gt;&gt;</div><div>That = is my 
> interpretation.<br><br>I.e., this is an encapsulation that can be pla= 
> ced between the &quot;transport&quot; (e.g.,<br>IP, MPLS, TCP, 
> HTTP....) an= d the payload.</div> 
> <div>&gt;&gt;&gt;</div><div><br></div><div>OK, I think that&#39;s a 
> bit dif= ferent from what Uri was arguing 
> for.</div><div><br></div><div>&gt;&gt;&gt;=
> </div><div>Well, erm, what is an &quot;overlay&quot;?<br>Isn&#39;t an 
> overl= ay just a network that happens to be running over another 
> network?<br> Why would that need to be mentioned explicitly?<br>Why 
> would you assume it = is ruled out if it is not 
> mentioned?<br></div><div>&gt;&gt;&gt;</div><div><=
> br></div><div>I tend to think of an overlay as one where there are 
> br>multiple=
>  occurrences of the same layer of =A0header in the packet., but maybe 
> I hav= e it wrong. =A0Does the IETF have a formal definition for 
> this?</div> <div><br></div><div>&gt;&gt;&gt;</div><div>That is 
> probably a good question= .<br>Personally, I would like to put it 
> &quot;for investigation.&quot; I.e.= , I don&#39;t think we<br>know 
> enough about the use cases and requirements = to answer your question 
> at this<br> stage.<br><br>But if enough people show up on the list 
> saying that they onl= y want to handle<br>one categorisation, then 
> perhaps we can limit from day = one.<br><div 
> class=3D"gmail_extra">&gt;&gt;&gt;</div><div class=3D"gmail_ex= tra"> 
> <br></div><div class=3D"gmail_extra">I think it would make sense to 
> add som= ething explicit to the charter about this.</div><div 
> class=3D"gmail_extra">= <br></div><div class=3D"gmail_extra">Since I 
> have been asked the question o= ffline, I will go ahead and explain 
> what I mean by transparent vs non-trans= parent appliances. =A0With a 
> non-transparent appliance, the appliance appea= rs as a 
> &quot;router&quot; in the path of the data. =A0As far as I&#39;m aw= 
> are this is how load balancers are deployed and this is how firewalls 
> are c= ommonly deployed. =A0In the non-transparent case, the address 
> of the applia= nce does not appear in the packet; instead packets are 
> diverted to the appl= iance using PBR. =A0This used sometimes for 
> IDS/IPS type appliances.</div> <div 
> class=3D"gmail_extra"><br></div><div 
> class=3D"gmail_extra">Anoop<br><b=
> r><div class=3D"gmail_quote">On Sun, Sep 22, 2013 at 6:11 AM, Adrian 
> r>Farrel=
>  <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" 
> target=3D"_bl= ank">[email-masked]</a>&gt;</span> wrote:<br> 
> &gt; My interpretation of the following line:<br> &gt;&gt;&gt;<br> 
> &gt; A document will describe the single service-level encapsulation 
> protoc= ol for<br> &gt; conveying the service function chain and the 
> service function path<br> &gt;&gt;&gt;<br> &gt;<br> &gt; is that there 
> will be a single encapsulation protocol at the &quot;ser= vice 
> layer&quot;.<br> Are<br> &gt; we saying that there could be more than 
> one way of carrying this heade= r but<br> &gt; that the contents would 
> be the same?<br> <br> </div>That is my interpretation.<br> <br> I.e., 
> this is an encapsulation that can be placed between the &quot;transpo= 
> rt&quot; (e.g.,<br> IP, MPLS, TCP, HTTP....) and the payload.<br> <div 
> class=3D"im"><br> &gt; Would the output of this WG would allow the 
> creation of a service chai= n even<br> &gt; when overlays are not in 
> use? =A0(This is not clear from reading the c= harter.)<br> <br> 
> </div>Well, erm, what is an &quot;overlay&quot;?<br> Isn&#39;t an 
> overlay just a network that happens to be running over another=  
> network?<br> Why would that need to be mentioned explicitly?<br> Why 
> would you assume it is ruled out if it is not mentioned?<br> <div 
> class=3D"im"><br> &gt; Finally, is the work intended to support chains 
> of both transparent an= d non-<br> &gt; transparent appliances, or is 
> the focus mainly on transparent applianc= es? =A0I<br> &gt; ask 
> because there may be interesting layering issues with respect to t= 
> he<br> &gt; placement of this header, especially if we have a 
> combination of trans= parent<br> &gt; and non-transparent 
> appliances.<br> <br> </div>That is probably a good question.<br> 
> Personally, I would like to put it &quot;for investigation.&quot; 
> I.e., I d= on&#39;t think we<br> know enough about the use cases and 
> requirements to answer your question at=  this<br> stage.<br> <br> But 
> if enough people show up on the list saying that they only want to 
> hand= le<br> one categorisation, then perhaps we can limit from day 
> one.<br> <br> Cheers,<br> Adrian<br> <br>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Sep 2013 16:44:41 +0100

I *think* the distinction being made is...

Does the packet follow the path it would have followed absent the imposition of
a service function? If so, the service function is applied transparently. If
not, the packet is somehow diverted (e.g. down a tunnel, by stealing the
destination address field, etc.) and the service function is applied
non-transparently.

If I am right in this, then I think it is not helpful to talk about transparent
or non-transparent services (or service functions), but how they are applied or
realised for a particular flow.

Adrian

> From: Ron Parker [mailto:[email-masked]]
> Sent: 25 September 2013 15:53
> To: Thomas Narten; Anoop Ghanwani
> Subject: RE: [nsc] transparent vs. non-transparent services [was Re: New NSC
> WG Charter - charter bullet #3]
> 
> Thomas, Anoop,
> 
> It strikes me that this transparency is not wrt to the originator or addressee
of the
> traffic, but rather between the SFC classifier and the SFC service nodes
(SNs).    In
> particular, whether an encapsulating "transport" header (e.g., IPv4/UDP) is
> applied in front of the NSC/SFC "service header" (which is in front of the
original
> packet), or not.
> 
> If an IP-layer encapsulation is applied, for example, the packets are
> routed/switched normally amongst the SFC classifier and SN's because the
> packets are explicitly IP addressed at each hop (given that the SN's would
need to
> change the destination IP in the encapsulating header to select the "next"
SN).
> However, if a "transport" header is not applied, policy-based
routing/switching
> would need to be used to steer the traffic in such a way that did not
necessarily
> conform to traditional routing/switching decisions.
> 
>    Ron
> 
> 
> I don't quite get this. To me, SFC is all about applying service functions to
traffic
> flows -- but in a way that is transparent to those traffic flows and the end
points
> originating them. That is, "applications" generating traffic aren't generally
aware
> of these service functions and they aren't really asking for them. They are
applied
> as the result of network policy/operations, not because the applications need
> them (for correctness). E.g., load balancing and firewalls.  Those sorts of
things
> are applied by network operators whether the applications want them or not. So
> the kinds of service functions this group is interested in are in some sense
by
> definition "transparent" to applications.
> 
> -- that is what I mean by "application" above. These are the components of the
> overall service that are doing the work, i.e., the DB, the application server,
etc.
> They are *NOT* service functions, in my mind.]
> 
> Service functions aren't going to be addressed by the traffic - traffic is
between
> the "applications", i.e., the end points of a service chain.
> 
> Today, service functions are deployed along the path between applications --
> because that is how we know how to do it. Going forward, we don't want to
> *require* that anymore.
> 
> "transparent" because they are not explicitely addressed by the traffic flows
and
> are in fact transparent to the applications.
> 
> Thomas
> 
> 
> 
> > Anoop
>

---

From: David Allan I <[email-masked]>
Date: Wed, 25 Sep 2013 16:20:48 +0000

I'm not a fan of encapsulating the frame in a database before forwarding....

I understand Joel's use case of carrying the subscriber ID (assuming the entire frame presented to a BNG is not preserved), and the need for a chain ID as a forwarding "helper". These two items strike me as both "necessary and sufficient".

Cheers
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 24, 2013 8:18 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

	--Tom

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 25 Sep 2013 17:06:43 +0000

Hi,

I think there's a further nuance, at least in the service world that is different separate from native path vs. diversion/steering discussion.  A transparent service acts a "bump in the wire", the most common example.  A non-transparent service terminates the traffic (e.g. the original TCP session), performs some action, then forwards the traffic via a new connection or mimicking the original one.

Thanks
Paul

---

From: Ron Parker <[email-masked]>
Date: Wed, 25 Sep 2013 17:18:50 +0000

So is the definition of transparent -- packets are unchanged (headers, content, etc.) and routing/switching path is unaltered?   Or is it just the former?   The mere diversion to a service node would seem to constitute "routing/switching is altered". 

   Ron

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2013 1:07 PM
To: <[email-masked]>
Cc: Ron Parker; Thomas Narten; Anoop Ghanwani; <[email-masked]>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

Hi,

Thanks
Paul

On Sep 25, 2013, at 8:44 AM, Adrian Farrel <[email-masked]> wrote:

> Does the packet follow the path it would have followed absent the 
> imposition of a service function? If so, the service function is 
> applied transparently. If not, the packet is somehow diverted (e.g. 
> down a tunnel, by stealing the destination address field, etc.) and 
> the service function is applied non-transparently.
> 
> If I am right in this, then I think it is not helpful to talk about 
> transparent or non-transparent services (or service functions), but 
> how they are applied or realised for a particular flow.
> 
> Adrian
> 
>> Subject: RE: [nsc] transparent vs. non-transparent services [was Re: 
>> New NSC WG Charter - charter bullet #3]
>> 
>> Thomas, Anoop,
>> 
>> particular, whether an encapsulating "transport" header (e.g., 
>> IPv4/UDP) is applied in front of the NSC/SFC "service header" (which 
>> is in front of the
> original
>> packet), or not.
>> 
>> routed/switched normally amongst the SFC classifier and SN's because 
>> the packets are explicitly IP addressed at each hop (given that the 
>> SN's would
> need to
>> functions to
>> as the result of network policy/operations, not because the 
>> firewalls.  Those sorts of
> things
>> are applied by network operators whether the applications want them 
>> or not. So the kinds of service functions this group is interested in 
>> are in some sense
> by
>> DB, the application server,
> etc.
>> traffic is
>> traffic flows
>>> interpretation.<br><br>I.e., this is an encapsulation that can be 
>>> pla= ced between the &quot;transport&quot; (e.g.,<br>IP, MPLS, TCP,
>>> </div><div>Well, erm, what is an &quot;overlay&quot;?<br>Isn&#39;t 
>>> an overl= ay just a network that happens to be running over another 
>>> enough about the use cases and requirements = to answer your 
>>> question at this<br> stage.<br><br>But if enough people show up on 
>>> the list saying that they onl= y want to handle<br>one 
>>> categorisation, then perhaps we can limit from day = one.<br><div 
>>> class=3D"gmail_extra">&gt;&gt;&gt;</div><div class=3D"gmail_ex= 
>>> tra"> <br></div><div class=3D"gmail_extra">I think it would make 
>>> sense to add som= ething explicit to the charter about 
>>> this.</div><div class=3D"gmail_extra">= <br></div><div 
>>> class=3D"gmail_extra">Since I have been asked the question o= 
>>> ffline, I will go ahead and explain what I mean by transparent vs 
>>> non-trans= parent appliances. =A0With a non-transparent appliance, 
>>> the appliance appea= rs as a &quot;router&quot; in the path of the 
>>> data. =A0As far as I&#39;m aw= are this is how load balancers are 
>>> deployed and this is how firewalls are c= ommonly deployed. =A0In 
>>> the non-transparent case, the address of the applia= nce does not 
>>> appear in the packet; instead packets are diverted to the appl= 
>>> iance using PBR. =A0This used sometimes for IDS/IPS type 
>>> appliances.</div> <div class=3D"gmail_extra"><br></div><div
>>> left-width:1px;border-left-color:rgb(204,204,204);border-left-style:
>>> so
>>> lid;p=
>>> service function path<br> &gt;&gt;&gt;<br> &gt;<br> &gt; is that 
>>> there will be a single encapsulation protocol at the &quot;ser= vice 
>>> layer&quot;.<br> Are<br> &gt; we saying that there could be more 
>>> than one way of carrying this heade= r but<br> &gt; that the 
>>> contents would be the same?<br> <br> </div>That is my 
>>> interpretation.<br> <br> I.e., this is an encapsulation that can be 
>>> placed between the &quot;transpo= rt&quot; (e.g.,<br> IP, MPLS, TCP, 
>>> HTTP....) and the payload.<br> <div class=3D"im"><br> &gt; Would the 
>>> output of this WG would allow the creation of a service chai= n 
>>> even<br> &gt; when overlays are not in use? =A0(This is not clear 
>>> from reading the c= harter.)<br> <br> </div>Well, erm, what is an 
>>> &quot;overlay&quot;?<br> Isn&#39;t an overlay just a network that 
>>> happens to be running over another= network?<br> Why would that need 
>>> to be mentioned explicitly?<br> Why would you assume it is ruled out 
>>> if it is not mentioned?<br> <div class=3D"im"><br> &gt; Finally, is 
>>> the work intended to support chains of both transparent an= d 
>>> non-<br> &gt; transparent appliances, or is the focus mainly on 
>>> transparent applianc= es? =A0I<br> &gt; ask because there may be 
>>> interesting layering issues with respect to t= he<br> &gt; placement 
>>> of this header, especially if we have a combination of trans= 
>>> parent<br> &gt; and non-transparent appliances.<br> <br> </div>That 
>>> is probably a good question.<br> Personally, I would like to put it 
>>> &quot;for investigation.&quot; I.e., I d= on&#39;t think we<br> know 
>>> enough about the use cases and requirements to answer your question 
>>> at=  this<br> stage.<br> <br> But if enough people show up on the 
>>> list saying that they only want to hand= le<br> one categorisation, 
>>> then perhaps we can limit from day one.<br> <br> Cheers,<br> 
>>> Adrian<br> <br> </blockquote></div><br></div></div></div>
>>

---

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

Ron,

> So is the definition of transparent -- packets are unchanged
> (headers, content, etc.) and routing/switching path is unaltered?
> Or is it just the former?  The mere diversion to a service node
> would seem to constitute "routing/switching is altered".

I think the point is we don't exactly have an agreed to defintion of
"transparent" in the NSC context, so it's not particularly helpful to
use it in describing NSC behavior without being clear about what is
meant.

For services in NSC, packets clearly will get modified in some cases
(e.g. NAT or proxies) but won't in others. So distinguishing types of
services by how much they change the packets they inspect is probably
not helpful for NSC. NSC doesn't really care *what* the services does,
just that the service exists and packets need to be steered to travel
through the service.

Thomas

---

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

In practice it is the latter, since those are the detectable alterations.  

While the state of the forwarding table is dynamic and subject to change in packet switched networks, the state of the headers of the packets on those networks are typically static unless they are specifically altered per-hop, so in the context of traffic steering, and by extension, steering that traffic into a service chain, if the headers aren't modified in an unusual manner for a particular OSI layer, that steering is deemed "transparent" because the traffic steering isn't detectable by peers/endpoints at that layer of the OSI.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Ron Parker [[email-masked]]
Sent: Wednesday, September 25, 2013 1:18 PM
To: Paul Quinn (paulq); <[email-masked]>
Cc: Thomas Narten; <[email-masked]>; Anoop Ghanwani
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New        NSC     WG      Charter - charter bullet #3]

   Ron

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Wednesday, September 25, 2013 1:07 PM
To: <[email-masked]>
Cc: Ron Parker; Thomas Narten; Anoop Ghanwani; <[email-masked]>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

Hi,

Thanks
Paul

---

From: Ron Parker <[email-masked]>
Date: Wed, 25 Sep 2013 17:27:04 +0000

I agree with Dave that subscriber ID and those fields necessary to complete the chain forwarding (may or may not end up being a simple chain id) are the most important metadata.   However, there may be other interesting fields to consider such as location of the subscriber (e.g., cell id  in a 3gpp network).   

But other less universally useful fields may prove too troublesome to incorporate.   Take DPI conclusions as a counter example.   How are they described?   Where is the central registry of known protocols/applications and the strings and/or integers used to identify them?   It would be an ongoing battle to try to communicate DPI conclusions between SF's in such a way that all could agree on the interpretation.

Thanks.

    Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, September 25, 2013 12:21 PM
To: Jerome Moisand; Thomas Nadeau; Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Cheers
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 24, 2013 8:18 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

	--Tom

---

From: Ron Parker <[email-masked]>
Date: Wed, 25 Sep 2013 17:28:30 +0000

Thomas,

I agree that the notion of transparent service is not necessary to incorporate in our work.

   Ron

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <[email-masked]>; Anoop Ghanwani; <[email-masked]>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

Ron,

> So is the definition of transparent -- packets are unchanged (headers, 
> content, etc.) and routing/switching path is unaltered?
> Or is it just the former?  The mere diversion to a service node would 
> seem to constitute "routing/switching is altered".

I think the point is we don't exactly have an agreed to defintion of "transparent" in the NSC context, so it's not particularly helpful to use it in describing NSC behavior without being clear about what is meant.

For services in NSC, packets clearly will get modified in some cases (e.g. NAT or proxies) but won't in others. So distinguishing types of services by how much they change the packets they inspect is probably not helpful for NSC. NSC doesn't really care *what* the services does, just that the service exists and packets need to be steered to travel through the service.

Thomas

---

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

This seems like an implementation detail.  That said, this is also a problem that has been solved a number of times, so we probably don't need to re-invent the when it does come time to address which meta data gets generated, how it is formatted or encoded, and how to communicate it to the nodes that need to know it.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Ron Parker [[email-masked]]
Sent: Wednesday, September 25, 2013 1:27 PM
To: David Allan I; Jerome Moisand; Thomas Nadeau; Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Thanks.

    Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, September 25, 2013 12:21 PM
To: Jerome Moisand; Thomas Nadeau; Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 24, 2013 8:18 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

        --Tom

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 25 Sep 2013 11:10:49 -0700

When I mentioned transparent/non-transparent, I meant that there was some
change in the packet headers (whether at the IP, MAC, or TCP layers) for
packets that were going to be subject to the service in question, in the
non-transparent case.  In other words, for the transparent case, I cannot
tell by looking at the packet headers whether or not the packet would be
subject to that service.  Clearly, there are others who think
transparent/non-transparent mean something else.  And that's just simply
because there is not standard terminology, which perhaps the WG can help
define.

I think this also plays into where in the packet the NSC header goes, and
whether there can be multiple instances of the NSC header in the packet.

If a certain layer's header is terminated at a service box, it would be a
layering violation to carry the NSC header beyond that point.

For instance, if the NSC header is located between the MAC and IP header,
and the packet hits a load balancer that changes the IP & MAC headers, that
device would need to create a new NSC header.

It may be that as Thomas says, we are not going to worry about
non-transparent appliances at all, but then I'm not sure how we even
implement something like a load balancer.

Finally, I do think the problem statement needs a lot of work before we get
to solutions.  I think it would be useful to state somewhere in the charter
that solutions would only be considered after the problem statement is in a
reasonable shape and the WG participants are in agreement about what needs
to be solved.

Anoop

On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker <
[email-masked]> wrote:

> "transparent" in the NSC context, so it's not particularly helpful to use
> it in describing NSC behavior without being clear about what is meant.
>
> For services in NSC, packets clearly will get modified in some cases (e.g.
> NAT or proxies) but won't in others. So distinguishing types of services by
> how much they change the packets they inspect is probably not helpful for
> NSC. NSC doesn't really care *what* the services does, just that the
> service exists and packets need to be steered to travel through the service.
>
> Thomas
>
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 25 Sep 2013 20:21:19 +0000

Hi Ron,

Using the definition I suggested below, the difference between transparent and not center around termination.  In either case, the service may, or may not alter the original packets.  Only a non-transarant service, will for example, open new connections in response to the original session.  A good example is a server load balancer: it can terminate incoming TCP session, inspect traffic, then open new sessions.   To the end user, the service isn't visible.

Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 25 Sep 2013 20:22:17 +0000

I agree, the problem, architecture and associated solutions should be applicable in either (any?) case.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 25 Sep 2013 20:31:49 +0000

Ron,

As you point out a central registry isn't really viable for all solutions.  In many environments, the "controller" will provide meaning for the context headers.

Thanks
Paul

---

From: "Pham, Chuong D" <[email-masked]>
Date: Thu, 26 Sep 2013 09:19:41 +1000

Another example is in the case of Header Enrichment (HE) service in a Mobile network. A HE function inserts information elements into HTTP header. What to insert is dependent on the identification of the users i.e. the MSISDN. Today, IP packets arriving at the HE function do not contain such non-IP-address user identification.

Other value-added-services such as Parental Control and certain flavours of Video Optimisation also require such user identification.

If the "cost" of carrying this user identification in metadata is justified, I see great opportunity, especially for Mobile operators (and Fixed in the case of Fixed Mobile Convergence (FMC)).

Regards,
Chuong

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Wednesday, 25 September 2013 10:07 PM
To: Joel M. Halpern
Cc: [email-masked]; [email-masked]; Linda Dunbar
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Thanks,

-- Carlos.

On Sep 25, 2013, at 3:23 AM, Joel M. Halpern <[email-masked]> wrote:

>>> I think "metadata" is a particularly poor term to use here because 
>>> it actually directly means "additional data attached to something 
>>> We should also look at what you mean by out-of-band. I think here 
>>> you mean "using some information exchange protocol."
>> 
>>> | framework for service function chaining and the necessary 
>>> | protocols or protocol extensions to convey the service path and 
>>> | for communication between nodes that implement service functions
>>> 
>>> and:
>>>

---

From: "Pham, Chuong D" <[email-masked]>
Date: Thu, 26 Sep 2013 09:42:02 +1000

I agree with Ron that cell id is another very good example of interesting fields in metadata for Mobile operators. 
Regards,
Chuong

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, 26 September 2013 3:27 AM
To: David Allan I; Jerome Moisand; Thomas Nadeau; Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Thanks.

    Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, September 25, 2013 12:21 PM
To: Jerome Moisand; Thomas Nadeau; Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Cheers
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 24, 2013 8:18 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

	--Tom

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 25 Sep 2013 18:59:38 -0700

>>It may be that as Thomas says, we are not going to worry about non-transparent appliances at all, but then I'm not sure how we even implement something like a load balancer.

>> Finally, I do think the problem statement needs a lot of work before we get to solutions.  I think it would be useful to state somewhere in the charter that solutions would only be considered after the problem statement is in a reasonable shape and the WG participants are in agreement about what needs to be solved.

Agree with Anoop. We do need to clarify this aspect in the problem statement.

Thanks,
Ramki

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Wednesday, September 25, 2013 11:11 AM
To: Ron Parker
Cc: Thomas Narten; <[email-masked]>; Paul Quinn (paulq); <[email-masked]>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

When I mentioned transparent/non-transparent, I meant that there was some change in the packet headers (whether at the IP, MAC, or TCP layers) for packets that were going to be subject to the service in question, in the non-transparent case.  In other words, for the transparent case, I cannot tell by looking at the packet headers whether or not the packet would be subject to that service.  Clearly, there are others who think transparent/non-transparent mean something else.  And that's just simply because there is not standard terminology, which perhaps the WG can help define.

I think this also plays into where in the packet the NSC header goes, and whether there can be multiple instances of the NSC header in the packet.

If a certain layer's header is terminated at a service box, it would be a layering violation to carry the NSC header beyond that point.

For instance, if the NSC header is located between the MAC and IP header, and the packet hits a load balancer that changes the IP & MAC headers, that device would need to create a new NSC header.

It may be that as Thomas says, we are not going to worry about non-transparent appliances at all, but then I'm not sure how we even implement something like a load balancer.

Finally, I do think the problem statement needs a lot of work before we get to solutions.  I think it would be useful to state somewhere in the charter that solutions would only be considered after the problem statement is in a reasonable shape and the WG participants are in agreement about what needs to be solved.

Anoop

On Wed, Sep 25, 2013 at 10:28 AM, Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

   Ron

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <[email-masked]<mailto:[email-masked]>>; Anoop Ghanwani; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]
Ron,

Thomas

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 26 Sep 2013 15:10:07 +0000

Hi Anoop, Ramki,

Great to see that you both have read the problem statement!  Let's make this constructive: we'd love to see your detailed comments.  Please send them to the list, and/or the draft authors and we'll review them.

Paul

Thanks,
Ramki

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Anoop Ghanwani
Sent: Wednesday, September 25, 2013 11:11 AM
To: Ron Parker
Cc: Thomas Narten; <[email-masked]<mailto:[email-masked]>>; Paul Quinn (paulq); <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

Anoop

   Ron

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <[email-masked]<mailto:[email-masked]>>; Anoop Ghanwani; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]
Ron,

Thomas

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 26 Sep 2013 10:47:07 -0700

Hi Paul,

The two big issues are the ones that I already alluded to.

First, it would be good to have more clarity around transparent vs
non-transparent appliances (otherwise you have folks like Thomas who think
it only applies to transparent appliances, and folks like me who wonder how
non-transparent appliances are supposed to work with this).

The second issue is around multiple layers of overlays.  There is reference
to metadata, yet it is not clear if metadata must appear multiple times in
the frame if the service is applied at L2 vs L3 vs L4.

I can't see how the document can deal with this without getting into some
specific examples.

A relatively minor thing would be better clarify around overlays.  Normally
when I think of overlays, I think tunnels, not regular layering.  But it
seems like Adrian, for example, has a differing view.  The document should
clarify what it really means by network overlay by giving some examples.

The way the document is currently written captures the problem well, but at
a very high-level.  It is easy to get a gist of what's going on, but it
leaves a lot of room for interpretation as to the scope of the problem
being tackled.

Anoop

On Thu, Sep 26, 2013 at 8:10 AM, Paul Quinn (paulq) <[email-masked]> wrote:

>  Hi Anoop, Ramki,
>
>  Great to see that you both have read the problem statement!  Let's make
> this constructive: we'd love to see your detailed comments.  Please send
> them to the list, and/or the draft authors and we'll review them.
>
>  Paul
>
>  On Sep 25, 2013, at 6:59 PM, ramki Krishnan <[email-masked]>
>  wrote:
>
> implement something like a load balancer.****
>
>  >> Finally, I do think the problem statement needs a lot of work before
> we get to solutions.  I think it would be useful to state somewhere in the
> charter that solutions would only be considered after the problem statement
> is in a reasonable shape and the WG participants are in agreement about
> what needs to be solved.****
>
>  Agree with Anoop. We do need to clarify this aspect in the problem
> statement.****
>
>  Thanks,****
>  Ramki****
>
>  *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Anoop Ghanwani
> *Sent:* Wednesday, September 25, 2013 11:11 AM
> *To:* Ron Parker
> *Cc:* Thomas Narten; <[email-masked]>; Paul Quinn (paulq); <
> [email-masked]>
> *Subject:* Re: [nsc] transparent vs. non-transparent services [was Re:
> New NSC WG Charter - charter bullet #3]****
>  ** **
>   When I mentioned transparent/non-transparent, I meant that there was
> some change in the packet headers (whether at the IP, MAC, or TCP layers)
> for packets that were going to be subject to the service in question, in
> the non-transparent case.  In other words, for the transparent case, I
> cannot tell by looking at the packet headers whether or not the packet
> would be subject to that service.  Clearly, there are others who think
> define.****
>  I think this also plays into where in the packet the NSC header goes,
> and whether there can be multiple instances of the NSC header in the packet.
> ****
>  ** **
>   If a certain layer's header is terminated at a service box, it would be
> a layering violation to carry the NSC header beyond that point.****
>   ** **
>   For instance, if the NSC header is located between the MAC and IP
> header, and the packet hits a load balancer that changes the IP & MAC
> headers, that device would need to create a new NSC header.****
>   ** **
> implement something like a load balancer.****
>   ** **
>   Finally, I do think the problem statement needs a lot of work before we
> get to solutions.  I think it would be useful to state somewhere in the
> charter that solutions would only be considered after the problem statement
> is in a reasonable shape and the WG participants are in agreement about
> what needs to be solved.****
>   ** **
>   Anoop****
>
> ** **
> [email-masked]> wrote:****
>  Thomas,
>
>    Ron****
> Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New
> NSC WG Charter - charter bullet #3]****
>
> Ron,
>
> Thomas****

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 26 Sep 2013 22:04:09 +0000

Chuong, 

Thanks for the examples. 

Some questions are inserted below: 

> Another example is in the case of Header Enrichment (HE) service in a
> Mobile network. A HE function inserts information elements into HTTP
> header. What to insert is dependent on the identification of the users
> i.e. the MSISDN. Today, IP packets arriving at the HE function do not
> contain such non-IP-address user identification.

[Linda] "The Header Enrichment service" insert bits to existing HTTP header of the packets, correct? I've seen other network function modules (or even BNG) add/change bits to HTTP header to carry information to downstream nodes. I hope that this kind of encoding bits/fields to existing header should be acknowledged as a way to carry "Metadata" by the NSC charter. 

> If the "cost" of carrying this user identification in metadata is
> justified, I see great opportunity, especially for Mobile operators
> (and Fixed in the case of Fixed Mobile Convergence (FMC)).

[Linda] The "HE" example you give earlier doesn't require new Metadata header. Do you have any examples to show adding/encoding bits to existing header (HTTP, TCP, or IP header) is not enough?

> Another typical example is to use metadata to share the result of
> ingress classification, or network information (as e.g., to be used in
> subscriber identification) to then be used for policy in a service
> function downstream the service path. One such example is VRF
> information.
> 
> Thanks,
> 
> -- Carlos.
> 
> > For me, the canonical example of metadata applies to the use case of
> a service chain providing residential gateway functionality with
> network resident NAT.
> > I have also seen cases where DPI service engines are separate
> entities in the chain from services which need the results of the DPI.
> That seems a natural candidate for metadata.
> >
> > Yours,
> > Joel
> >
> >> "Metadata" has been used extensively in the NSC context. But beyond
> the "service chain ID", I can't find any other necessary information
> required to be exchanged among the "Service Functions" in all the use
> cases presented at the Berlin informal BoF and use cases drafts. Can
> anyone give some examples of the information required to be exchanged
> among those "Service Functions" given by the draft-quinn-nsc-arch-00?
> >>
> >> [Linda] Since each Service-Chain ID represents a list of service
> functions, it is possible to use "out-of-band" control channel to pass
> the information on the sequence of Service Functions associated with
> the ID.
> >>
> >>
> >>>
> >>> The charter says:
> >>>
> new

---

From: "Pham, Chuong D" <[email-masked]>
Date: Fri, 27 Sep 2013 10:06:45 +1000

Hi Linda,
Please see my responses inline below.
Regards,
Chuong

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Friday, 27 September 2013 8:04 AM
To: Pham, Chuong D; Carlos Pignataro (cpignata); Joel M. Halpern
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] New NSC WG Charter - charter bullet #3

Chuong, 

Thanks for the examples. 

[Linda] "The Header Enrichment service" insert bits to existing HTTP header of the packets, correct? I've seen other network function modules (or even BNG) add/change bits to HTTP header to carry information to downstream nodes. I hope that this kind of encoding bits/fields to existing header should be acknowledged as a way to carry "Metadata" by the NSC charter. 
[Chuong] Header Enrichment service (HE) is considered a value-added-service (VAS) in our Mobile network and I believe this is also the case for many other Mobile Operators. Traffic is steered to HE (using some non-SDN, non-NSC methods today - We hope NSC will help us with this). The HE only sees the source/destination IP addresses (plus other TCP/HTTP layer information like port numbers etc). From the IP packet alone, the HE cannot identify a Mobile users. Now, why does the HE need to identify the Mobile users? one example of the kind of VAS a HE offers is inserting a MSISDN (aka the Mobile phone number) into the HTTP header so that the traffic is recognised at the server end (i.e. a Web site owner, owned by us, or our partners) as belonging to one of our Mobile subscribers. With this knowledge, the server end can apply certain actions such as authorising the customers to access certain services via the Web site (without requiring the users to go through User-Name/Password based authentication which is a turn-off of Mobile users with small screens and handsets. One example of the services is a Usage Meter which reports on the user's data usage to date. How can the HE know which user (and the MSISDN) the IP packets/flows belong to so that the HE can insert the correct MSISDN? Today, we relying on sending Radius Accounting (RA) messages to the HE. RA has attributes which include the IP address dynamically assigned to a user and the MSISDN belong to this user. Today the HE has to receive Radius Accounting and maintain this database at all time. If the HE receives the MSISDN in the metadata inserted by the first classification node in NSC, then it does not have to maintain that database. Moreover, downstream to HE, we may want to apply a Parental Control server aka a Content Filtering (CF) service, where the CF also needs to know the MSISDN owning the IP packets. This is because different users require/subscribe-to different CF policies. Today in our network, again, we duplicate what we have for HE and send Radius Accounting to CF and make the CF to maintain the data base as well. Hopefully, we now can see that if metadata contains the MSISDN, then the HE and CF do not have to maintain their own databases to correlate IP packets with users. HE and CF are what we currently have. I could extend this example to future services such as Personal-Firewall, Malware-Detection, Video-Optimisation etc., where different user requires different policies, hence the need to identify users of IP packets.     

[Linda] The "HE" example you give earlier doesn't require new Metadata header. Do you have any examples to show adding/encoding bits to existing header (HTTP, TCP, or IP header) is not enough?
[Chuong] See above. If it's still not clear, I will be happy to discuss further. 

> addresses across subscribers, then some field is needed to identify 
> the subscriber in the service chain.
> >> load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID 
> >>> | developed to describe requirements and protocols necessary to 
> >>> | convey information to service function implementation points. 
> >>> | Where possible, existing IETF protocols will be used and extended.
> >>>

---

From: ramki Krishnan <[email-masked]>
Date: Thu, 26 Sep 2013 19:31:58 -0700

Hi Paul,

I think the following topics should be addressed in the problem statement to add more clarity.

1)      Interaction between state migration, for example VM migration, and service function chaining.

2)      Fast path offload and service function chaining interaction; for example, a load balancer/security appliance may send a request to offload a long-lived large flow to the switch/router.

If you like, I can send more text on these topics.

Thanks,
Ramki

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Thursday, September 26, 2013 10:47 AM
To: Paul Quinn (paulq)
Cc: ramki Krishnan; [email-masked]
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

Hi Paul,

First, it would be good to have more clarity around transparent vs non-transparent appliances (otherwise you have folks like Thomas who think it only applies to transparent appliances, and folks like me who wonder how non-transparent appliances are supposed to work with this).

The second issue is around multiple layers of overlays.  There is reference to metadata, yet it is not clear if metadata must appear multiple times in the frame if the service is applied at L2 vs L3 vs L4.

I can't see how the document can deal with this without getting into some specific examples.

A relatively minor thing would be better clarify around overlays.  Normally when I think of overlays, I think tunnels, not regular layering.  But it seems like Adrian, for example, has a differing view.  The document should clarify what it really means by network overlay by giving some examples.

The way the document is currently written captures the problem well, but at a very high-level.  It is easy to get a gist of what's going on, but it leaves a lot of room for interpretation as to the scope of the problem being tackled.

Anoop

On Thu, Sep 26, 2013 at 8:10 AM, Paul Quinn (paulq) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Anoop, Ramki,

Paul

Thanks,
Ramki

From: [email-masked]<mailto:[email-masked]> [mailto:nsc-<mailto:nsc->[email-masked]<mailto:[email-masked]>] On Behalf Of Anoop Ghanwani
Sent: Wednesday, September 25, 2013 11:11 AM
To: Ron Parker
Cc: Thomas Narten; <[email-masked]<mailto:[email-masked]>>; Paul Quinn (paulq); <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]

Anoop

   Ron

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 25, 2013 1:24 PM
To: Ron Parker
Cc: Paul Quinn (paulq); <[email-masked]<mailto:[email-masked]>>; Anoop Ghanwani; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] transparent vs. non-transparent services [was Re: New NSC WG Charter - charter bullet #3]
Ron,

Thomas