Subject: [nsc] Ted Lemon's concern with charter text

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 2 Dec 2013 12:20:54 -0000

Hi,

During IESG review Ted and I had a bit of an exchange about the meaning of "a
service" and the "layer at which a service chain can be applied".

Ted was looking for some text to clarify this in the in the charter and suggests
replacing the entire first paragraph with...

>  Network service providers, in addition to delivering IP connectivity,
>  frequently provide in-path services such as firewall filtering, load
>  balancing and transactional proxies such as spam filters.   Delivery
>  of these types of services is undergoing significant change with the
>  introduction of virtualization, network overlays, and orchestration.
> 
>  Service delivery is currently both a technical and an organizational
>  challenge that involves significant modification to the network
>  configuration, impacting the speed at which services can be
>  deployed and increasing operational costs.   Such services are
>  typically implemented by the ordered combination of a number of
>  service functions that are deployed at different points within a
>  network.
> 
>  Today, a common deployment model has service functions inserted on
>  the data-forwarding path between communicating peers. Going forward,
>  however, there is a desire to move to a different model, where
>  service functions, whether physical or virtualized, are not required
>  to reside on the direct data path and traffic is instead steered
>  through service functions, wherever they are deployed.

This is only a strawman from Ted (and thanks to him for proposing text), and we
should not assume that it is immutable. 

I think the way to look at this is:
- Is there anything in the new text we disagree with?
- Would making this change cause harm?
- Could this change be improved still further?

Opinions please.

Cheers,
Adrian

---

From: Ron Parker <[email-masked]>
Date: Mon, 2 Dec 2013 15:03:13 +0000

Adrian,

I think Ted's text is a very nice summary of what we are trying to accomplish.

He does use the term "in-path" which could use some elaboration, IMO.   I feel that SFC applies to transparent mid-boxes and not to explicitly addressed service functions (i.e., SFC applies to a transparent HTTP proxy, but not to an explicit HTTP proxy).

>  balancing and transactional proxies such as spam filters.   

Could become:

"Network service providers, in addition to delivering IP connectivity, frequently provide transparent services such as firewall filtering, load balancing and transactional proxies such as spam filters."

We may want to strike or replace load balancing as that may not be an actual transparent service but rather a building block for some actual transport service -- open to suggestions on this verbage.

> the data-forwarding path between communicating peers.

Could become:

"Today, a common deployment model is to insert various mid-boxes on the data-forwarding path between communicating peers."

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

During IESG review Ted and I had a bit of an exchange about the meaning of "a service" and the "layer at which a service chain can be applied".

Ted was looking for some text to clarify this in the in the charter and suggests replacing the entire first paragraph with...

> through service functions, wherever they are deployed.

This is only a strawman from Ted (and thanks to him for proposing text), and we should not assume that it is immutable. 

Opinions please.

Cheers,
Adrian

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

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 2 Dec 2013 16:34:30 +0000

Issue#1: I think we have to be careful to not use the word 'service' to speak of a given network function. 

Personally, I always use the word 'service' as something perceived by the end user/customer. Something that you subscribe to, something that you benefit from, something that you may be billed for, something that may require customer care interactions. This is a 'black box' perspective, the Network Service Provider (or IT department inside an Enterprise) can then implement such service in many ways, using many network functions and related systems, without the end user knowing.

So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service Function! Meaning a network function that directly helps in providing service-related processing and service (profile) differentiation. It's just a component though, not the entire Service as perceived by the end user.

And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as this term has a connotation that would seem to exclude some forms of Service Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, they are *the* primary Service Function in today's broadband networks). 

Issue #2: I understand what Ted is trying to say with the 'in-path' aspect, but fact is service (function) chaining is about steering use traffic via a constrained path, and well, the service function does remain on the data path (granted, the data path changed from a 'shortest path routed' to a more constrained path, but it's still a data path!). 

===
I don't know, seems to me that the existing first paragraph is actually fine, if not better (even if the last sentence 'direct data path' terminology isn't that great either). It also seems to me that we've been hair-splitting for a while now, and maybe we should just move on... I would just suggest to simplify the last sentence of the existing paragraph and say:

<< Going forward, however, there is a desire to move to a different model, where traffic can be steered through service functions (physical or virtualized), wherever they are deployed.>>

And then, during the actual work, for sure, we'll need to settle on clear definitions for 'Service', 'Service Function', etc.

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, December 02, 2013 10:03 AM
To: [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Adrian,

Could become:

Could become:

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

> however, there is a desire to move to a different model, where service 
> functions, whether physical or virtualized, are not required to reside 
> on the direct data path and traffic is instead steered through service 
> functions, wherever they are deployed.

Opinions please.

Cheers,
Adrian

---

From: Ron Parker <[email-masked]>
Date: Mon, 2 Dec 2013 17:52:44 +0000

Hi, Jerome.

I agree with your definitions of service vs. service function.

Regarding functions like PGW, in the upstream direction for user traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is therefore not in need of any traffic steering.   In the downstream direction, the PGW represents itself as a PE router that reaches the subscribers.   Most of the interest, today, around the mobile use case is for transparent middlebox functions that reside between the PGW and the Internet.   The set of service functions is typically called the "Gi LAN", a name that more or less implies the present day deployment model.

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 11:35 AM
To: Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

===

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, December 02, 2013 10:03 AM
To: [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Adrian,

Could become:

Could become:

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

Opinions please.

Cheers,
Adrian

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 2 Dec 2013 17:57:53 +0000

Well, the PGW (or a BNG for wireline) is the starting point of the chain. It acts as both Service Classifier and Service Policy Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is squarely a Service Function. Would you agree?

(anyhoo, my point was mostly to avoid the middlebox terminology! Even if I know what you mean!)

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 12:53 PM
To: Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hi, Jerome.

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Monday, December 02, 2013 11:35 AM
To: Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

===

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, December 02, 2013 10:03 AM
To: [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Adrian,

Could become:

Could become:

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

Opinions please.

Cheers,
Adrian

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Dec 2013 18:09:46 +0000

Jerome,

I agree with you that the PGW (or a BNG for wireline) is the starting point of the
chain. (most likely) It acts as both Service Classifier and Service Policy Enforcement Point. 

Do you call PGW or BNG a "service function"?  PGW/BNG can steer traffic to other service functions", but I don't think PGW/BNG themselves should be called "service functions". 

Linda 

> From: nsc [mailto:[email-masked]] On Behalf Of Jerome Moisand
> Sent: Monday, December 02, 2013 11:58 AM
> Well, the PGW (or a BNG for wireline) is the starting point of the
> chain. It acts as both Service Classifier and Service Policy
> Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is
> squarely a Service Function. Would you agree?
> 
> Regarding functions like PGW, in the upstream direction for user
> traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is
> therefore not in need of any traffic steering.   In the downstream
> direction, the PGW represents itself as a PE router that reaches the
> subscribers.   Most of the interest, today, around the mobile use case
> is for transparent middlebox functions that reside between the PGW and
> the Internet.   The set of service functions is typically called the
> "Gi LAN", a name that more or less implies the present day deployment
> model.
> 
>    Ron
> 
> 
> Personally, I always use the word 'service' as something perceived by
> the end user/customer. Something that you subscribe to, something that
> you benefit from, something that you may be billed for, something that
> may require customer care interactions. This is a 'black box'
> perspective, the Network Service Provider (or IT department inside an
> Enterprise) can then implement such service in many ways, using many
> network functions and related systems, without the end user knowing.
> 
> So a firewall or a spam-filtering proxy is NOT a Service. It's... a
> Service Function! Meaning a network function that directly helps in
> providing service-related processing and service (profile)
> differentiation. It's just a component though, not the entire Service
> as perceived by the end user.
> 
> And Ron, I would suggest to avoid speaking of mid-box (or middleboxes),
> as this term has a connotation that would seem to exclude some forms of
> Service Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox',
> and yet, they are *the* primary Service Function in today's broadband
> networks).
> 
> Issue #2: I understand what Ted is trying to say with the 'in-path'
> aspect, but fact is service (function) chaining is about steering use
> traffic via a constrained path, and well, the service function does
> remain on the data path (granted, the data path changed from a
> 'shortest path routed' to a more constrained path, but it's still a
> data path!).
> 
> ===
> I don't know, seems to me that the existing first paragraph is actually
> fine, if not better (even if the last sentence 'direct data path'
> terminology isn't that great either). It also seems to me that we've
> been hair-splitting for a while now, and maybe we should just move on...
> I would just suggest to simplify the last sentence of the existing
> paragraph and say:
> 
> << Going forward, however, there is a desire to move to a different
> model, where traffic can be steered through service functions (physical
> or virtualized), wherever they are deployed.>>
> 
> And then, during the actual work, for sure, we'll need to settle on
> clear definitions for 'Service', 'Service Function', etc.
> 
> He does use the term "in-path" which could use some elaboration, IMO.
> I feel that SFC applies to transparent mid-boxes and not to explicitly
> addressed service functions (i.e., SFC applies to a transparent HTTP
> proxy, but not to an explicit HTTP proxy).
> 
> "Network service providers, in addition to delivering IP connectivity,
> frequently provide transparent services such as firewall filtering,
> load balancing and transactional proxies such as spam filters."
> 
> We may want to strike or replace load balancing as that may not be an
> actual transparent service but rather a building block for some actual
> transport service -- open to suggestions on this verbage.
> 
> 
> "Today, a common deployment model is to insert various mid-boxes on the
> data-forwarding path between communicating peers."
> 
> 
> 
>    Ron
> 
> 
> During IESG review Ted and I had a bit of an exchange about the meaning
> of "a service" and the "layer at which a service chain can be applied".
> 
> Ted was looking for some text to clarify this in the in the charter and
> suggests replacing the entire first paragraph with...
> 
> service
> This is only a strawman from Ted (and thanks to him for proposing text),
> and we should not assume that it is immutable.
>

---

From: Ron Parker <[email-masked]>
Date: Mon, 2 Dec 2013 18:18:38 +0000

Jerome,

The PGW could be decomposed further for fitting it into an SFC context.   The call control portion is explicitly addressed and is therefore not subject to SFC controls.   The PCEF functions, however, operate in the user plane and are transparent to the original communications endpoints and therefore are subject to SFC controls. 

   Ron

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, December 02, 2013 12:53 PM
To: Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hi, Jerome.

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Monday, December 02, 2013 11:35 AM
To: Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

===

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, December 02, 2013 10:03 AM
To: [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Adrian,

Could become:

Could become:

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

Opinions please.

Cheers,
Adrian

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Mon, 2 Dec 2013 19:08:17 +0000

> Personally, I always use the word 'service' as something perceived by the end user/customer

I agree with you on this point and I think this is in-line with the definition of service currently present in  draft-quinn-sfc-arch:

"Service:  An offering provided by an operator that is delivered using one or more service functions.  This may also be referred to as a
      composite service."

>Well, the PGW (or a BNG for wireline) is the starting point of the chain. It acts as both Service Classifier and Service Policy >Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is squarely a Service Function. Would you agree?

Regarding your comment on BNG in my opinion according to the definitions of "service function" and "service node" in draft-quinn-sfc-arch the BNG is a Service Node not a Service Function. 

Quoting the definitions from draft-quinn-sfc-arch:
" Service Function (SF):  A network or application based packet
      treatment, application, compute or storage resource, used
      singularly or in concert with other service functions within a
      service chain to enable a service offered by an operator

   Service Node (SN):  Physical or virtual element that hosts one or
      more service functions and has one or more network locators
      associated with it for reachability and service delivery."

Any comments?

Thanks
Roberta

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, December 02, 2013 12:53 PM
To: Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hi, Jerome.

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Monday, December 02, 2013 11:35 AM
To: Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

===

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, December 02, 2013 10:03 AM
To: [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Adrian,

Could become:

Could become:

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

Opinions please.

Cheers,
Adrian

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 2 Dec 2013 19:31:26 +0000

Hi Roberta,

Yes, you're right, this is a better way to put it. A BNG includes a Service Function (or several), but is actually a full Service Node. Same would apply to PGW, as Ron pointed out.

==
Sorry Adrian, I am afraid we high jacked a bit the discussion about the first paragraph of the charter though...

-----Original Message-----
From: Roberta Maglione (robmgl) [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 2:08 PM
To: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

> the end user/customer

Any comments?

Thanks
Roberta

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, December 02, 2013 12:53 PM
To: Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hi, Jerome.

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Monday, December 02, 2013 11:35 AM
To: Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

===

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, December 02, 2013 10:03 AM
To: [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Adrian,

Could become:

Could become:

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

Opinions please.

Cheers,
Adrian

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Mon, 2 Dec 2013 20:22:43 +0000

Thanks Jerome.
 Going back to the discussion about the first paragraph I agree with you when you say that

" a firewall or a spam-filtering proxy is NOT a Service. It's... a Service Function" 
and this is also in-line with the examples of Service functions listed in definition of SF in the draft-quinn-sfc-arch: 
"A non-exhaustive list of Service Functions includes: firewalls,
      WAN and application acceleration, Deep Packet Inspection (DPI),
      server load balancers, ..."

The current version of the first paragraph as is looks ok to me, but maybe we should understand  better from Ted what is missing/needs to be clarified in the current text in order to address his comments.

Best Regards
Roberta

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 2:31 PM
To: Roberta Maglione (robmgl); Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function

Hi Roberta,

==

-----Original Message-----
From: Roberta Maglione (robmgl) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 2:08 PM
To: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Any comments?

Thanks
Roberta

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Monday, December 02, 2013 12:53 PM
To: Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hi, Jerome.

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Monday, December 02, 2013 11:35 AM
To: Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

===

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, December 02, 2013 10:03 AM
To: [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Adrian,

Could become:

Could become:

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, December 02, 2013 7:21 AM
To: [email-masked]
Cc: Ted Lemon
Subject: [nsc] Ted Lemon's concern with charter text

Hi,

Opinions please.

Cheers,
Adrian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 15:35:14 -0500

> The current version of the first paragraph as is looks ok to me, but maybe we should understand  better from Ted what is missing/needs to be clarified in the current text in order to address his co…

The easiest thing from my side would be for you to put what you think ought to be there in the text and send me that, and I can tell you whether it does the job for me.   The problem with the original text was simply that I had no idea what "services" were, and so I couldn't parse the rest of the charter.   Once Adrian explained what that meant, the whole thing made sense.   I'd like it if others reading the charter had the "makes sense" experience rather than the "no idea what it means" experience. :)

The text that I proposed was simply a proposal for how to restructure and what to put in to make that happen.   I was pretty sure that the actual terms I used were wrong, so don't feel obliged to retain them.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 2 Dec 2013 22:06:50 -0000

I think it is clear that Ted is just asking for "a little more background". This
should be relatively harmless, but I can bet that there are a few devils (or at
least minor daemons) in the detail of that.

So, an option here (and, yes, I would also like to avoid splitting hairs for the
rest of the year) is to:
- merge the current paragraph with Ted's three
- update Ted's text as necessary (such as s/service/service function)

Anyone want to take a stab, or shall I?

Adrian

> From: Ted Lemon [mailto:[email-masked]]
> Sent: 02 December 2013 20:35
> To: Roberta Maglione (robmgl)
> Cc: Jerome Moisand; Adrian Farrel; [email-masked]; Ron Parker
> Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and
> Service Function
> 
> > The current version of the first paragraph as is looks ok to me, but maybe
we
> should understand  better from Ted what is missing/needs to be clarified in
the
> current text in order to address his comments.
> 
> The easiest thing from my side would be for you to put what you think ought to
> be there in the text and send me that, and I can tell you whether it does the
job
> for me.   The problem with the original text was simply that I had no idea
what
> "services" were, and so I couldn't parse the rest of the charter.   Once
Adrian
> explained what that meant, the whole thing made sense.   I'd like it if others
> reading the charter had the "makes sense" experience rather than the "no idea
> what it means" experience. :)
> 
> The text that I proposed was simply a proposal for how to restructure and what
> to put in to make that happen.   I was pretty sure that the actual terms I
used
> were wrong, so don't feel obliged to retain them.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 2 Dec 2013 23:00:42 +0000

Hi Adrian/Ted,

Would the following text suffice?

Network operators frequently utilize service functions such as firewall
filtering, load-balancing and transactional proxies (for example spam
filters) in the delivery of services to end users.   Delivery of these
types of services is undergoing significant change with the introduction
of virtualization, network overlays, and orchestration. Deploying service
functions to support service delivery is currently both a technical and an
organizational challenge that involves significant modification to the
network
configuration, impacting the speed at which services can be deployed and
increasing operational costs.   Such services are typically implemented by
the ordered combination of a number of service functions that are deployed
at different points within a network. Today, common deployment models have
service functions inserted on the data-forwarding path between
communicating peers. Going forward, however, there is a need to move to a
different model, where service functions, whether physical or virtualized,
are not required
to reside on the direct data path and traffic is instead steered through
required service functions, wherever they are deployed.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Dec 2013 23:47:15 +0000

I share the same view as Ted stated: "The problem with the original text was simply that I had no idea what "services" were...". 

Many service function examples being discussed on the SFC list and in the use case drafts are for optimization purpose, like TCP acceleration, Video/Web acceleration. Those functions may not even be visible to external entities. 

The so called "service delivery" in the context of NSC (or SFC) is more about applying a sequence of service functions to treat packets that match certain criteria. 

Therefore, I think that the following text is more accurate description:

"The mechanisms of applying service functions to "data flows" is undergoing significant change with the introduction of virtualization, network overlays and orchestration. ..."

There may be a better name than "data  flows", such as plain simple "connectivity services" or "traffic among peers". 

p.s. In the "draft-quinn-nsc-problem-statements", Network Service is defined as "An externally visible service offered by a network operator; but many service functions being discussed are not visible to external entities. 

Linda 

> Sent: Monday, December 02, 2013 4:07 PM
> To: [email-masked]
> Cc: 'Ted Lemon'
> > On Dec 2, 2013, at 3:22 PM, Roberta Maglione (robmgl)
> <[email-masked]>
> > wrote:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 19:51:49 -0500

That looks great to me.   But please, pretty please, break that giant paragraph up into three bite-sized chunks.   You could break once at "Deploying service functions" and a second time at "Today, common".

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Dec 2013 14:27:54 -0000

[Adding IESG into the thread so they can see the changes for the latest
revision]

Thanks Jim and Ted. I have replaced the first paragraph with Jim's new text and
broken it up as Ted requested.

> That looks great to me.   But please, pretty please, break that giant
paragraph up
> into three bite-sized chunks.   You could break once at "Deploying service
> functions" and a second time at "Today, common".

Cheers,
Adrian

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Tue, 3 Dec 2013 16:34:08 +0000

Hi Linda,

I support your statement.  Suggest we carefully distinguish between an abstract function, mean a well-defined unique elementary functionality and a physical device like a BNG or PGW or even a switch, router or x86 middleware box. Reading Ron's arguments, I assume Ron probably thinks in the same direction. 

Originally e.g. a BNG is the service creation point for a DSL service (PPP, DHCP). A BNG as you said will also classify or inspect traffic and forward it according certain rules given e.g. by a AAA (up/downstream).  Similar arguments for a PGW.

I could insert a service card into a BNG box and run e.g. CG-NAT on it. Means CG-NAT would be in the BNG box but it is another elementary functionality which also could be realized outside the BNG box on another platform just dedicated for CG-NAT and located deep in the service function chain platform.  I could plug service cards into routers and run some service functions. 

Some vendors offer proprietary systems which include more than one unique functionality. I could buy a "performance enhancement proxy" (whatever it means) which includes in e.g. TCP optimization, header enrichment and video optimization. This is typically a big installation over some racks but it can still be seen as one system or performance enhancement function. 

An instantiation of an abstract unique elementary function (node) in a service function chain (directed graph) may even consist of a load balancer and a certain number of instances of the elementary service function, physical or virtualized.  See also Ron's argumentation.

Means one really should distinguish between an abstract elementary functionality which I would associate with a node (for short service function)  in an abstract service chain (directed graph) and a physical box which may include more than just one instantiation of an elementary function. 

Other example: A commercial load balancer may have more functions than just load balancing. ....
 
What do you think?
    
Regards, Walter

-----Ursprüngliche Nachricht-----
Von: nsc [mailto:[email-masked]] Im Auftrag von Linda Dunbar
Gesendet: Montag, 2. Dezember 2013 19:10
An: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Betreff: Re: [nsc] Ted Lemon's concern with charter text

Jerome,

I agree with you that the PGW (or a BNG for wireline) is the starting point of the chain. (most likely) It acts as both Service Classifier and Service Policy Enforcement Point. 

Linda 

> And Ron, I would suggest to avoid speaking of mid-box (or 
> middleboxes), as this term has a connotation that would seem to 
> exclude some forms of Service Functions (e.g. a BNG or PGW are rarely 
> viewed as 'middlebox', and yet, they are *the* primary Service 
> Function in today's broadband networks).
> 
> I don't know, seems to me that the existing first paragraph is 
> actually fine, if not better (even if the last sentence 'direct data path'
> model, where traffic can be steered through service functions 
> (physical or virtualized), wherever they are deployed.>>
> 
> >  Network service providers, in addition to delivering IP 
> > connectivity, frequently provide in-path services such as firewall 
> > filtering, load  balancing and transactional proxies such as spam filters.
> 
> Could become:
> 
> "Today, a common deployment model is to insert various mid-boxes on 
> the data-forwarding path between communicating peers."
> 
> 
> 
>    Ron
> 
> 
> During IESG review Ted and I had a bit of an exchange about the 
> meaning of "a service" and the "layer at which a service chain can be applied".
> 
> Ted was looking for some text to clarify this in the in the charter 
> and suggests replacing the entire first paragraph with...
> 
> >  Network service providers, in addition to delivering IP 
> > connectivity, frequently provide in-path services such as firewall filtering, load
> >  of these types of services is undergoing significant change with 
> > the introduction of virtualization, network overlays, and orchestration.
> >
> >  Service delivery is currently both a technical and an 
> > organizational challenge that involves significant modification to 
> > the network configuration, impacting the speed at which services can be
> This is only a strawman from Ted (and thanks to him for proposing 
> text), and we should not assume that it is immutable.
>

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 4 Dec 2013 07:08:35 +0000

Hello Haeffner,

You are correct that a device like PGW, BNG or Load Balancer may offer multiple service. For example commercial load balancer can offer header enrichment, TCP optimization and quite an array of steering functionality. They can and do offer custom policy engines and such. 

Another way of putting this is that a service-node may offer multiple distinct services. The local box can select a specific service based on the local policy.  In my head I visualizing a service node that has one ingress and one egress but can offer multiple service inside that local entity. 

I hope that would be possible as per this WG.  

________________________________________
From: nsc [[email-masked]] on behalf of Haeffner, Walter, Vodafone DE [[email-masked]]
Sent: Tuesday, December 03, 2013 8:34 AM
To: Linda Dunbar; Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Hi Linda,

What do you think?

Regards, Walter

-----Ursprüngliche Nachricht-----
Von: nsc [mailto:[email-masked]] Im Auftrag von Linda Dunbar
Gesendet: Montag, 2. Dezember 2013 19:10
An: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Betreff: Re: [nsc] Ted Lemon's concern with charter text

Jerome,

Linda

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Dec 2013 13:51:18 +0000

Sumandra,

Your use case should absolutely be supported.    Many service functions may be co-located in the same compute complex (without getting too precise on the meaning of that term).   And in such a case, each may use distinct or shared network locators (i.e., distinct or shared IP addresses).

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Wednesday, December 04, 2013 2:09 AM
To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hello Haeffner,

Hi Linda,

What do you think?

Regards, Walter

-----Ursprüngliche Nachricht-----
Von: nsc [mailto:[email-masked]] Im Auftrag von Linda Dunbar
Gesendet: Montag, 2. Dezember 2013 19:10
An: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Betreff: Re: [nsc] Ted Lemon's concern with charter text

Jerome,

Linda

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 4 Dec 2013 15:33:29 +0000

Back to the original thread... ;-)

The new wording sounds fine to me. I would just reiterate my suggestion about avoiding the 'direct data path' terminology. Service chaining is about modifying the data path, it's not about avoiding it. I understand what 'direct' is supposed to mean, but this may be rather confusing to other readers.

Current text:
<< Today, common deployment models have service functions inserted on
the data-forwarding path between communicating peers. Going forward,
however, there is a need to move to a different model, where service
functions, whether physical or virtualized, are not required to reside on
the direct data path and traffic is instead steered through required service
functions, wherever they are deployed.>>

Proposed change:

<< Today, common deployment models have service functions inserted on the regular data-forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where traffic can be steered through required service functions (physical or virtualized), wherever they are deployed.>>

Tx
Jerome

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Wednesday, December 04, 2013 8:51 AM
To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Sumandra,

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 2:09 AM
To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hello Haeffner,

Hi Linda,

What do you think?

Regards, Walter

-----Ursprüngliche Nachricht-----
Von: nsc [mailto:[email-masked]] Im Auftrag von Linda Dunbar
Gesendet: Montag, 2. Dezember 2013 19:10
An: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Betreff: Re: [nsc] Ted Lemon's concern with charter text

Jerome,

Linda

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Dec 2013 16:17:10 +0000

Jerome,

I like your edits, but I'm iffy on "regular data path".   I'll offer a further refinement of your text:

<< Today, common deployment models have service functions inserted transparently on the data-forwarding path between communicating peers.  Going forward, however, there is a desire to move to a different model, where traffic can be steered through required service functions (physical or virtualized), wherever they are deployed.>>

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]] 
Sent: Wednesday, December 04, 2013 10:33 AM
To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Current text:
<< Today, common deployment models have service functions inserted on the data-forwarding path between communicating peers. Going forward, however, there is a need to move to a different model, where service functions, whether physical or virtualized, are not required to reside on the direct data path and traffic is instead steered through required service functions, wherever they are deployed.>>

Proposed change:

Tx
Jerome

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 8:51 AM
To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Sumandra,

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 2:09 AM
To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hello Haeffner,

Hi Linda,

What do you think?

Regards, Walter

-----Ursprüngliche Nachricht-----
Von: nsc [mailto:[email-masked]] Im Auftrag von Linda Dunbar
Gesendet: Montag, 2. Dezember 2013 19:10
An: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Betreff: Re: [nsc] Ted Lemon's concern with charter text

Jerome,

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Dec 2013 16:30:33 +0000

Ron's refined wording is very accurate description. Really like it. 

Linda
> << Today, common deployment models have service functions inserted
> transparently on the data-forwarding path between communicating peers.
> Going forward, however, there is a desire to move to a different model,
> where traffic can be steered through required service functions
> To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda
> Dunbar; [email-masked]; [email-masked]
> Cc: Ted Lemon
> The new wording sounds fine to me. I would just reiterate my suggestion
> about avoiding the 'direct data path' terminology. Service chaining is
> about modifying the data path, it's not about avoiding it. I understand
> what 'direct' is supposed to mean, but this may be rather confusing to
> other readers.
> 
> Current text:
> on the direct data path and traffic is instead steered through required
> service functions, wherever they are deployed.>>
> 
> Proposed change:
> 
> the regular data-forwarding path between communicating peers. Going
> forward, however, there is a desire to move to a different model, where
> traffic can be steered through required service functions (physical or
> virtualized), wherever they are deployed.>>
> 
> Tx
> Jerome
> 
> To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome
> Moisand; [email-masked]; [email-masked]
> Cc: Ted Lemon
> Your use case should absolutely be supported.    Many service functions
> may be co-located in the same compute complex (without getting too
> precise on the meaning of that term).   And in such a case, each may
> use distinct or shared network locators (i.e., distinct or shared IP
> addresses).
> 
>    Ron
> 
> 
> To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron
> Parker; [email-masked]; [email-masked]
> Cc: Ted Lemon
> You are correct that a device like PGW, BNG or Load Balancer may offer
> multiple service. For example commercial load balancer can offer header
> enrichment, TCP optimization and quite an array of steering
> functionality. They can and do offer custom policy engines and such.
> 
> Another way of putting this is that a service-node may offer multiple
> distinct services. The local box can select a specific service based on
> the local policy.  In my head I visualizing a service node that has one
> ingress and one egress but can offer multiple service inside that local
> entity.
> 
> From: nsc [[email-masked]] on behalf of Haeffner, Walter,
> Vodafone DE [[email-masked]]
> I support your statement.  Suggest we carefully distinguish between an
> abstract function, mean a well-defined unique elementary functionality
> and a physical device like a BNG or PGW or even a switch, router or x86
> middleware box. Reading Ron's arguments, I assume Ron probably thinks
> in the same direction.
> 
> Originally e.g. a BNG is the service creation point for a DSL service
> (PPP, DHCP). A BNG as you said will also classify or inspect traffic
> and forward it according certain rules given e.g. by a AAA
> (up/downstream).  Similar arguments for a PGW.
> 
> I could insert a service card into a BNG box and run e.g. CG-NAT on it.
> Means CG-NAT would be in the BNG box but it is another elementary
> functionality which also could be realized outside the BNG box on
> another platform just dedicated for CG-NAT and located deep in the
> service function chain platform.  I could plug service cards into
> routers and run some service functions.
> 
> Some vendors offer proprietary systems which include more than one
> unique functionality. I could buy a "performance enhancement proxy"
> (whatever it means) which includes in e.g. TCP optimization, header
> enrichment and video optimization. This is typically a big installation
> over some racks but it can still be seen as one system or performance
> enhancement function.
> 
> An instantiation of an abstract unique elementary function (node) in a
> service function chain (directed graph) may even consist of a load
> balancer and a certain number of instances of the elementary service
> function, physical or virtualized.  See also Ron's argumentation.
> 
> Means one really should distinguish between an abstract elementary
> functionality which I would associate with a node (for short service
> function)  in an abstract service chain (directed graph) and a physical
> box which may include more than just one instantiation of an elementary
> function.
> 
> I agree with you that the PGW (or a BNG for wireline) is the starting
> point of the chain. (most likely) It acts as both Service Classifier
> and Service Policy Enforcement Point.
> 
> Do you call PGW or BNG a "service function"?  PGW/BNG can steer traffic
> to other service functions", but I don't think PGW/BNG themselves
> should be called "service functions".
> 
> Linda
> 
> filtering, load
> Delivery

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 4 Dec 2013 16:40:23 +0000

Yes, I was struggling with the same point, Ron. Your rewording is perfect. Hopefully, Ted and Adrian and Jim will like it too! ;-)

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Wednesday, December 04, 2013 11:31 AM
To: Ron Parker; Jerome Moisand; Sumandra Majee; Haeffner, Walter, Vodafone DE; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Linda
> Going forward, however, there is a desire to move to a different 
> model, where traffic can be steered through required service functions 
> The new wording sounds fine to me. I would just reiterate my 
> suggestion about avoiding the 'direct data path' terminology. Service 
> chaining is about modifying the data path, it's not about avoiding it. 
> I understand what 'direct' is supposed to mean, but this may be rather 
> confusing to other readers.
> 
> Current text:
> on the direct data path and traffic is instead steered through 
> required service functions, wherever they are deployed.>>
> 
> Proposed change:
> 
> forward, however, there is a desire to move to a different model, 
> To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; 
> Jerome Moisand; [email-masked]; [email-masked]
> Cc: Ted Lemon
> multiple service. For example commercial load balancer can offer 
> header enrichment, TCP optimization and quite an array of steering 
> distinct services. The local box can select a specific service based 
> on the local policy.  In my head I visualizing a service node that has 
> one ingress and one egress but can offer multiple service inside that 
> local entity.
> 
> and a physical device like a BNG or PGW or even a switch, router or 
> x86 middleware box. Reading Ron's arguments, I assume Ron probably 
> thinks in the same direction.
> 
> enrichment and video optimization. This is typically a big 
> installation over some racks but it can still be seen as one system or 
> performance enhancement function.
> 
> function)  in an abstract service chain (directed graph) and a 
> physical box which may include more than just one instantiation of an 
> elementary function.
> 
> Do you call PGW or BNG a "service function"?  PGW/BNG can steer 
> traffic to other service functions", but I don't think PGW/BNG 
> themselves should be called "service functions".
> 
> Linda
> 
> > "Gi LAN", a name that more or less implies the present day 
> > deployment model.
> >
> >    Ron
> >
> >
> > Personally, I always use the word 'service' as something perceived 
> > by the end user/customer. Something that you subscribe to, something
> that
> > differentiation. It's just a component though, not the entire 
> > Service as perceived by the end user.
> >
> > exclude some forms of Service Functions (e.g. a BNG or PGW are 
> > rarely viewed as 'middlebox', and yet, they are *the* primary 
> > Service Function in today's broadband networks).
> >
> > aspect, but fact is service (function) chaining is about steering 
> > use traffic via a constrained path, and well, the service function 
> > does remain on the data path (granted, the data path changed from a 
> > "Network service providers, in addition to delivering IP 
> > connectivity, frequently provide transparent services such as 
> > firewall filtering, load balancing and transactional proxies such as spam filters."
> >
> > We may want to strike or replace load balancing as that may not be 
> > an actual transparent service but rather a building block for some
> actual
> > >  Today, a common deployment model has service functions inserted 
> > > on the data-forwarding path between communicating peers.
> >
> > Could become:
> >
> > meaning of "a service" and the "layer at which a service chain can 
> > be
> applied".
> >
> > >  Today, a common deployment model has service functions inserted 
> > > on the data-forwarding path between communicating peers. Going

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 5 Dec 2013 05:56:55 +0000

I liked the original text better. "need"/"desire" could not care less.

Surendra.

On 12/4/13 8:40 AM, "Jerome Moisand" <[email-masked]> wrote:

>Yes, I was struggling with the same point, Ron. Your rewording is
>perfect. Hopefully, Ted and Adrian and Jim will like it too! ;-)
>
>To: Ron Parker; Jerome Moisand; Sumandra Majee; Haeffner, Walter,
>Vodafone DE; [email-masked]; [email-masked]
>Cc: Ted Lemon
>> > > where

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 5 Dec 2013 07:01:17 +0000

Hi Ron and colleagues,

I wonder how can a service function be physical or virtualized, maybe implicitly you mean the node they are implemented on. To be consistent with other terminologies in the proposed charter such as "service function instances" and "network nodes", and call out network function "virtualization" as a new trend, I would like to propose the following text:

<< Today, common deployment models have service functions implemented on physical nodes which are located on the regular data-forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions can be implemented on either physical or virtualized network nodes, and traffic can be steered through required service functions wherever they are deployed.>>

Regards,
Yuanlong

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, December 05, 2013 12:17 AM
To: Jerome Moisand; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

Jerome,

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]] 
Sent: Wednesday, December 04, 2013 10:33 AM
To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Current text:

Proposed change:

Tx
Jerome

-----Original Message-----
From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 8:51 AM
To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Sumandra,

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 2:09 AM
To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: RE: [nsc] Ted Lemon's concern with charter text

Hello Haeffner,

Hi Linda,

What do you think?

Regards, Walter

-----Ursprüngliche Nachricht-----
Von: nsc [mailto:[email-masked]] Im Auftrag von Linda Dunbar
Gesendet: Montag, 2. Dezember 2013 19:10
An: Jerome Moisand; Ron Parker; [email-masked]; [email-masked]
Cc: Ted Lemon
Betreff: Re: [nsc] Ted Lemon's concern with charter text

Jerome,

Linda

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Dec 2013 12:37:19 +0000

Yuanlong,

I don't have a problem pointing out that most deployments today are on non-virtualized service functions.  But we should be careful with the wording -- even virtualized service functions reside on physical compute nodes.  

    Ron

> On Dec 5, 2013, at 2:01 AM, "Jiangyuanlong" <[email-masked]> wrote:
> 
> Hi Ron and colleagues,
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Dec 2013 16:50:47 +0000

I'm afraid that I do not like the use of the word "transparent" in the
revised text as this will require even more explanation in the charter.
What do we mean by "transparent"; transparent to the end-user? Transparent
to the TCP session? Transparent to Š? You get my point. I would suggest
that removal of "transparent" from the text should be sufficient as the
existing text is only meant to say that service functions sit on the
forwarding path today and in future we want to relax that requirement
through steering.

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Dec 2013 16:51:53 +0000

No objections from me.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Thursday, December 05, 2013 11:51 AM
To: Jerome Moisand; Linda Dunbar; Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; [email-masked]; [email-masked]
Cc: Ted Lemon
Subject: Re: [nsc] Ted Lemon's concern with charter text

I'm afraid that I do not like the use of the word "transparent" in the revised text as this will require even more explanation in the charter.
What do we mean by "transparent"; transparent to the end-user? Transparent to the TCP session? Transparent to Š? You get my point. I would suggest that removal of "transparent" from the text should be sufficient as the existing text is only meant to say that service functions sit on the forwarding path today and in future we want to relax that requirement through steering.

On 12/4/13 11:40 AM, "Jerome Moisand" <[email-masked]> wrote:

>> model, where traffic can be steered through required service 
>> functions (physical or virtualized), wherever they are deployed.>>
>> 
>>    Ron
>> 
>> 
>> I understand what 'direct' is supposed to mean, but this may be 
>> rather confusing to other readers.
>> 
>> Current text:
>> functions, whether physical or virtualized, are not required to 
>> reside on the direct data path and traffic is instead steered through 
>> You are correct that a device like PGW, BNG or Load Balancer may 
>> offer multiple service. For example commercial load balancer can 
>> offer header enrichment, TCP optimization and quite an array of 
>> steering functionality. They can and do offer custom policy engines and such.
>> 
>> on the local policy.  In my head I visualizing a service node that 
>> has one ingress and one egress but can offer multiple service inside 
>> that local entity.
>> 
>> I support your statement.  Suggest we carefully distinguish between 
>> an abstract function, mean a well-defined unique elementary 
>> functionality and a physical device like a BNG or PGW or even a 
>> switch, router or
>> installation over some racks but it can still be seen as one system 
>> or performance enhancement function.
>> 
>> An instantiation of an abstract unique elementary function (node) in 
>> a service function chain (directed graph) may even consist of a load 
>> > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it 
>> > is squarely a Service Function. Would you agree?
>> >
>> > Enterprise) can then implement such service in many ways, using 
>> > many network functions and related systems, without the end user knowing.
>> >
>> > actually fine, if not better (even if the last sentence 'direct 
>> > data
>> path'
>> > terminology isn't that great either). It also seems to me that 
>> > we've been hair-splitting for a while now, and maybe we should just 
>> > move
>> on...
>> > addressed service functions (i.e., SFC applies to a transparent 
>> > HTTP proxy, but not to an explicit HTTP proxy).
>> >
>> > > connectivity, frequently provide in-path services such as 
>> > > firewall filtering, load  balancing and transactional proxies 
>> > > such as spam
>> filters.
>> >
>> > Could become:
>> >
>> > firewall filtering, load balancing and transactional proxies such 
>> > as
>>spam filters."
>> >
>> > > organizational challenge that involves significant modification 
>> > > to the network configuration, impacting the speed at which 
>> > > services
>> can be

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 5 Dec 2013 14:04:15 -0500

Yea, I agree. This is a slippery slope akin to where we originally went off the road in PWE3 when we debated "reproduces the wire" or something like that.  What we ended up with was "faithfully approximates" or something.  That relaxation of the terminology/requirements went a long way in pragmatism of solutions. 

	--Tom

>>>> reside