Subject: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

From: Linda Dunbar <[email-masked]>
Date: Wed, 25 Feb 2015 16:52:27 +0000

Joel and Carlos,

The current definition of RSP is:

Rendered Service Path (RSP): The Service Function Path is a
constrained specification of where packets using a certain
service chain must go. While it may be so constrained as to
identify the exact locations, it can also be less specific.
Packets themselves are of course transmitted from and to
specific places in the network, visiting a specific sequence of
SFFs and SFs. This sequence of actual visits by a packet to
specific SFFs and SFs in the network is known as the Rendered
Service Path (RSP). This definition is included here for use by
later documents, such as when solutions may need to discuss the
actual sequence of locations the packets visit.

Some suggestions:

-          I would think it is more accurate to call it "Rendered Service Function Path (RSFP)".

-          Why do you say "packets using a certain service chain"? It is more accurate to say "packets belonging to a certain service function chain".

Here is my suggested wording for RSP (or RSFP):

-          The sequence of actual SFFs and SFs in the network traversed by packets belonging to a specific Service Function Chain is known as the Rendered Service Function Path (RSFP).

Cheers,

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 25 Feb 2015 17:08:12 +0000

Joel,

What does it mean by saying packets "using" a service chain?

How does packets  "use" a service chain? I am confused.

Linda

From: Joel Halpern [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 10:59 AM
To: Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

I don't think adding another word to the term will help comprehension, and it will complicate usage.  So I would prefer not to do that.

As for the other change, packets don't belong to a service chain.  They may be using a service chain.  They may be assigned by a classifier to a service chain, but they don't "belong" to the chain as I understand the words.

Yours,
Joel

From: Linda Dunbar [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 11:52 AM
To: Joel Halpern; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Joel Halpern <[email-masked]>
Date: Wed, 25 Feb 2015 16:59:16 +0000

Yours,
Joel

From: Linda Dunbar [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 11:52 AM
To: Joel Halpern; Carlos Pignataro (cpignata); [email-masked]
Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Joel Halpern <[email-masked]>
Date: Wed, 25 Feb 2015 17:10:52 +0000

Sorry.  A packet is technically using a service function path.  It is doing so if the information in the SFC defined header indicates that the packet is to forwarded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The RSP itself requires a rather omniscient observer perspective to determine, but does exist conceptually.

Yours,
Joel

From: Linda Dunbar [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 12:08 PM
To: Joel Halpern; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Joel,

Linda

From: Joel Halpern [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, February 25, 2015 10:59 AM
To: Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 25 Feb 2015 17:21:06 +0000

Packets being "assigned" to a Service Function Chain (path) makes sense.

But packets "using" a service function chain/path is quite odd.

Linda

From: Joel Halpern [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 11:11 AM
To: Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Feb 2015 12:26:18 -0500

I could live with replacing "using" with "assigned to".
Yours,
Joel

On 2/25/15 12:21 PM, Linda Dunbar wrote:
> Packets being “assigned” to a Service Function Chain (path) makes sense.
>
> But packets “using” a service function chain/path is quite odd.
>
> Linda
>
> *From:*Joel Halpern [mailto:[email-masked]]
> *Sent:* Wednesday, February 25, 2015 11:11 AM
> *To:* Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]
> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in
> draft-ietf-sfc-architecture-05
>
> Sorry.  A packet is technically using a service function path.  It is
> doing so if the information in the SFC defined header indicates that the
> packet is to forwarded along that service function path.  Thus, the
> assignment / usage can be determined from examining the packet.  The RSP
> itself requires a rather omniscient observer perspective to determine,
> but does exist conceptually.
>
> Yours,
>
> Joel
>
> *From:*Linda Dunbar [mailto:[email-masked]]
> *Sent:* Wednesday, February 25, 2015 12:08 PM
> *To:* Joel Halpern; Carlos Pignataro (cpignata); [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in
> draft-ietf-sfc-architecture-05
>
> Joel,
>
> What does it mean by saying packets “using” a service chain?
>
> How does packets  “use” a service chain? I am confused.
>
> Linda
>
> *From:*Joel Halpern [mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]>
> *Sent:* Wednesday, February 25, 2015 10:59 AM
> *To:* Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in
> draft-ietf-sfc-architecture-05
>
> I don’t think adding another word to the term will help comprehension,
> and it will complicate usage.  So I would prefer not to do that.
>
> As for the other change, packets don’t belong to a service chain.  They
> may be using a service chain.  They may be assigned by a classifier to a
> service chain, but they don’t “belong” to the chain as I understand the
> words.
>
> Yours,
>
> Joel
>
> *From:*Linda Dunbar [mailto:[email-masked]]
> *Sent:* Wednesday, February 25, 2015 11:52 AM
> *To:* Joel Halpern; Carlos Pignataro (cpignata); [email-masked]
> <mailto:[email-masked]>
> *Subject:* wording Suggestion for the Rendered Service Path (RSP) in
> draft-ietf-sfc-architecture-05
>
> Joel and Carlos,
>
> -I would think it is more accurate to call it “Rendered Service Function
> Path (RSFP)”.
>
> -Why do you say “packets using a certain service chain”? It is more
> accurate to say “packets belonging to a certain service function chain”.
>
> -The sequence of actual SFFs and SFs in the network traversed by packets
> belonging to a specific Service Function Chain is known as the Rendered
> Service Function Path (RSFP).
>
> Cheers,
>
> Linda Dunbar
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 25 Feb 2015 17:28:28 +0000

I am agnostic about the "using" vs. "assigned" vs. something else nomenclature, but feel it's important to follow Joel's explicit use of "service function path" in this context ... a given "service function chain" can be configured over multiple different "paths", even concurrently.

Avanti,
BobN

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, February 25, 2015 12:21 PM
To: Joel Halpern; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Linda

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Ron Parker <[email-masked]>
Date: Wed, 25 Feb 2015 18:01:57 +0000

I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don't think that comes out clearly in the current description, especially when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

*        SFC - specify the sequence of service function types that need to be visited

*        SFP - specify the sequence of service function types that need to be visited, but also optionally specify instance selection constraining policies for some or all of the types

*        RSP - specify the exact sequence of service function instances that need to be visited (with the understanding that an instance may optionally perform its own internal load balancing)

Thanks.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern
Sent: Wednesday, February 25, 2015 12:11 PM
To: Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]
Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 25 Feb 2015 18:18:23 +0000

I like Ron's suggestion, except that the RSP should be  "the sequence of actual SFFs and SFs in the network traversed".  RSP may not be "specified". Different packets assigned to the same service function path can traverse through different RSPs.

Linda

From: Ron Parker [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 12:02 PM
To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Thanks.

   Ron

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Feb 2015 18:52:17 +0000

Sure ‹ this change + replacing chain with path, made in the working copy.
These are useful, but very narrow editorials, which to me reinforces the
fact that the doc is ready to be sent to the IESG.

Chairs,

This document¹s WGLC ended on 2014-11-14 (over 3.5 months ago). Is there
something else needed? Can you please request pub?

Thanks,

‹ Carlos.

On 2/25/15, 12:26 PM, "Joel M. Halpern" <[email-masked]> wrote:

>> Packets being ³assigned² to a Service Function Chain (path) makes sense.
>>
>> But packets ³using² a service function chain/path is quite odd.
>>
>> Linda
>>
>> What does it mean by saying packets ³using² a service chain?
>>
>> How does packets  ³use² a service chain? I am confused.
>>
>> Linda
>>
>> I don¹t think adding another word to the term will help comprehension,
>> As for the other change, packets don¹t belong to a service chain.  They
>> service chain, but they don¹t ³belong² to the chain as I understand the
>> words.
>>
>> Yours,
>>
>> Joel
>>
>> -I would think it is more accurate to call it ³Rendered Service Function
>> Path (RSFP)².
>>
>> -Why do you say ³packets using a certain service chain²? It is more
>> accurate to say ³packets belonging to a certain service function chain².
>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 25 Feb 2015 14:56:02 -0500

+1

> On Feb 25, 2015:11:59 AM, at 11:59 AM, Joel Halpern <[email-masked]> wrote:
> 
> I don’t think adding another word to the term will help comprehension, and it will complicate usage.  So I would prefer not to do that.
>  
> As for the other change, packets don’t belong to a service chain.  They may be using a service chain.  They may be assigned by a classifier to a service chain, but they don’t “belong” to the chain as I understand the words.
>  
> Yours,
> Joel
>  
> From: Linda Dunbar [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Joel Halpern; Carlos Pignataro (cpignata); [email-masked] <mailto:[email-masked]>
> -          I would think it is more accurate to call it “Rendered Service Function Path (RSFP)”.
> -          Why do you say “packets using a certain service chain”? It is more accurate to say “packets belonging to a certain service function chain”.
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 26 Feb 2015 10:13:46 +0900

I think that Ron's definitions are much clear. Also, I suppose that SFP 
includes SFF that need to be visited additionally. Is this correct?

Cheers,
Shunsuke

On 2015/02/26 3:01, Ron Parker wrote:
> I think the key concept here is that of a 3 level hierarchy of SFC, SFP,
> RSP.   I don’t think that comes out clearly in the current description,
> especially when RSP references Service Function Chain rather than
> Service Function Path.   The way I think of it:
>
> ·SFC – specify the sequence of service function types that need to be
> visited
>
> ·SFP – specify the sequence of service function types that need to be
> visited, but also optionally specify instance selection constraining
> policies for some or all of the types
>
> ·RSP – specify the exact sequence of service function instances that
> need to be visited (with the understanding that an instance may
> optionally perform its own internal load balancing)
>
> Thanks.
>
>     Ron
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Joel Halpern
> *Sent:* Wednesday, February 25, 2015 12:11 PM
> *Subject:* [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered
> Service Path (RSP) in draft-ietf-sfc-architecture-05
>

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service System Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: Ron Parker <[email-masked]>
Date: Thu, 26 Feb 2015 01:26:42 +0000

I think if we state that RSP is the exact sequence of SF instances, we indirectly resolve the sequence of SFFs, too, since the SFC system must know the SF instance to SFF (s) bindings.   I was hesitant to state that RSP was the sequence of SF instances and SFFs, as has been suggested, because of the possibility that SF instances COULD be multi-homed to SFFs. 

   Ron

> On Feb 25, 2015, at 8:12 PM, Shunsuke Homma <[email-masked]> wrote:
> 
> I think that Ron's definitions are much clear. Also, I suppose that SFP includes SFF that need to be visited additionally. Is this correct?
> 
> Cheers,
> Shunsuke
>

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 26 Feb 2015 11:25:41 +0900

Ron,

Thank you for your reply. I understand and agree with your opinion 
regarding RSP. Is SFF also the same?

Shunsuke

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 26 Feb 2015 18:33:43 +0000

I think Ron's suggested wording for SFC is much more straight forward than the current SFC definition on the sfc-architecture-05.

draft-ietf-sfc-architecture-05 has:
Service Function Chain (SFC): A service function chain defines an
ordered set of abstract service functions (SFs) and ordering
constraints that must be applied to packets and/or frames and/or
flows selected as a result of classification. An example of an
abstract service function is "a firewall". The implied order
may not be a linear progression as the architecture allows for
SFCs that copy to more than one branch, and also allows for
cases where there is flexibility in the order in which service
functions need to be applied. The term service chain is often
used as shorthand for service function chain.

Isn't the wording of  "an ordered set of abstract service functions (SFs) that must be applied to packets and/or frames and/or flows" already sufficient enough to describe the ordering constraints?

Why need the extra wording of "..and ordering constraints"?

"...selected as a result of classification" should be more like ".. selected based on a specific matching criteria".

I suggest using the following wording:

"A service function chain defines an ordered set of abstract service functions (SFs)
that must be applied to packets and/or frames and/or flows that meet the specific matching criteria."

It is implementation specific to have a classification node inspecting packets and attaching different SFC-IDs based on the "Service Chain matching Criteria" in the header to make it easier for subsequent nodes.

Linda

Thanks.

   Ron

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Joel Halpern <[email-masked]>
Date: Thu, 26 Feb 2015 21:22:30 +0000

While Ron's wording was roughly right, it did not seem to add anything to what we had, and was not written as a definition, but as a description.  As such, the question is whether it adds anything to the descriptive text further in the document.

Also, it is quite possible to have tighter ordering constraints on an SFP than on an SFC.  How tight the ordering constraints are in the SFC probably depends upon the SFC definer and tools.

Yours,
Joel

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, February 26, 2015 1:34 PM
To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Linda

From: Ron Parker [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, February 25, 2015 12:02 PM
To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Thanks.

   Ron

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 26 Feb 2015 21:32:04 +0000

Joel,

Agree with what you said:

"..., it is quite possible to have tighter ordering constraints on an SFP than on an SFC."

[Linda] Do you really need the extra wording ""..and ordering constraints" for the SFC definition?
Is it sufficient to say "A service function chain defines an ordered set of abstract service functions (SFs) that must be applied to packets and/or frames and/or flows"?

Linda

From: Joel Halpern [mailto:[email-masked]]
Sent: Thursday, February 26, 2015 3:23 PM
To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Yours,
Joel

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, February 26, 2015 1:34 PM
To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Linda

Thanks.

   Ron

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Joel Halpern <[email-masked]>
Date: Thu, 26 Feb 2015 21:35:38 +0000

Sorry.  I now understand your question.

As a mathematician, I would probably be happy if the definition simply said "a partially ordered set of abstract service functions that must be applied ..."
However, I think most people would find that less than enlightening.

Yours,
Joel

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, February 26, 2015 4:32 PM
To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Joel,

Linda

From: Joel Halpern [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, February 26, 2015 3:23 PM
To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Yours,
Joel

Linda

Thanks.

   Ron

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 26 Feb 2015 22:15:20 +0000

Joel,

Thank you for the understanding.

Through our 9-vendor joined Service Graph Forwarding Proof of Concept project for NFV-ONF, we learned that same service function by different vendors can be very different. E.g. FW by Vendor A can be very different from FW by Vendor B.

So the ordered set of "Service Functions" has to be specific to which vendor's service functions.

For example, one service function chain could be "<Vendor A><FW> -->  <Vendor B> <SecurityGW>"; another service function chain could be "<Vendor B><FW> --> <Vendor C><SecurityGW>".

Bottom line, we don't have "abstract service functions".  I don't understand why SFC definition has to say "order set of abstract service functions".  I suggest removing the word "abstract" from the SFC definition.

Cheers,
Linda

From: Joel Halpern [mailto:[email-masked]]
Sent: Thursday, February 26, 2015 3:36 PM
To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Yours,
Joel

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, February 26, 2015 4:32 PM
To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Joel,

Linda

Yours,
Joel

Linda

Thanks.

   Ron

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: Ron Parker <[email-masked]>
Date: Thu, 26 Feb 2015 22:21:56 +0000

Linda,

I think 'abstract' here means "one SFC-visible instance of".   In your example, you would have a chain as "one instance of <VendorA-FW> --> one instance of <VendorB-SecurityGW>".   A corresponding path would be "one gold instance of <VendorA-FW> --> one purple instance of <VendorB-SecurityGW>".   A corresponding RSP would be "instance-1 of <VendorA-FW> --> instance 3 of <VendorB-SecurityGW>, where those instances complied with the gold and purple instance selection constraints.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, February 26, 2015 5:15 PM
To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); [email-masked]
Subject: [sfc] Service Functions used in a chain is anything but "Abstract" (was RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

Joel,

Cheers,
Linda

Yours,
Joel

Joel,

Linda

Yours,
Joel

Linda

Thanks.

   Ron

Yours,
Joel

Joel,

Linda

Yours,
Joel

Joel and Carlos,

Some suggestions:

Cheers,

Linda Dunbar

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 18:05:11 -0500

Assuming we end up with useful definitions of service functions, they 
can be abstract.  AFor now, it may be that things have to be described 
in terms of specific ids, such as OpenStack may use for deployment of 
individual functions.  But architecturally that is very limiting.

Since the SFC working group is not defining the protocols for that 
aspect of the system, we should talk in terms of abstract services, even 
if the current implementable control may need to be more specific.

Yours,
Joel

On 2/26/15 5:15 PM, Linda Dunbar wrote:
> Through our 9-vendor joined Service Graph Forwarding Proof of Concept
> project for NFV-ONF, we learned that same service function by different
> vendors can be very different. E.g. FW by Vendor A can be very different
> from FW by Vendor B.
>
> So the ordered set of “Service Functions” has to be specific to which
> vendor’s service functions.
>
> For example, one service function chain could be “<Vendor A><FW>
> à <Vendor B> <SecurityGW>”; another service function chain could be
> “<Vendor B><FW> à<Vendor C><SecurityGW>”.
>
> Bottom line, we don’t have “abstract service functions”.  I don’t
> understand why SFC definition has to say “order set of abstract service
> functions”.  I suggest removing the word “abstract” from the SFC
> definition.
>
> Cheers,
>
> Linda
>
> *Sent:* Thursday, February 26, 2015 3:36 PM
> *To:* Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); [email-masked]
> As a mathematician, I would probably be happy if the definition simply
> said “a partially ordered set of abstract service functions that must be
> applied …”
>
> *Sent:* Thursday, February 26, 2015 4:32 PM
> *To:* Joel Halpern; Ron Parker; Carlos Pignataro (cpignata);
> *Agree with what you said:*
>
> “…, it is quite possible to have tighter ordering constraints on an SFP
> than on an SFC.”
>
> [Linda] Do you really need the extra wording ““..and ordering
> constraints” for the SFC definition?
>
> Is it sufficient to say “A service function chain defines an ordered set
> of abstract service functions (SFs) that must be applied to packets
> and/or frames and/or flows”?
>
> Linda
>
> *Sent:* Thursday, February 26, 2015 3:23 PM
> *To:* Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata);
> While Ron’s wording was roughly right, it did not seem to add anything
> to what we had, and was not written as a definition, but as a
> description.  As such, the question is whether it adds anything to the
> descriptive text further in the document.
>
> Also, it is quite possible to have tighter ordering constraints on an
> SFP than on an SFC.  How tight the ordering constraints are in the SFC
> probably depends upon the SFC definer and tools.
>
> Yours,
>
> Joel
>
> *Sent:* Thursday, February 26, 2015 1:34 PM
> *To:* Ron Parker; Joel Halpern; Carlos Pignataro (cpignata);
> I think Ron’s suggested wording for SFC is much more straight forward
> than the current SFC definition on the sfc-architecture-05.
>
> Isn’t the wording of  “an ordered set of abstract service functions
> (SFs) that must be applied to packets and/or frames and/or flows”
> already sufficient enough to describe the ordering constraints?
>
> Why need the extra wording of “..and ordering constraints”?
>
> “...selected as a result of classification” should be more like “..
> selected based on a specific matching criteria”.
>
> “A service function chain defines an ordered set of abstract service
> functions (SFs)
>
> that must be applied to packets and/or frames and/or flows that meet the
> specific matching criteria.”
>
> It is implementation specific to have a classification node inspecting
> packets and attaching different SFC-IDs based on the “Service Chain
> matching Criteria” in the header to make it easier for subsequent nodes.
>
> Linda
>
> *From:*Ron Parker [mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]>
> *Sent:* Wednesday, February 25, 2015 12:02 PM
> *To:* Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata);