Subject: [nsc] What is a service? Why is NSC not SC?

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Jun 2013 12:23:17 +0100

Hi,

I know this cuts into use cases, but I think it will turn out to be important
for clarity and scope.

There is a risk that "we all know what we mean", but that no-one clearly
articulates what "network service chaining" is. (It is a little like NFV where
the definition also seems to be hard to pin down.)

I don't want to rat-hole too much on definitions, but it would help if we can
draw some lines. When is "service chaining" not "network service chaining"?

Thanks,
Adrian

---

From: <[email-masked]>
Date: Thu, 20 Jun 2013 14:00:14 +0200

Hi Adrian, 

You raised a good point. 

I do think the use of "service" and even "network service" will induce confusion. "service" is an overloaded term which does not have the same signification for network engineers, application designs, marketing people, etc. 

In addition, "service" is already a packaging of several functions. It may implicitly require the invocation of various functions and the combinations of multiple actions involving several (network) nodes. This is for instance the notion of service as defined in RFC 2474.

For those reasons, I would suggest the use of:
* a non-overloaded term
* a more neutral term which can suit various use cases of interest of this group

As an alternative, I'm proposing the use of NLF (Network-Located Function). A proposed definition for NLF is provided below:

   o  NLF (Network-Located Function): refers to a function which is
      enabled in the network operated by an administrative entity.  NLF
      can be for example: firewall (e.g., [RFC6092]), DPI (Deep Packet
      Inspection), LI (Lawful Intercept) module, NAT44 [RFC3022], NAT64
      [RFC6146], DS-Lite AFTR [RFC6333], NPTv6 [RFC6296], HOST_ID
      injection, HTTP Header Enrichment function, TCP optimizer, etc. 

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Adrian Farrel
>Envoyé : jeudi 20 juin 2013 13:23
>À : [email-masked]
>Objet : [nsc] What is a service? Why is NSC not SC?
>
>Hi,
>
>_______________________________________________
>nsc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nsc

---

From: Ken Gray <[email-masked]>
Date: Thu, 20 Jun 2013 12:54:56 +0000

To me, if you are trying to make distinctions, I think its all in focus.  We're concerned with how the datagram gets from point A to point B, where A and B may be described as a service element (i think Jim's SEP terminology is apt here) and that element may require either an imbedded or orchestrated clue/context (as required by a more global concept of service that may encompass many elements.

That delivery may be constrained by a number of network-related factors that require the application of policy, knowledge of aspects of topology, and continual monitoring/maintenance of those factors.

So, the "network" focus is that delivery.

Or to define in negatives, its not concerned with the decomposition of the service or element, the optimization of the service platform or best practices in creating, maintaining or administering a service (except for the areas that ultimately end up manipulating the datagram itself or the forwarding logic of the element (eg the interface with orchestration).

I know that spitball is incomplete.  I don't think we need another way to say "service" but should focus on the "network" component.

Sent from my iPhone

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Jun 2013 15:26:57 +0100

Thanks to Ken and Med for replies.

Choosing to respond on Med's thread because he gave...

>       injection, HTTP Header Enrichment function, TCP optimizer, etc.

Something I pick out of this is that all the example functions are
packet-oriented functions (or possibly flow-oriented) and not application layer
services. I think this is significant and not accidental :-)

Can we capture that idea in a definition?

I note that it is hinted at in Paul and Jim's BoF proposal text and it is there
because I asked them why this proposal was aimed at the Routing Area not the
Applications Area. To which the answer was "because we want to steer packets or
flows to the place where the next service will be applied."

Adrian

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 20 Jun 2013 14:59:34 +0000

Hi Adrian, 

>From my perspective "service" is an overloaded term, so we attempted to
bound the concept of service.  Depending on perspective a service could be
an individual vertical service such as a financial or sales application, a
transit service such as network security or IP connectivity, a service
providing compute or storage resources, a network-based service such as a
firewall, a particular piece of content such as a video stream, or some
combination of all of these.

By adding the term network, we imply that we are focused on functions that
are linked via the network, and have network-relevant attributes (e.g.
network location).  In addition to this some services will require
metadata and some will not; for those that do we need a way to pass said
metadata between service instances and this is where additional mechanisms
above and beyond "service routing" come into play such as proposed in
draft-quinn-nsh-00.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 20 Jun 2013 11:20:41 -0400

Personally, I think the term "service" is OK. Yes, it's somewhat
overloaded, but almost any term we use will be. But we do need to
define what we mean by the term

That said ...

> combination of all of these.

This is the general notion of a service, but I think its too broad for
NSC.

Don't we really only care about services where the actual source &
destination of the traffic are: 1) unaware that the service is being
applied and 2) do not address that service explicitely? I.e., what we
usually think of as middleboxes?

Because end points don't address them, normal packet forwarding
doesn't ensure traffic always goes through the "service". And NSC is
all about being able to describe the existance of such services and
having mechanisms that ensure all traffic (as defined by flows/policy)
flows through the services that are required to be applied.

So, NSC is needed to force traffic flows to properly traverse
middlebox "services". But NSC  is not needed to have traffic
delivered to say, a storage controller. Right?

Thomas

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 20 Jun 2013 12:37:54 -0400

Hi, Adrian.

On 2013-06-20 10:26 AM, Adrian Farrel wrote:
> packet-oriented functions (or possibly flow-oriented) and not 
> application layer services. I think this is significant and not 
> accidental :-) Can we capture that idea in a definition?

We do need to agree on what a "network service" is, as distinguished 
from non-network services. I suspect that some people intuitively lump 
together many things as network services, that should really be further 
divided into "Endpoint Network Services" and "Inline Network Services". 
(Hopefully somebody can come up with better category names; I'm just 
trying to make the general point.)

For example, DNS and DHCP could be examples of Endpoint Network 
Services, while Firewall or NAT could be examples of Inline Network 
Services. The key difference, as both you and Thomas Narten have pointed 
out, is whether packets/flows are terminating (at the Endpoint) or being 
forwarded (through the Inline service).

Since we're focused on Service Chaining, this group needs to investigate 
how packets/flows are routed through Inline Network Services. It seems 
pretty obvious that we already have the means to get packets to the 
correct endpoint, and so I assume Endpoint Network Services are out of 
scope when we talk about "Network Services" here. (But, of course, 
somebody could convince me otherwise.)

I'm hesitant to categorize based on whether something works at the 
"application layer", because I can imagine Inline Network Services that 
do so yet still need Service Chaining routing etc.

Cheers,
-Benson

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 20 Jun 2013 12:39:42 -0400

> define what we mean by the term

I don't think it really matters if we call it a "service" or "function" 
- either term is broad enough. But personally I like the term "service". 
In my mind at least, there could be a subtle distinction between a 
"service" and a "function" in that the word "function" could describe a 
lower-level capability, whereas the word "service" describes something 
more complete. E.g. multiple functions might come together to provide a 
service (implying that "functions" are internal aspects whereas 
"services" are atomic things)

But that's just my leaning; I don't think I can defend this as _the_ 
correct definition. And frankly, this group may choose to work at a 
level of granularity that reaches down to the "function" as I've 
described it.

Cheers,
-Benson

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 20 Jun 2013 16:50:23 +0000

Hi Benson,

One of the reasons why I refer to them as "service functions" ;-)

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 20 Jun 2013 17:23:00 +0000

Hi Adrian,

>services. I think this is significant and not accidental :-)

Jim> actually the intent was that both packet-oriented and application
layer service functions are within scope. It is certainly possible to
envisage service chains that incorporate both of these types of functions
and we should not restrict our work to one or the other but rather let the
use cases dictate.

---

From: Paul Quinn <[email-masked]>
Date: Thu, 20 Jun 2013 11:04:04 -0700

Hi Benson,

On Jun 20, 2013, at 9:37 AM, Benson Schliesser <[email-masked]> wrote:

>> Something I pick out of this is that all the example functions are packet-oriented functions (or possibly flow-oriented) and not application layer services. I think this is significant and not accidental :-) Can we capture that idea in a definition?
> 
> We do need to agree on what a "network service" is, as distinguished from non-network services. I suspect that some people intuitively lump together many things as network services, that should really be further divided into "Endpoint Network Services" and "Inline Network Services". (Hopefully somebody can come up with better category names; I'm just trying to make the general point.)
> 
> For example, DNS and DHCP could be examples of Endpoint Network Services, while Firewall or NAT could be examples of Inline Network Services. The key difference, as both you and Thomas Narten have pointed out, is whether packets/flows are terminating (at the Endpoint) or being forwarded (through the Inline service).
> 

PQ>  Although that distinction is broadly true, I'm not sure we need to draw it out now.  A chain couple be composed of terminating and inline services and fall under the umbrella of network service chaining.  

> Since we're focused on Service Chaining, this group needs to investigate how packets/flows are routed through Inline Network Services. It seems pretty obvious that we already have the means to get packets to the correct endpoint, and so I assume Endpoint Network Services are out of scope when we talk about "Network Services" here. (But, of course, somebody could convince me otherwise.)
> 

PQ>  I think both are in scope:  a good example is the simple one of server load balancer (terminating) and a firewall (inline).

> I'm hesitant to categorize based on whether something works at the "application layer", because I can imagine Inline Network Services that do so yet still need Service Chaining routing etc.

PQ>  Agreed.

Paul

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 20 Jun 2013 20:59:54 +0000

Hi Thomas,

>usually think of as middleboxes?

Jim> yes. The application of the service function/s should be transparent
to the consumer of the service.
>flows through the services that are required to be applied.

Jim> yes but with the added twist that metadata might be inserted into the
traffic flow and be consumed by one or more service functions as it passes
through the chain. 

>delivered to say, a storage controller. Right?

Jim> correct.

---

From: <[email-masked]>
Date: Fri, 21 Jun 2013 09:00:48 +0200

Hi Adrian,

Please see inline.

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de Adrian
>Farrel
>Envoyé : jeudi 20 juin 2013 16:27
>À : [email-masked]
>Objet : Re: [nsc] What is a service? Why is NSC not SC?
>

 [Med] In fact the list includes both (e.g., HTTP Header Enrichment function)...but all these functions are involved in the delivery of connectivity services. 

>flows to the place where the next service will be applied."

[Med] IMHO, this is a cross-area topic between the Routing area and Internet Area. The core concern is still about how to provide differentiated forwarding but the technical realization would need some extensions which are more in the perimeter of the Internet Area (e.g., inject a piece of information in packets).

---

From: <[email-masked]>
Date: Fri, 21 Jun 2013 09:45:26 +0200

Hi Jim, all,

I would even say: these functions are seen as black-boxes and no assumption is to be made on the outcome of such functions. 

We tried to capture this and other assumptions in draft-boucadair-*

   o  NLFs are handled as black-boxes; the technical characterization of
      each NLF is not required.
   o  Not all NLFs can be characterized with a standard definition in
      terms of technical description, detailed specification, etc.
   o  There is no global nor standard list of NLFs enabled in a given
      administrative domain.  The set of NLFs varies on a per deployment
      basis.
   o  There is no global nor standard NLF chaining logic.  The ordered
      set of NLFs that need to be activated to deliver a given
      connectivity service is specific to each administrative entity.
   o  The chaining of NLFs and the criteria to invoke some of them are
      local to each administrative entity that operates a connectivity
      network (also called administrative domain).
   o  NLF chaining logic and related policies should not be exposed
      outside a given administrative domain.
   o  Several NLF chaining logics can be simultaneously enforced within
      an administrative domain to meet business requirements.

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de Jim
>Guichard (jguichar)
>Envoyé : jeudi 20 juin 2013 19:23
>À : [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Fri, 21 Jun 2013 10:01:37 +0200

Dear Benson,

Please see inline.
Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de Benson
>Schliesser
>Envoyé : jeudi 20 juin 2013 18:38
>À : [email-masked]
>Cc : [email-masked]

 [Med] This distinction is IMHO orthogonal to the chaining itself. You may envisage for both categories of services you listed, a need to invoke multiple sets of network-located functions to deliver a given *-Network Service. For instance, the set of functions to be invoked during network attachment phase would be distinct than the one to be followed once the network attachment is succeeded. In both cases, appropriate forwarding actions will need to be undertaken under some conditions. The important points IMHO are:
* these operations are about achieving differentiated forwarding
* actions to achieve this differentiated forwarded are enforced in the network side
* the functions to be invoked (together with the invocation logic) is policy-based and local to the network
* end user (devices) are not aware of the chaining logic.

All what is about is how to construct forwarding maps so the traffic will processed following policies local to a given network.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 23 Jun 2013 22:16:12 +0200

Hi Adrian,

Great question ! (Just catching up ...)

For me the definition is extremely simple ... Networks = services + transport.

So I somehow disagree with the notion of
draft-quinn-nsc-problem-statement that services are just data center
thing or that those are just firewalls, loadbalancers or worse carrier
grade NATs. For me services is anything BGP carries - that includes:
L3VPN regular PE, ASBR, L2VPNs, EVPNs, virtual hub PE, Internet, etc
...

Those with some history of L3VPNs recall very well the struggle to
chain firewalls on customer sites to make their VPN sites divided into
DMZ and secured planes.

And just to cut some comments short .. this is not boiling the ocean.
Very simply service marking can accomplish any service discovery and
chaining (ability for specific data patter to be forced to go via such
service node+context within that node).

Best,
R.

> On Thu, Jun 20, 2013 at 1:23 PM, Adrian Farrel <[email-masked]> wrote:
> Hi,
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 23 Jun 2013 22:58:27 +0000

Hi all,

Looking at this thread, combining the distinction between "function" and "service" provided by Benson, and the assumptions Med lists in what relates to how policy applies to them within an administrative domain, I am in favor of talking of functions that are combined (chained) to build services, at any recursion level: a service can be composed (chained) as a function to build a more complex service.

Probably the Solomonic proposal from Jim is the one making more sense...

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

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

________________________________

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 24 Jun 2013 11:59:51 +0000

Hi Robert,

>L3VPN regular PE, ASBR, L2VPNs, EVPNs, virtual hub PE, Internet, etc

Jim> the intent of draft-quinn-nsc-problem-statement is not to imply that
services are just for the data center, or that service chaining is only
relevant in that environment; to the contrary, services and chaining may
span multiple networks including the DC and WAN. Further, as I mentioned
in a previous post, services are what the consumer buys and those services
could be constructed using one or more "functions" where those functions
could be a firewall as you said, but could also be a multitude of other
things, some of which you mention above.

>service node+context within that node).

Jim> this is certainly a valid way of forming basic service chains and we
have included such mechanisms as part of the potential work items should a
WG be formed.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 24 Jun 2013 14:19:08 +0000

Hi Med,

I think we will find there are various models for how service functions
are applied to service chains; the two most high-level models are (i)
proxy functions, and (ii) non-proxy functions. We called these two models
out in draft-quinn-nsh-00. In the former case it is true that the service
function is essentially a black box but with a well defined interface and
further that interface enables the blackbox to perform enhance service
delivery. In this case it will be the job of the proxy to interpret the
service headers and map them to a corresponding identifier that the
service function can understand (for example a VLAN). In the latter case
the service function itself will have the intelligence to interpret the
service headers and therefore as part of our work we will need to define
these headers, as well as the format and data presented to the service
function.

On 6/21/13 3:45 AM, "[email-masked]"
<[email-masked]> wrote:

>Hi Jim, all,
>
>I would even say: these functions are seen as black-boxes and no
>assumption is to be made on the outcome of such functions.
>
>>>application
>>>layer
>>>I note that it is hinted at in Paul and Jim's BoF proposal text and it
>>>is
>>>there

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 24 Jun 2013 14:35:32 +0000

Hi Med,

One further thought. All of the points that you make are well taken and
honestly reflect one of the reasons why we have submitted our NSH
proposal. Trying to define the characteristics and operation of each and
every service function (NLF in your terminology) is imho looking at the
problem from the wrong direction. What we want to be able to do is take
the intelligence inherent within the network and present that information
to whatever application/function is running within a service function so
that it may take advantage of that data in whichever way it chooses. This
requires that said intelligence is presented in a standardized format so
that the developer of the service function can be sure of what information
it can obtain from the network and how it might process that to provide
the function it is designed to perform. It also provides the ability for
one service function to interoperate with other service functions so as to
build service chains.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 24 Jun 2013 17:08:30 +0000

Hi Jim,

On 24 Jun 2013, at 16:35 , Jim Guichard (jguichar) wrote:
> the function it is designed to perform.

So this requires a standardized network-to-SF interface. I assume you refer here to a mechanism by which the SF could learn what data it can retrieve from the network once deployed in a certain location, as well as defining the mechanisms for attaching a service to that location (whether by means of an address/port pair, a URL, a tunnel endpoint...)

> It also provides the ability for one service function to interoperate with
> other service functions so as to build service chains.

And this requires a standardized SF metadata interface, so each SF can announce what it expects as input and provides as output, so an orchestrator can statically or even dynamically build the appropriate chain. And this open the question on whether chaining is linear and unidirectional, so we could speak of pipelining, or it is foreseeable more complex composition structures.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: <[email-masked]>
Date: Tue, 25 Jun 2013 08:19:16 +0200

Hi Jim,

I think we are sync on the required protocol extensions and the merits of the approach.

On important aspect to consider is provisioning and policy enforcement: as you can see in draft-boucadair-*, we separated these aspects from the actual handling of packets and the behavior of involved nodes. I would vote to include the work on the Information Model (data model may not be in scope in a first step since DMs will depend on the favorite provisioning protocol a network is using). 

Cheers,
Med

>De : Jim Guichard (jguichar) [mailto:[email-masked]]
>Envoyé : lundi 24 juin 2013 16:36
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 25 Jun 2013 11:04:11 +0000

Hi Diego,

On 6/24/13 1:08 PM, "Diego R. Lopez" <[email-masked]> wrote:

>So this requires a standardized network-to-SF interface. I assume you
>refer here to a mechanism by which the SF could learn what data it can
>retrieve from the network once deployed in a certain location, as well as
>defining the mechanisms for attaching a service to that location (whether
>by means of an address/port pair, a URL, a tunnel endpoint...)

Jim> yes.

>And this requires a standardized SF metadata interface, so each SF can
>announce what it expects as input and provides as output, so an
>orchestrator can statically or even dynamically build the appropriate
>chain. And this open the question on whether chaining is linear and
>unidirectional, so we could speak of pipelining, or it is foreseeable
>more complex composition structures.

Jim> yes although the SF may or may not announce its capabilities (in the
latter case the orchestrator would be told directly). In terms of service
chains we have to work through both unidirectional and bidirectional as
well as complex chains (where traffic may be diverted mid-chain for
example on to a different chain).

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 25 Jun 2013 11:27:22 +0000

Hi Med,
Yes agreed they are separate work items and should absolutely be worked on
as part of this overall effort.

On 6/25/13 2:19 AM, "[email-masked]"
<[email-masked]> wrote:

>On important aspect to consider is provisioning and policy enforcement:
>as you can see in draft-boucadair-*, we separated these aspects from the
>actual handling of packets and the behavior of involved nodes. I would
>vote to include the work on the Information Model (data model may not be
>in scope in a first step since DMs will depend on the favorite
>provisioning protocol a network is using).
>
>Cheers,
>Med
>
>>>>Jim
>>>>>because I asked them why this proposal was aimed at the Routing Area
>>>>>not
>>>>>the

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 26 Jun 2013 02:22:45 +0000

Hi,

Current two types of SF is one way of classifying, meaning SF having or not having the capability of dealing with a NSC header. Here, I'd like to highlight there is another way of classifying SF, which we need to take into consideration. That is, the SF may be transparent or terminating to a flow. For example, a flow will go through a load balancer transparently, but will be terminated at a cache. These two types will influence how a chain is organized and requirements of the protocol.

My two cents.

Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, June 25, 2013 7:04 PM
To: Diego R. Lopez
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nsc] What is a service? Why is NSC not SC?

Hi Diego,

Jim> yes.

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 26 Jun 2013 02:51:10 +0000

Hi,

Please allow me to chip in on the original questions.

NSC may be interpreted in two ways. One is what's chained are network functions. The other is service functions are chained on network layer. Both should be in the scope. In other words, we are seeking chaining SFs on network level, while SF could be network service functions or higher layer service functions.

Another point I wanna make is that IMHO, on key character of NSC is traffic is forwarded per service characteristics other than destination addresses. This is the key value NSC WG, if will be formed, should work on. Service characteristics may include the network service a use has subscribed to, e.g. parental control, firewall. That means a packet is forwarded into a service chain, when a classifier matches some rules of service characteristics, which may be reflected by access ports, or segments or tuples in a packet.

Cheers,
Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Monday, June 24, 2013 6:58 AM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]; Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] What is a service? Why is NSC not SC?

Hi all,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Jun 2013 12:25:48 +0000

Hi Hongyu,

Comments inline ..

On 6/25/13 10:51 PM, "Hongyu Li (Julio)" <[email-masked]> wrote:

>NSC may be interpreted in two ways. One is what's chained are network
>functions. 

Jim> I would say that what is chained are functions applied to network
traffic. 

>The other is service functions are chained on network layer. Both should
>be in the scope. In other words, we are seeking chaining SFs on network
>level, while SF could be network service functions or higher layer
>service functions.

Jim> yes, exactly right. Perhaps the correct terminology is Lx-L7 service
functions?   

>
>Another point I wanna make is that IMHO, on key character of NSC is
>traffic is forwarded per service characteristics other than destination
>addresses.

Jim> it is certainly possible to form basic service chains using only
destination address through manipulation of routing. However, more complex
chains that reflect service characteristics and policy, or service
functions that are able to consume and/or insert metadata require a more
flexible steering mechanism as you say.

> This is the key value NSC WG, if will be formed, should work on. Service
>characteristics may include the network service a use has subscribed to,
>e.g. parental control, firewall. That means a packet is forwarded into a
>service chain, when a classifier matches some rules of service
>characteristics, which may be reflected by access ports, or segments or
>tuples in a packet.
>
>Cheers,
>Hongyu
>
>Looking at this thread, combining the distinction between "function" and
>"service" provided by Benson, and the assumptions Med lists in what
>relates to how policy applies to them within an administrative domain, I
>am in favor of talking of functions that are combined (chained) to build
>services, at any recursion level: a service can be composed (chained) as
>a function to build a more complex service.
>
>>>> I note that it is hinted at in Paul and Jim's BoF proposal text and
>>>>it is
>>>> there

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Jun 2013 13:13:37 +0000

Hongyu, regarding:

[snip] Another point I wanna make is that IMHO, on key character of NSC is traffic is forwarded per service characteristics other than destination addresses. This is the key value NSC WG, if will be formed, should work on. Service characteristics may include the network service a use has subscribed to, e.g. parental control, firewall. That means a packet is forwarded into a service chain, when a classifier matches some rules of service characteristics, which may be reflected by access ports, or segments or tuples in a packet.

[Ron]:  I view NSC as a specific application of policy based forwarding, where the policy is based on any or all of the fields in the IP header.   The end-to-end model of classifier-based nodes and non-classifier-based nodes means that there are 2 distinct sets of procedures to determine and apply the policy.

Best regards,

Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hongyu Li (Julio)
Sent: Tuesday, June 25, 2013 10:51 PM
To: Diego R. Lopez; <[email-masked]> <[email-masked]>
Cc: [email-masked]; Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] What is a service? Why is NSC not SC?

Hi,

Cheers,
Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Monday, June 24, 2013 6:58 AM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]; Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] What is a service? Why is NSC not SC?

Hi all,

Be goode,

On 21 Jun 2013, at 09:45 , <[email-masked]>  <[email-masked]> wrote:

>> Jim Guichard (jguichar) Envoyé : jeudi 20 juin 2013 19:23 À : 
>> [email-masked]; [email-masked] Objet : Re: [nsc] What is a 
>> service? Why is NSC not SC?
>>
>> Hi Adrian,
>>
>>> accidental :-)
>> Jim> actually the intent was that both packet-oriented and 
>> Jim> application
>> envisage service chains that incorporate both of these types of 
>> functions and we should not restrict our work to one or the other but 
>> rather let the use cases dictate.
>>
>>
>>> it is there because I asked them why this proposal was aimed at the 
>>> Routing Area not the Applications Area. To which the answer was 
>>> "because we want to steer packets or flows to the place where the 
>>> next service will be applied."
>>>
>>> Adrian
>>>

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 26 Jun 2013 13:54:08 +0000

Hi Ron,

> [Ron]:  I view NSC as a specific application of policy based forwarding, where the policy is based on any or all of the fields in the IP header.   The end-to-end model of classifier-based nodes and…

I'd prefer to think that it is not necessarily limited to the fields in the IP header. To start with, we could think in TCP/UDP headers or L2 ones. Or even think about application stuff, like HTTP headers...

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: David Meyer <[email-masked]>
Date: Wed, 26 Jun 2013 06:56:38 -0700

> I'd prefer to think that it is not necessarily limited to the fields in the IP header. To start with, we could think in TCP/UDP headers or L2 ones. Or even think about application stuff, like HTTP…

Certainly agree with this...--dmm

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Jun 2013 13:59:02 +0000

Hi, Diego.

Thanks for the response.   Comment below.

BR,
Ron

[snip] I'd prefer to think that it is not necessarily limited to the fields in the IP header. To start with, we could think in TCP/UDP headers or L2 ones. Or even think about application stuff, like HTTP headers...

[Ron] Agree completely.   NSC is a specific application of policy based forwarding where the policy is based on classification of the packets, including layers 2 through 7.     By stating that the NLF's are located via their IP addresses and/or FQDN's, we don't require or preclude any particular forwarding paradigm between the classifier node and the non-classifier node.

-----Original Message-----
From: Diego R. Lopez [mailto:[email-masked]] 
Sent: Wednesday, June 26, 2013 9:54 AM
To: Ron Parker
Cc: Hongyu Li (Julio); <[email-masked]> <[email-masked]>; [email-masked]; Jim Guichard (jguichar); [email-masked]
Subject: Re: [nsc] What is a service? Why is NSC not SC?

Hi Ron,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Jun 2013 14:16:53 +0000

I think we need to be clear on definitions. I believe your comments to be true (although I would not restrict it to the IP header only) for classification of traffic that needs to be forwarded into a service chain. Actual forwarding through the service chain is achieved using the headers pushed on to the packets based upon the initial or subsequent classification.

Sent from my iPhone

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 26 Jun 2013 14:37:12 +0000

Hi Jim,

I agree that forwarding based on pushed headers is a possible model for building the chain, but others are possible as well. You can have a "service router" where SFs (or NLFs) forward packets once processed and that decides on the following step. Or you can build the chain by means of a SDN controller. Or it could even be conceivable to use some kind of specific addressing schema: a couple of possible ideas could be multicast or LISP... I do not imply that I support any of these solutions (for the moment) or even any or all of them are necessarily feasible, but just to cite a few additional choices at this point.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Jun 2013 14:45:05 +0000

Yes I agree Diego but my point was that classification may be a different operation to forwarding.

Sent from my iPhone

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 26 Jun 2013 14:44:09 +0000

Hi Ron,

Agreed. That's why a few messages ago I was saying we needed to define how to identify the SF/NLF interfaces...

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 26 Jun 2013 14:45:33 +0000

And I can only say "amen" to that!

Dr Diego R. Lopez
Telefonica I+D

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