Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

From: [email-masked]
Date: Mon, 10 Feb 2014 11:15:29 +0800

Hi，

  For Reinaldo's comments 2.
  I'm not sure "SF" & "SF instance" confuse me in the draft.

  For example, NAT44 with a rule is a SF, NAT44 with another rule is 
a different SF.  This is my understanding based on the description in
the draft.   (Or a same SF but different SF instances?) 

Thanks,
Wei

"sfc" <[email-masked]>  2014-01-30 14:26:55:

> Hi Paul,
> 
> Reviewing this draft and comparing with the Yang model I have a couple 
of
> comments
> 
> 1 - 
> 
> I noticed that a SFID and SFC-domain might need more wording.
> 
> "Service Function Identity (SFID):  A unique identifier that
>       represents a service function.  SFIDs are unique for each SF
>       within an SFC domain.²
> 
> "SFC-domain" is used within the definition above but then the draft
> switches to "administrative domain² everywhere else.
> 
> Also, the definition of Service Function uses ³administrative domain²
> instead of of "SFC-domain".
> 
> 
> 2 - 
> 
> It seems were are missing the definition of a instantiated Service
> Function:
> 
> A Service Function is something like NAT44, Firewall, etc. It denotes a
> class of services that provide the same function.
> 
> A SFC is an ordered set of SFs.
> 
> A SFP is an instantiation of a SFC. So, what do we call the SFs that are
> instantiated and part of the SFP? We can not call them Service Functions
> again because we are now talking about an specific service and that 
would
> cause confusion. Do we call them "Service Function Instances² and
> therefore a SFP is composed of an ordered set of Service Function
> Instances?
> 
> Thanks,
> 
> -RP
> 
> On 1/29/14, 6:58 AM, "Paul Quinn (paulq)" <[email-masked]> wrote:
> 
> >Hi folks,
> >
> >The only change to this version is that we moved to two editors, and
> >listed the other co-authors in a contributors section.
> >
> >As always, your comments and feedback is appreciated!
> >Paul
> >
> >
> >> 
> >> A new version of I-D, draft-quinn-sfc-arch-04.txt
> >> has been successfully submitted by Paul Quinn and posted to the
> >> IETF repository.
> >> 
> >> Name:      draft-quinn-sfc-arch
> >> Revision:   04
> >> Title:      Service Function Chaining (SFC) Architecture
> >> Document date:   2014-01-28
> >> Group:      Individual Submission
> >> Pages:      21
> >> URL: 
> >>http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-04.txt
> >> Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/
> >> Htmlized:       http://tools.ietf.org/html/draft-quinn-sfc-arch-04
> >> Diff: http://www.ietf.org/rfcdiff?url2=draft-quinn-sfc-arch-04
> >> 
> >> Abstract:
> >>   This document describes an architecture used for the creation of
> >>   Service Function Chains (SFC).  It includes architectural concepts,
> >>   principles, and components used in the construction of composite
> >>   services through deployment of SFCs in a network.  This document 
does
> >>   not propose solutions, protocols, or extensions to existing
> >>   protocols.
> >> 
> >> 
> >> 
> >> 
> >> Please note that it may take a couple of minutes from the time of
> >>submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >> 
> >> The IETF Secretariat
> >> 
> >
> >_______________________________________________
> >sfc mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 10 Feb 2014 14:00:26 +0000

Hi,

The Service Function NAT44 represents the functions a NAT44 performs,  i.e. Translate source IPv4 packets, create mappings, etc. But a Service Function does not process packets, it is just a template definition.

A service instance actually processes packets and is part of a Service Path.  So, two different NAT44 devices that process packets are classified under the same service function but represent different instances.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, February 9, 2014 at 7:15 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>
Subject: Re: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi，

Thanks,
Wei

"sfc" <[email-masked]<mailto:[email-masked]>>  2014-01-30 14:26:55:

> Hi Paul,
>
> Reviewing this draft and comparing with the Yang model I have a couple of
> comments
>
> 1 -
>
> again because we are now talking about an specific service and that would
> On 1/29/14, 6:58 AM, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >Hi folks,
> >
> >> Diff:
> >>   This document describes an architecture used for the creation ofhttp://www.ietf.org/rfcdiff?url2=draft-quinn-sfc-arch-04
> >>   services through deployment of SFCs in a network.  This document does
> >[email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Ron Parker <[email-masked]>
Date: Mon, 10 Feb 2014 15:03:19 +0000

Meng,

I view the instances issue in 2 different ways.

First, a type of service function (i.e., NAT44) may exist with multiple policy sets.    For this purpose, the deployment of a service function with a policy set is an instance.   For example, NAT44-with-policy-set-A is one instance while NAT44-with-policy-set-B is another instance.   From a chain perspective, chain 1 might contain NAT44-with-policy-set-A while chain 2 might contain NAT44-with-policy-set-B.    The actual location of the those 2 instances is arbitrary - it is possible that they are located to the same physical and/or virtual compute node or different.   It is even possible that the 2 logical instances are realized by the exact same set of processes executing on the exact same compute node, or at the other extreme, they could be located in different countries.

Second, a particular service function instance (i.e., NAT44-with-policy-set-A) may, itself, be multiply instantiated for load balancing or resiliency purposes.   I consider this aspect within the realm of “chain to path reduction”.   That, is the high level chain specified the need for NAT44-with-policy-set-A, but the actual chain invoked for a particular flow must end up steering the traffic to some particular instance of that logical service function.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 9:00 AM
To: [email-masked]
Cc: Paul Quinn (paulq); sfc; [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi,

Hi，

Thanks,
Wei

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 10 Feb 2014 19:12:34 +0000

Hi Ron,
Seems to me that there are actually 3 different things here:

  1.  A service function that is able to apply policy-set-A and policy-set-B and has an internal mechanism for distinction between which policy to apply to inbound traffic. In this case it is a single service function with internal classification between which policy set to apply.
  2.  A service function that applies policy-set-A and a different service function that applies policy-set-B e.g. They are two distinct service functions.
  3.  A service function that is able to apply policy-set-A and policy-set-B and relies upon indication within the inbound packet to determine which policy set to apply. In this case its a single service function but without internal classification.

From: Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 10:03 AM
To: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Paul Quinn <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Meng,

First, a type of service function (i.e., NAT44) may exist with multiple policy sets.    For this purpose, the deployment of a service function with a policy set is an instance.   For example, NAT44-with-policy-set-A is one instance while NAT44-with-policy-set-B is another instance.   From a chain perspective, chain 1 might contain NAT44-with-policy-set-A while chain 2 might contain NAT44-with-policy-set-B.    The actual location of the those 2 instances is arbitrary – it is possible that they are located to the same physical and/or virtual compute node or different.   It is even possible that the 2 logical instances are realized by the exact same set of processes executing on the exact same compute node, or at the other extreme, they could be located in different countries.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 9:00 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Paul Quinn (paulq); sfc; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi,

Hi，

Thanks,
Wei

---

From: Ron Parker <[email-masked]>
Date: Mon, 10 Feb 2014 19:41:10 +0000

Hi, Jim.

I agree.   Broadly speaking, there are 2 distinct ways to select a differentiated policy set for a particular class of service function.   In the one, it is conveyed implicitly by the SFC classifier which merely specifies the chain id – everything else follows from that.    In the other, the service function uses local mechanisms to determine which policy set to apply.    The form that the local mechanisms takes is outside of the SFC purview, IMO.

Orthogonal to all of that is the multiple instantiations for load balancing and/or resieliency purposes.

    Ron

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Monday, February 10, 2014 2:13 PM
To: Ron Parker; Reinaldo Penno (repenno); [email-masked]
Cc: Paul Quinn (paulq); [email-masked]; sfc
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi Ron,

Meng,

   Ron

Hi,

Hi，

Thanks,
Wei

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 10 Feb 2014 20:21:30 +0000

Based on the definition I see this differently.

The same service function could be instantiated with  policy-set-A and later instantiated with  policy-set-B. It is still the same service function, but different instances.

Therefore I would consider {1 below} one service function (say, NAT44) and two different service function instances, one that applies  policy-set-A and other that applies  policy-set-A.

From: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

  1.  A service function that applies policy-set-A and a different service function that applies policy-set-B e.g. They are two distinct service functions.

---

From: Cathy Zhang <[email-masked]>
Date: Mon, 10 Feb 2014 20:55:26 +0000

I share the same view as Reinaldo.
I think each Service Function is associated with a type, such as FW Service Function or NAT Service Function
while each Service Instance is an instantiation of a Service Function on a Service Node and is  associated with a specific policy profile/set of that type of Service Function.
In a SFC admin domain, there could be multiple Service Nodes (physical/virtual) that support a specific Service Function, such as FW,
and a service instance could be instantiated on any one of the Service Nodes (as to which Service Node to instantiate the service instance,
it depends on load status of the Service Nodes, network proximity etc., which is out of scope) .
Multiple flow chains can be associated with the same Service Instance on a Service Node, which means these flows will be applied the same policy set
for that specific type of service function, as shown in the following diagram.

BTW, I would like to suggest that the draft adds a definition for "Service Instance" to bring everyone on the same page as to its semantics.

Thanks,
Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; [email-masked]
Cc: Paul Quinn (paulq); sfc; [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Feb 2014 16:07:13 -0500

While one can choose to deploy different service instances to handle 
different policies, that is not currently described as a requirement.
To take that further, I very strongly disagree with making that a 
requirement.  In the operational models I have seen, that would 
complicate scaling and operations significantly.  I do not believe the 
architecture can or should prevent per-policy service function 
instances, but it ought not require such.

Yours,
Joel

On 2/10/14, 3:55 PM, Cathy Zhang wrote:
> while each Service Instance is an instantiation of a Service Function on
> a Service Node and is  associated with a specific policy profile/set of
> that type of Service Function.
>
> In a SFC admin domain, there could be multiple Service Nodes
> (physical/virtual) that support a specific Service Function, such as FW,
>
> and a service instance could be instantiated on any one of the Service
> Nodes (as to which Service Node to instantiate the service instance,
>
> Multiple flow chains can be associated with the same Service Instance on
> a Service Node, which means these flows will be applied the same policy set
>
> BTW, I would like to suggest that the draft adds a definition for
> “Service Instance” to bring everyone on the same page as to its semantics.
>
> Thanks,
>
> Cathy
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Reinaldo Penno
> (repenno)
> *Sent:* Monday, February 10, 2014 12:22 PM
> *To:* Jim Guichard (jguichar); Ron Parker; [email-masked]
> *Cc:* Paul Quinn (paulq); sfc; [email-masked]
> *Subject:* Re: [sfc] Fwd: New Version Notification for
> draft-quinn-sfc-arch-04.txt
>
> The same service function could be instantiated with  policy-set-A and
> later instantiated with  policy-set-B. It is still the same service
> function, but different instances.
>
> Therefore I would consider {1 below} one service function (say, NAT44)
> and two different service function instances, one that applies
>   policy-set-A and other that applies  policy-set-A.
>
> *From: *"Jim Guichard (jguichar)" <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Monday, February 10, 2014 at 11:12 AM
> *To: *Ron Parker <[email-masked]
> <mailto:[email-masked]>>, Cisco Employee
> <[email-masked] <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *"Paul Quinn (paulq)" <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, sfc <[email-masked]
> <mailto:[email-masked]>>
> *Subject: *Re: [sfc] Fwd: New Version Notification for
> draft-quinn-sfc-arch-04.txt
>
>  1. A service function that applies policy-set-A and a different service
>     function that applies policy-set-B e.g. They are two distinct
>     service functions.
>
>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 10 Feb 2014 21:07:39 +0000

How would you represent an instance of a service function instance? Seems more logical to represent a service function type that provides function based on policy set as an independent service function.

Sent from my iPhone

On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <[email-masked]<mailto:[email-masked]>> wrote:

BTW, I would like to suggest that the draft adds a definition for “Service Instance” to bring everyone on the same page as to its semantics.

Thanks,
Cathy

To: Jim Guichard (jguichar); Ron Parker; [email-masked]<mailto:[email-masked]>

---

From: Cathy Zhang <[email-masked]>
Date: Mon, 10 Feb 2014 21:23:23 +0000

Hi Jim,

Could you clarify what you mean by an instance of a service function instance?

Thanks,
Cathy

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Monday, February 10, 2014 1:08 PM
To: Cathy Zhang
Cc: Reinaldo Penno (repenno); Ron Parker; [email-masked]; Paul Quinn (paulq); sfc; [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Sent from my iPhone

Thanks,
Cathy

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Mon, 10 Feb 2014 22:30:15 +0000

IMHO:

in draft-quinn-sfc-arch-04.txt definitions:

"Service Function (SF):  A function that is responsible for specific treatment of received packets. "

So two instances of a Service Function should apply the same policy, as the policy

is what make the treatment of received packets to be specific.

A type of Service Function (eg. FW vs NAT44) is not enough to identify precisely a Service Function.

There is a need for a descriptor for what makes it specific, and a name so that it can be identified.

Very similar to a class/object paradygm in fact, as a class describes the behavior of its instances.

Nicolas

________________________________
From: Reinaldo Penno (repenno) [[email-masked]]
Sent: Monday, February 10, 2014 9:21 PM
To: Jim Guichard (jguichar); Ron Parker; [email-masked]
Cc: Paul Quinn (paulq); sfc; [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

---

From: Ron Parker <[email-masked]>
Date: Mon, 10 Feb 2014 22:36:33 +0000

Nicolas,

I'm supportive of both mechanisms that Jim described:

a)      The SF instance identity implies its policy set

b)      The SF instance locally selects its policy set through means not specified by SFC

The first provides useful simplification while the second more naturally supports highly differentiated policy behaviors.

So, does a service instance identity fully specify its behavior?   It depends.

   Ron

From: Nicolas BOUTHORS [mailto:[email-masked]]
Sent: Monday, February 10, 2014 5:30 PM
To: Reinaldo Penno (repenno); Jim Guichard (jguichar); Ron Parker; [email-masked]
Cc: Paul Quinn (paulq); sfc; [email-masked]
Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

IMHO:

Nicolas

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 10 Feb 2014 22:49:26 +0000

I can see that from service perspective, the NAT44-A and NAT44-B are different instances (or aspects) of NAT function.

However, there could be  multiple "entities" of NAT44-B (e.g.  one "entity" only has 10G capability), and many "entities" of NAT44-B. Each entity has its own unique address (or Locator in draft-parker-sfc-chain-to-path).

>From network steering perspective, any of  the "entities" for NAT44-B can be used for a chain that needs NAT44-B.

But a Service/Network forwarding node can't use NAT44-B for a chain that needs NAT44-A, so maybe the NAT44-A and NAT44-B can be considered as different service functions?

Some people (like Jim) call  those "entities" as  "instances" because they perform the same function but with different addresses.

How about we call those multiple "entities" as a "component"?  in the same way as the "component" in server cluster http://en.wikipedia.org/wiki/Computer_cluster

Linda

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, February 10, 2014 3:08 PM
To: Cathy Zhang
Cc: [email-masked]; sfc; Paul Quinn (paulq); Ron Parker; [email-masked]; Reinaldo Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Sent from my iPhone

Thanks,
Cathy

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 10 Feb 2014 22:54:24 +0000

Hello Nicolas,

Inline with [RP]

From: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 2:30 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

IMHO:

[RP] I see “specific treatment of packets” as in NAT44 translate source IPv4 packets and Firewalls accept/blocks connections.  So, they treat packets differently

[RP] Yes it is., it depends on your approach.  NAT44 behavior is defined in  http://tools.ietf.org/search/rfc4787

[RP] The SFC NAT44 class would describe basically http://tools.ietf.org/search/rfc4787 and a specific instance would have the actual policies.

Nicolas

From: Reinaldo Penno (repenno) [[email-masked]<mailto:[email-masked]>]

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 10 Feb 2014 23:04:18 +0000

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 2:49 PM
To: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

However, there could be  multiple “entities” of NAT44-B (e.g.  one “entity” only has 10G capability), and many “entities” of NAT44-B. Each entity has its own unique address (or Locator in draft-parker-sfc-chain-to-path).

>From network steering perspective, any of  the “entities” for NAT44-B can be used for a chain that needs NAT44-B.

But a Service/Network forwarding node can’t use NAT44-B for a chain that needs NAT44-A, so maybe the NAT44-A and NAT44-B can be considered as different service functions?

[RP] I would consider them the same service function but different instances. IMHO if a NAT44 performs as described in RFC4787, then that belongs to the NAT44 service function class. The configuration, rules and policies inside a specific instance of NAT  is what makes it different.

Now, I can see how one could consider each different NAT44 configuration as a different service function. But in that case you would have gazillions of service functions when in fact you only need a small number.

Some people (like Jim) call  those “entities” as  “instances” because they perform the same function but with different addresses.

How about we call those multiple “entities” as a “component”?  in the same way as the “component” in server cluster http://en.wikipedia.org/wiki/Computer_cluster

Linda

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, February 10, 2014 3:08 PM
To: Cathy Zhang
Cc: [email-masked]<mailto:[email-masked]>; sfc; Paul Quinn (paulq); Ron Parker; [email-masked]<mailto:[email-masked]>; Reinaldo Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Sent from my iPhone

Thanks,
Cathy

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 10 Feb 2014 23:17:27 +0000

Hi Cathy,

let’s take the FW example with policy-set-a and policy-set-b. If we treat the FW as a type of service function where policy-set-a and policy-set-b are instances of that “type" of service function then my point is that each of those could be located at multiple points in the network thereby giving you multiple “instances” of the policy-set-a “instance” and the policy-set-b “instance. I will argue that that is not the right way to look at it.. Let me explain my logic.

Let’s take the FW example again. Suppose that I now have policy-set’s a,b,c, & d. Lets further suppose that policy-set’s a&b are available at service nodes 1, 2, 3 & 4 and policy-set’s c&d are available at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will not have the necessary policy to treat the traffic even though we have said they are of the same service function “type". This gives us a dilemma that can be tackled in 1 of 3 ways imho:

  1.  I could split them into 2 separate service functions; let’s call them FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely upon the FW itself to determine which of the policy-set’s to apply using some out-of-scope for the SFC WG mechanism.
  2.  To avoid reclassification as indicated in (1) I could split each FW+policy-set into its own distinct service function; FW(a), FW(b), FW(c), and FW(d). The problem with this is that I could end up with a large number of distinct service functions.
  3.  I could let the SFC service encapsulation carry enough information for the FW to determine which of the policy-set’s a,b,c,d to apply to a given flow without needing to reclassify at the FW or split all of the FW+policy-set combinations into separate service functions. In other words I could simply have a service function with type “FW” and indicate the policy-set within the service encapsulation.

For me point (3) highlights pretty nicely one of the reasons for having an SFC service encapsulation.

From: Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 4:23 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>
Cc: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Paul Quinn <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi Jim,

Thanks,
Cathy

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Monday, February 10, 2014 1:08 PM
To: Cathy Zhang
Cc: Reinaldo Penno (repenno); Ron Parker; [email-masked]<mailto:[email-masked]>; Paul Quinn (paulq); sfc; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Sent from my iPhone

Thanks,
Cathy

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 10 Feb 2014 23:18:06 +0000

Yes, I agree (see previous post for logic).

From: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 5:30 PM
To: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, Jim Guichard <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Paul Quinn <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

IMHO:

Nicolas

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 10 Feb 2014 23:21:14 +0000

Hi Reinaldo,

Jim> not if you rely upon the service encapsulation to differentiate ;-)

Sent from my iPhone

Thanks,
Cathy

---

From: Ron Parker <[email-masked]>
Date: Mon, 10 Feb 2014 23:31:05 +0000

Approach 3 is the most elegant, but also the most costly in terms of the service header.  Rather than deriving both sequence and policy selection from the chain id that presumably appears in the service header, we would now need a stack of policy set identifiers that is pushed on by the classifier -- one for each service function in the chain.

   Ron

On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Cathy,

Hi Jim,

Thanks,
Cathy

Sent from my iPhone

Thanks,
Cathy

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 10 Feb 2014 23:31:46 +0000

Hi,

Inline with [RP]

From: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 3:17 PM
To: Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi Cathy,

Let’s take the FW example again. Suppose that I now have policy-set’s a,b,c, & d. Lets further suppose that policy-set’s a&b are available at service nodes 1, 2, 3 & 4 and policy-set’s c&d are available at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will not have the necessary policy to treat the traffic even though we have said they are of the same service function “type".

[RP] Since we are starting from different premises the results with different. We never said Service Functions with different policies have the same type.  All we said is that they have the capability to provide the same functionality,

This gives us a dilemma that can be tackled in 1 of 3 ways imho:

Hi Jim,

Thanks,
Cathy

Sent from my iPhone

Thanks,
Cathy

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 10 Feb 2014 23:53:50 +0000

You now have to manage a set of (service function + policy-set) tags in the data plane.  I call (service function + policy tag) = “service instance”. This allows me to still have a small number of service functions since those are decouple from the policy.

From: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 at 3:21 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi Reinaldo,

Sent from my iPhone

Thanks,
Cathy

---

From: "Pham, Chuong D" <[email-masked]>
Date: Tue, 11 Feb 2014 10:58:24 +1100

What is a policy set? Is it a virtual/logical firewall? Or is it what policies to apply to a traffic flow?

In any case, in approach 3, the classifier would need to know which FW owns which policy sets anyway unless the idea is having only one FW SF with all the policy sets in it. If the classifier needs to know the individual FW SFs, I think approach 1 and 2 in combination is more practical.

Effectively, there will be FW SF1, SF2...SFn in a network, depends on the need of that network. A FW SF may host multiple policy sets. It's the local choice and in this case, the FW will need to decide which policy set to use, just like the way it does today.

Regards,
Chuong

From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, 11 February 2014 10:31 AM
To: Jim Guichard (jguichar)
Cc: [email-masked]; Cathy Zhang; sfc; Paul Quinn (paulq); [email-masked]; Reinaldo Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

   Ron

let's take the FW example with policy-set-a and policy-set-b. If we treat the FW as a type of service function where policy-set-a and policy-set-b are instances of that "type" of service function then my point is that each of those could be located at multiple points in the network thereby giving you multiple "instances" of the policy-set-a "instance" and the policy-set-b "instance. I will argue that that is not the right way to look at it.. Let me explain my logic.

Let's take the FW example again. Suppose that I now have policy-set's a,b,c, & d. Lets further suppose that policy-set's a&b are available at service nodes 1, 2, 3 & 4 and policy-set's c&d are available at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will not have the necessary policy to treat the traffic even though we have said they are of the same service function "type". This gives us a dilemma that can be tackled in 1 of 3 ways imho:

 1.  I could split them into 2 separate service functions; let's call them FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely upon the FW itself to determine which of the policy-set's to apply using some out-of-scope for the SFC WG mechanism.
 2.  To avoid reclassification as indicated in (1) I could split each FW+policy-set into its own distinct service function; FW(a), FW(b), FW(c), and FW(d). The problem with this is that I could end up with a large number of distinct service functions.
 3.  I could let the SFC service encapsulation carry enough information for the FW to determine which of the policy-set's a,b,c,d to apply to a given flow without needing to reclassify at the FW or split all of the FW+policy-set combinations into separate service functions. In other words I could simply have a service function with type "FW" and indicate the policy-set within the service encapsulation.

Hi Jim,

Thanks,
Cathy

Sent from my iPhone

Thanks,
Cathy

---

From: Ron Parker <[email-masked]>
Date: Tue, 11 Feb 2014 01:05:36 +0000

Chuong

A policy set is simply the configuration.  What it means is service function specific.   For example, with NAT44, perhaps when some set of clients access some particular remote subnet, they should be NAT'd with a special pool of IP addresses, otherwise the generic pool of IP addresses.   But for some other set of clients, always use the generic pool.   This would be 2 policy sets (I'm open to better names for this).

Per our previous thread, you could chose to call this NAT44-A and NAT44-B and create the classifier policy rules such that the correct flows engage the correct chains and therefore the correct NAT functionality.  It may even be that both logical NAT instances are located with the same transport address.

Or, you could 1/2 the number of distinct chains by requiring that the NAT44 decide on its own, without an assist from the classifier, when to use the special pool.

I believe that both use cases are entirely valid and both should be supported.

  Ron

On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" <[email-masked]<mailto:[email-masked]>> wrote:

Effectively, there will be FW SF1, SF2…SFn in a network, depends on the need of that network. A FW SF may host multiple policy sets. It’s the local choice and in this case, the FW will need to decide which policy set to use, just like the way it does today.

Regards,
Chuong

Cc: [email-masked]<mailto:[email-masked]>; Cathy Zhang; sfc; Paul Quinn (paulq); [email-masked]<mailto:[email-masked]>; Reinaldo Penno (repenno)

   Ron

Hi Jim,

Thanks,
Cathy

Sent from my iPhone

Thanks,
Cathy

---

From: "Pham, Chuong D" <[email-masked]>
Date: Tue, 11 Feb 2014 13:55:11 +1100

Ron,

I would just simply call the policy set "policy" (the term used by a FW vendor we use in our network). There are many policies in the firewall (1000's) of them. I don't think it is scalable for the classifier to know all of these these policies. This would also require integration between each firewall vendor and the classifier's implementation for the two to understand the language. Note that a flow may find matches among multiple policies and the policies can be nested etc. What the classifier can do at a minimum is to have information related to which FW SF (physical, logical or virtual) should be included in the chain for a particular flow. If multiple FW SFs i.e. multiple virtualised FWs hosting different sets of policies designed for different tenant/networks reside at a same IP address then I can see a benefit of the classifier to specify the correct virtual firewall by name or similar semantics which is understood by the front-end of the virtualised firewall SF complex.

In any case, pointing to the specific policies within the policies configured on a FW (physical/logical/virtual) is not scalable or workable, IMHO.

Regards,
Chuong

From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, 11 February 2014 12:06 PM
To: Pham, Chuong D
Cc: Jim Guichard (jguichar); [email-masked]; Cathy Zhang; sfc; Paul Quinn (paulq); [email-masked]; Reinaldo Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Chuong

  Ron

Regards,
Chuong

   Ron

Hi Jim,

Thanks,
Cathy

Sent from my iPhone

Thanks,
Cathy

---

From: Ron Parker <[email-masked]>
Date: Tue, 11 Feb 2014 03:41:23 +0000

Chuong,

The reason I used policy set was precisely as you described.  Perhaps for tenant A there are a 1000 ACLs.   For tenant B, there are also 1000 , but 100 are different.   Just like in the 3gpp PCRF practical use cases, a "rulebase" is indicated for a subscriber, never the individual rules.   In the case where there are relatively few distinct rulebases (perhaps the mythical gold silver and bronze users each receive distinct treatment), treating the sf function+rulebase as a distinct logical instance could simplify the overall service orchestration by concentrating the rulebase selection in one place.   Another way to view this is that the policy may be evaluated at 2 levels -- first pick the set of classification rules using non-specified mechanisms, then apply the selected set of policy to the relevant traffic flows.   Of course this 2 level approach would be optional.  I'm not sure much needs to happen in the architecture except to ensure that multiple logical service functions, even of the same type, are allowed to have the same transport address (locator).

   Ron

On Feb 10, 2014, at 9:55 PM, "Pham, Chuong D" <[email-masked]<mailto:[email-masked]>> wrote:

Ron,

I would just simply call the policy set “policy” (the term used by a FW vendor we use in our network). There are many policies in the firewall (1000’s) of them. I don’t think it is scalable for the classifier to know all of these these policies. This would also require integration between each firewall vendor and the classifier’s implementation for the two to understand the language. Note that a flow may find matches among multiple policies and the policies can be nested etc. What the classifier can do at a minimum is to have information related to which FW SF (physical, logical or virtual) should be included in the chain for a particular flow. If multiple FW SFs i.e. multiple virtualised FWs hosting different sets of policies designed for different tenant/networks reside at a same IP address then I can see a benefit of the classifier to specify the correct virtual firewall by name or similar semantics which is understood by the front-end of the virtualised firewall SF complex.

Regards,
Chuong

From: Ron Parker [mailto:[email-masked]]
Sent: Tuesday, 11 February 2014 12:06 PM
To: Pham, Chuong D
Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>; Cathy Zhang; sfc; Paul Quinn (paulq); [email-masked]<mailto:[email-masked]>; Reinaldo Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Chuong

  Ron

Regards,
Chuong

   Ron

Hi Jim,

Thanks,
Cathy

Sent from my iPhone

Thanks,
Cathy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Feb 2014 23:20:20 -0500

This seems to be a distinction which will be made differently in 
different cases.  We ought not mandate that there be different service 
instances for different policies, but we also should not prohibit it.

The way we typically design IETF RFCs will lead naturally to the above 
result.  The general rule is taht as long as things interact properly, 
you can do whatever you want.  So one environment can have different 
service instances, on different chains, for different policies.  Another 
deployment may have a collection of instances, each of which can apply 
all the policies, and the collection may itself appear to service 
chaining as a single service function instance (as long as the steering 
can steer traffic to it.)

Yours,
Joel

On 2/10/14, 10:41 PM, Ron Parker wrote:
> Chuong,
>
> The reason I used policy set was precisely as you described.  Perhaps
> for tenant A there are a 1000 ACLs.   For tenant B, there are also 1000
> , but 100 are different.   Just like in the 3gpp PCRF practical use
> cases, a "rulebase" is indicated for a subscriber, never the individual
> rules.   In the case where there are relatively few distinct rulebases
> (perhaps the mythical gold silver and bronze users each receive distinct
> treatment), treating the sf function+rulebase as a distinct logical
> instance could simplify the overall service orchestration by
> concentrating the rulebase selection in one place.   Another way to view
> this is that the policy may be evaluated at 2 levels -- first pick the
> set of classification rules using non-specified mechanisms, then apply
> the selected set of policy to the relevant traffic flows.   Of course
> this 2 level approach would be optional.  I'm not sure much needs to
> happen in the architecture except to ensure that multiple logical
> service functions, even of the same type, are allowed to have the same
> transport address (locator).
>
>     Ron
>
>
>
> On Feb 10, 2014, at 9:55 PM, "Pham, Chuong D"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>> Ron,
>>
>> I would just simply call the policy set “policy” (the term used by a
>> FW vendor we use in our network). There are many policies in the
>> firewall (1000’s) of them. I don’t think it is scalable for the
>> classifier to know all of these these policies. This would also
>> require integration between each firewall vendor and the classifier’s
>> implementation for the two to understand the language. Note that a
>> flow may find matches among multiple policies and the policies can be
>> nested etc. What the classifier can do at a minimum is to have
>> information related to which FW SF (physical, logical or virtual)
>> should be included in the chain for a particular flow. If multiple FW
>> SFs i.e. multiple virtualised FWs hosting different sets of policies
>> designed for different tenant/networks reside at a same IP address
>> then I can see a benefit of the classifier to specify the correct
>> virtual firewall by name or similar semantics which is understood by
>> the front-end of the virtualised firewall SF complex.
>>
>> In any case, pointing to the specific policies within the policies
>> configured on a FW (physical/logical/virtual) is not scalable or
>> workable, IMHO.
>>
>> Regards,
>>
>> Chuong
>>
>> *From:*Ron Parker [mailto:[email-masked]]
>> *Sent:* Tuesday, 11 February 2014 12:06 PM
>> *To:* Pham, Chuong D
>> *Cc:* Jim Guichard (jguichar); [email-masked] <mailto:[email-masked]>;
>> Cathy Zhang; sfc; Paul Quinn (paulq); [email-masked]
>> <mailto:[email-masked]>; Reinaldo Penno (repenno)
>> A policy set is simply the configuration.  What it means is service
>> function specific.   For example, with NAT44, perhaps when some set of
>> clients access some particular remote subnet, they should be NAT'd
>> with a special pool of IP addresses, otherwise the generic pool of IP
>> addresses.   But for some other set of clients, always use the generic
>> pool.   This would be 2 policy sets (I'm open to better names for this).
>>
>> Per our previous thread, you could chose to call this NAT44-A and
>> NAT44-B and create the classifier policy rules such that the correct
>> flows engage the correct chains and therefore the correct NAT
>> functionality.  It may even be that both logical NAT instances are
>> located with the same transport address.
>>
>> Or, you could 1/2 the number of distinct chains by requiring that the
>> NAT44 decide on its own, without an assist from the classifier, when
>> to use the special pool.
>>
>> On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D"
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     What is a policy set? Is it a virtual/logical firewall? Or is it
>>     what policies to apply to a traffic flow?
>>
>>     In any case, in approach 3, the classifier would need to know
>>     which FW owns which policy sets anyway unless the idea is having
>>     only one FW SF with all the policy sets in it. If the classifier
>>     needs to know the individual FW SFs, I think approach 1 and 2 in
>>     combination is more practical.
>>
>>     Effectively, there will be FW SF1, SF2…SFn in a network, depends
>>     on the need of that network. A FW SF may host multiple policy
>>     sets. It’s the local choice and in this case, the FW will need to
>>     decide which policy set to use, just like the way it does today.
>>
>>     Regards,
>>
>>     Chuong
>>
>>     *From:*Ron Parker [mailto:[email-masked]]
>>     *Sent:* Tuesday, 11 February 2014 10:31 AM
>>     *To:* Jim Guichard (jguichar)
>>     *Cc:* [email-masked] <mailto:[email-masked]>; Cathy Zhang; sfc; Paul
>>     Quinn (paulq); [email-masked] <mailto:[email-masked]>;
>>     Reinaldo Penno (repenno)
>>     Approach 3 is the most elegant, but also the most costly in terms
>>     of the service header.  Rather than deriving both sequence and
>>     policy selection from the chain id that presumably appears in the
>>     service header, we would now need a stack of policy set
>>     identifiers that is pushed on by the classifier -- one for each
>>     service function in the chain.
>>
>>        Ron
>>
>>
>>     On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)"
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Hi Cathy,
>>
>>         let’s take the FW example with policy-set-a and policy-set-b.
>>         If we treat the FW as a type of service function where
>>         policy-set-a and policy-set-b are instances of that “type" of
>>         service function then my point is that each of those could be
>>         located at multiple points in the network thereby giving you
>>         multiple “instances” of the policy-set-a “instance” and the
>>         policy-set-b “instance. I will argue that that is not the
>>         right way to look at it.. Let me explain my logic.
>>
>>         Let’s take the FW example again. Suppose that I now have
>>         policy-set’s a,b,c, & d. Lets further suppose that
>>         policy-set’s a&b are available at service nodes 1, 2, 3 & 4
>>         and policy-set’s c&d are available at service nodes 5, 6 & 7.
>>         Given this, when I instantiate an SFC that requires say
>>         policy-set-a, I cannot send the traffic to service nodes 5, 6
>>         or 7 as they will not have the necessary policy to treat the
>>         traffic *even though* we have said they are of the same
>>         service function “type". This gives us a dilemma that can be
>>         tackled in 1 of 3 ways imho:
>>
>>          1. I could split them into 2 separate service functions;
>>             let’s call them FW(a,b) & FW(c,d). Now the problem with
>>             this is that now I have to rely upon the FW itself to
>>             determine which of the policy-set’s to apply using some
>>             out-of-scope for the SFC WG mechanism.
>>          2. To avoid reclassification as indicated in (1) I could
>>             split each FW+policy-set into its own distinct service
>>             function; FW(a), FW(b), FW(c), and FW(d). The problem with
>>             this is that I could end up with a large number of
>>             distinct service functions.
>>          3. I could let the SFC service encapsulation carry enough
>>             information for the FW to determine which of the
>>             policy-set’s a,b,c,d to apply to a given flow
>>             *without* needing to reclassify at the FW *or* split all
>>             of the FW+policy-set combinations into separate service
>>             functions. In other words I could simply have a service
>>             function with type “FW” and indicate the policy-set within
>>             the service encapsulation.
>>
>>         *From: *Cathy Zhang <[email-masked]
>>         <mailto:[email-masked]>>
>>         *Date: *Monday, February 10, 2014 at 4:23 PM
>>         *To: *Jim Guichard <[email-masked]
>>         *Cc: *"Reinaldo Penno (repenno)" <[email-masked]
>>         <mailto:[email-masked]>>, Ron Parker
>>         <[email-masked]
>>         <mailto:[email-masked]>>,
>>         "[email-masked] <mailto:[email-masked]>"
>>         <[email-masked] <mailto:[email-masked]>>, Paul
>>         Quinn <[email-masked] <mailto:[email-masked]>>, sfc
>>         <[email-masked] <mailto:[email-masked]>>,
>>         <mailto:[email-masked]>>
>>         *Subject: *RE: [sfc] Fwd: New Version Notification for
>>         *From:*Jim Guichard (jguichar) [mailto:[email-masked]]
>>         *Sent:* Monday, February 10, 2014 1:08 PM
>>         *To:* Cathy Zhang
>>         *Cc:* Reinaldo Penno (repenno); Ron Parker;
>>         [email-masked] <mailto:[email-masked]>; Paul Quinn
>>         (paulq); sfc; [email-masked] <mailto:[email-masked]>
>>         How would you represent an instance of a service function
>>         instance? Seems more logical to represent a service function
>>         type that provides function based on policy set as an
>>         independent service function.
>>
>>         Sent from my iPhone
>>
>>
>>         On Feb 10, 2014, at 3:55 PM, "Cathy Zhang"
>>         <[email-masked] <mailto:[email-masked]>>
>>         wrote:
>>
>>             I think each Service Function is associated with a type,
>>             such as FW Service Function or NAT Service Function
>>
>>             while each Service Instance is an instantiation of a
>>             Service Function on a Service Node and is  associated with
>>             a specific policy profile/set of that type of Service
>>             Function.
>>
>>             In a SFC admin domain, there could be multiple Service
>>             Nodes (physical/virtual) that support a specific Service
>>             Function, such as FW,
>>
>>             and a service instance could be instantiated on any one of
>>             the Service Nodes (as to which Service Node to instantiate
>>             the service instance,
>>
>>             Multiple flow chains can be associated with the same
>>             Service Instance on a Service Node, which means these
>>             flows will be applied the same policy set
>>
>>             BTW, I would like to suggest that the draft adds a
>>             definition for “Service Instance” to bring everyone on the
>>             same page as to its semantics.
>>
>>             Thanks,
>>
>>             Cathy
>>
>>
>>             *From:*sfc [mailto:[email-masked]] *On Behalf Of
>>             *Reinaldo Penno (repenno)
>>             *To:* Jim Guichard (jguichar); Ron Parker;
>>             [email-masked] <mailto:[email-masked]>
>>             <mailto:[email-masked]>
>>             The same service function could be instantiated with
>>              policy-set-A and later instantiated with  policy-set-B.
>>             It is still the same service function, but different
>>             instances.
>>
>>             Therefore I would consider {1 below} one service function
>>             (say, NAT44) and two different service function instances,
>>             one that applies  policy-set-A and other that applies
>>              policy-set-A.
>>
>>             <[email-masked] <mailto:[email-masked]>>,
>>             "[email-masked] <mailto:[email-masked]>"
>>             <[email-masked] <mailto:[email-masked]>>
>>             *Cc: *"Paul Quinn (paulq)" <[email-masked]
>>             <mailto:[email-masked]>>, "[email-masked]
>>             <mailto:[email-masked]>" <[email-masked]
>>              1. A service function that applies policy-set-A and a
>>                 different service function that applies policy-set-B
>>                 e.g. They are two distinct service functions.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Tue, 11 Feb 2014 17:40:05 +0800

Hi Jim,

  Inline with [MW].

Thanks,
Wei Meng

"Jim Guichard (jguichar)" <[email-masked]> 写于 2014-02-11 07:17:27:

> Hi Cathy,
> 
> let’s take the FW example with policy-set-a and policy-set-b. If we 
> treat the FW as a type of service function where policy-set-a and 
> policy-set-b are instances of that “type" of service function then 
> my point is that each of those could be located at multiple points 
> in the network thereby giving you multiple “instances” of the 
> policy-set-a “instance” and the policy-set-b “instance. I will argue
> that that is not the right way to look at it.. Let me explain my logic.
> 
> Let’s take the FW example again. Suppose that I now have policy-set’
> s a,b,c, & d. Lets further suppose that policy-set’s a&b are 
> available at service nodes 1, 2, 3 & 4 and policy-set’s c&d are 
> available at service nodes 5, 6 & 7. Given this, when I instantiate 
> an SFC that requires say policy-set-a, I cannot send the traffic to 
> service nodes 5, 6 or 7 as they will not have the necessary policy 
> to treat the traffic even though we have said they are of the same 
> service function “type". This gives us a dilemma that can be tackled
> in 1 of 3 ways imho:
> 1. I could split them into 2 separate service functions; let’s call 
> them FW(a,b) & FW(c,d). Now the problem with this is that now I have
> to rely upon the FW itself to determine which of the policy-set’s to
> apply using some out-of-scope for the SFC WG mechanism. 
> 2. To avoid reclassification as indicated in (1) I could split each 
> FW+policy-set into its own distinct service function; FW(a), FW(b), 
> FW(c), and FW(d). The problem with this is that I could end up with 
> a large number of distinct service functions.

[MW] "The problem with this is that I could end up with a large number
of distinct service functions. " How large ? 100? 1000? It may be 
within acceptable limits.
    It seems to me that "spliting each FW+policy-set into its own distinct
service function" is a concise way to define service function.FW OR NAT is 

just the service type rather than service function. 

    IMO, service functions are configured & deployed by operators. The
granularity could be determined by operators .
    Actually, granularity of SFs is the bone of our contention.

> information for the FW to determine which of the policy-set’s a,b,c,
> d to apply to a given flow without needing to reclassify at the FW or
> split all of the FW+policy-set combinations into separate service 
> functions. In other words I could simply have a service function 
> with type “FW” and indicate the policy-set within the service 
encapsulation.
> From: Cathy Zhang <[email-masked]>
> To: Jim Guichard <[email-masked]>
> Cc: "Reinaldo Penno (repenno)" <[email-masked]>, Ron Parker <
> [email-masked]>, "[email-masked]" 
<[email-masked]
> >, Paul Quinn <[email-masked]>, sfc <[email-masked]>, 
"[email-masked]" <
> [email-masked]>
> Could you clarify what you mean by an instance of a service 
functioninstance?
> How would you represent an instance of a service function instance? 
> Seems more logical to represent a service function type that 
> provides function based on policy set as an independent service 
function.
> 
> Sent from my iPhone
> 
> On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <[email-masked]> 
wrote:
> while each Service Instance is an instantiation of a Service 
> Function on a Service Node and is  associated with a specific policy
> profile/set of that type of Service Function. 

> and a service instance could be instantiated on any one of the 
> Service Nodes (as to which Service Node to instantiate the service 
instance, 
> Multiple flow chains can be associated with the same Service 
> Instance on a Service Node, which means these flows will be applied 
> the same policy set 
> The same service function could be instantiated with  policy-set-A 
> and later instantiated with  policy-set-B. It is still the same 
> service function, but different instances. 
> 
> Therefore I would consider {1 below} one service function (say, 
> NAT44) and two different service function instances, one that 
> applies  policy-set-A and other that applies  policy-set-A.
> 
> From: "Jim Guichard (jguichar)" <[email-masked]>
> To: Ron Parker <[email-masked]>, Cisco Employee <
> [email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "Paul Quinn (paulq)" <[email-masked]>, "[email-masked]" <[email-masked]
> >, sfc <[email-masked]>
> 1. A service function that applies policy-set-A and a different 
> service function that applies policy-set-B e.g. They are two

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 11 Feb 2014 13:00:21 +0000

I agree Joel; I tried to layout the options in previous emails and IMO all options are valid and an implementer may do whichever they choose.

Sent from my iPhone

> On Feb 10, 2014, at 11:20 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> This seems to be a distinction which will be made differently in different cases.  We ought not mandate that there be different service instances for different policies, but we also should not prohibit it.
> 
> The way we typically design IETF RFCs will lead naturally to the above result.  The general rule is taht as long as things interact properly, you can do whatever you want.  So one environment can have different service instances, on different chains, for different policies.  Another deployment may have a collection of instances, each of which can apply all the policies, and the collection may itself appear to service chaining as a single service function instance (as long as the steering can steer traffic to it.)
> 
> Yours,
> Joel
> 
>>>        function instance?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 11:35:29 -0500

Thank you Jim.

If folks think that the definitions in the archtiecture document (or any 
of our other documents) prohibit this degree of flexibility, then I 
would suggest that we fix the definitions.  For me, this seems to be 
supported by the definitions we are using.

Yours,
Joel

On 2/11/14, 8:00 AM, Jim Guichard (jguichar) wrote:
> I agree Joel; I tried to layout the options in previous emails and
> IMO all options are valid and an implementer may do whichever they
> choose.
>
> Sent from my iPhone
>
>> different cases.  We ought not mandate that there be different
>> service instances for different policies, but we also should not
>> prohibit it.
>>
>> The way we typically design IETF RFCs will lead naturally to the
>> above result.  The general rule is taht as long as things interact
>> properly, you can do whatever you want.  So one environment can
>> have different service instances, on different chains, for
>> different policies.  Another deployment may have a collection of
>> instances, each of which can apply all the policies, and the
>> collection may itself appear to service chaining as a single
>> service function instance (as long as the steering can steer
>> traffic to it.)
>>
>> Yours, Joel
>>
>>> On 2/10/14, 10:41 PM, Ron Parker wrote: Chuong,
>>>
>>> The reason I used policy set was precisely as you described.
>>> Perhaps for tenant A there are a 1000 ACLs.   For tenant B, there
>>> are also 1000 , but 100 are different.   Just like in the 3gpp
>>> PCRF practical use cases, a "rulebase" is indicated for a
>>> subscriber, never the individual rules.   In the case where there
>>> are relatively few distinct rulebases (perhaps the mythical gold
>>> silver and bronze users each receive distinct treatment),
>>> treating the sf function+rulebase as a distinct logical instance
>>> could simplify the overall service orchestration by concentrating
>>> the rulebase selection in one place.   Another way to view this
>>> is that the policy may be evaluated at 2 levels -- first pick
>>> the set of classification rules using non-specified mechanisms,
>>> then apply the selected set of policy to the relevant traffic
>>> flows.   Of course this 2 level approach would be optional.  I'm
>>> not sure much needs to happen in the architecture except to
>>> ensure that multiple logical service functions, even of the same
>>> type, are allowed to have the same transport address (locator).
>>>
>>> Ron
>>>
>>>
>>>
>>>> I would just simply call the policy set “policy” (the term used
>>>> by a FW vendor we use in our network). There are many policies
>>>> in the firewall (1000’s) of them. I don’t think it is scalable
>>>> for the classifier to know all of these these policies. This
>>>> would also require integration between each firewall vendor and
>>>> the classifier’s implementation for the two to understand the
>>>> language. Note that a flow may find matches among multiple
>>>> policies and the policies can be nested etc. What the
>>>> classifier can do at a minimum is to have information related
>>>> to which FW SF (physical, logical or virtual) should be
>>>> included in the chain for a particular flow. If multiple FW SFs
>>>> i.e. multiple virtualised FWs hosting different sets of
>>>> policies designed for different tenant/networks reside at a
>>>> same IP address then I can see a benefit of the classifier to
>>>> specify the correct virtual firewall by name or similar
>>>> semantics which is understood by the front-end of the
>>>> virtualised firewall SF complex.
>>>>
>>>> In any case, pointing to the specific policies within the
>>>> policies configured on a FW (physical/logical/virtual) is not
>>>> scalable or workable, IMHO.
>>>>
>>>> Regards,
>>>>
>>>> Chuong
>>>>
>>>> *Sent:* Tuesday, 11 February 2014 12:06 PM *To:* Pham, Chuong
>>>> D *Cc:* Jim Guichard (jguichar); [email-masked]
>>>> <mailto:[email-masked]>; Cathy Zhang; sfc; Paul Quinn (paulq);
>>>> [email-masked] <mailto:[email-masked]>; Reinaldo
>>>> Penno (repenno) *Subject:* Re: [sfc] Fwd: New Version
>>>> Notification for draft-quinn-sfc-arch-04.txt
>>>>
>>>> Chuong
>>>>
>>>> A policy set is simply the configuration.  What it means is
>>>> service function specific.   For example, with NAT44, perhaps
>>>> when some set of clients access some particular remote subnet,
>>>> they should be NAT'd with a special pool of IP addresses,
>>>> otherwise the generic pool of IP addresses.   But for some
>>>> other set of clients, always use the generic pool.   This would
>>>> be 2 policy sets (I'm open to better names for this).
>>>>
>>>> Per our previous thread, you could chose to call this NAT44-A
>>>> and NAT44-B and create the classifier policy rules such that
>>>> the correct flows engage the correct chains and therefore the
>>>> correct NAT functionality.  It may even be that both logical
>>>> NAT instances are located with the same transport address.
>>>>
>>>> Or, you could 1/2 the number of distinct chains by requiring
>>>> that the NAT44 decide on its own, without an assist from the
>>>> classifier, when to use the special pool.
>>>>
>>>> What is a policy set? Is it a virtual/logical firewall? Or is
>>>> it what policies to apply to a traffic flow?
>>>>
>>>> which FW owns which policy sets anyway unless the idea is
>>>> having only one FW SF with all the policy sets in it. If the
>>>> classifier needs to know the individual FW SFs, I think
>>>> approach 1 and 2 in combination is more practical.
>>>>
>>>> Effectively, there will be FW SF1, SF2…SFn in a network,
>>>> depends on the need of that network. A FW SF may host multiple
>>>> policy sets. It’s the local choice and in this case, the FW
>>>> will need to decide which policy set to use, just like the way
>>>> it does today.
>>>>
>>>> Regards,
>>>>
>>>> Chuong
>>>>
>>>> *Sent:* Tuesday, 11 February 2014 10:31 AM *To:* Jim Guichard
>>>> (jguichar) *Cc:* [email-masked] <mailto:[email-masked]>; Cathy
>>>> Zhang; sfc; Paul Quinn (paulq); [email-masked]
>>>> Approach 3 is the most elegant, but also the most costly in
>>>> terms of the service header.  Rather than deriving both
>>>> sequence and policy selection from the chain id that presumably
>>>> appears in the service header, we would now need a stack of
>>>> policy set identifiers that is pushed on by the classifier --
>>>> one for each service function in the chain.
>>>>
>>>> Ron
>>>>
>>>>
>>>> policy-set-b “instance. I will argue that that is not the right
>>>> way to look at it.. Let me explain my logic.
>>>>
>>>> policy-set’s a,b,c, & d. Lets further suppose that policy-set’s
>>>> a&b are available at service nodes 1, 2, 3 & 4 and policy-set’s
>>>> c&d are available at service nodes 5, 6 & 7. Given this, when I
>>>> instantiate an SFC that requires say policy-set-a, I cannot
>>>> send the traffic to service nodes 5, 6 or 7 as they will not
>>>> have the necessary policy to treat the traffic *even though* we
>>>> have said they are of the same service function “type". This
>>>> gives us a dilemma that can be tackled in 1 of 3 ways imho:
>>>>
>>>> 1. I could split them into 2 separate service functions; let’s
>>>> call them FW(a,b) & FW(c,d). Now the problem with this is that
>>>> now I have to rely upon the FW itself to determine which of the
>>>> policy-set’s to apply using some out-of-scope for the SFC WG
>>>> mechanism. 2. To avoid reclassification as indicated in (1) I
>>>> could split each FW+policy-set into its own distinct service
>>>> function; FW(a), FW(b), FW(c), and FW(d). The problem with this
>>>> is that I could end up with a large number of distinct service
>>>> functions. 3. I could let the SFC service encapsulation carry
>>>> enough information for the FW to determine which of the
>>>> policy-set’s a,b,c,d to apply to a given flow *without* needing
>>>> to reclassify at the FW *or* split all of the FW+policy-set
>>>> combinations into separate service functions. In other words I
>>>> could simply have a service function with type “FW” and
>>>> indicate the policy-set within the service encapsulation.
>>>>
>>>> <mailto:[email-masked]>> *Date: *Monday, February 10,
>>>> 2014 at 4:23 PM *To: *Jim Guichard <[email-masked]
>>>> <mailto:[email-masked]>> *Cc: *"Reinaldo Penno (repenno)"
>>>> <[email-masked] <mailto:[email-masked]>>, Ron Parker
>>>> <mailto:[email-masked]>> *Subject: *RE: [sfc] Fwd: New Version
>>>> Notification for draft-quinn-sfc-arch-04.txt
>>>>
>>>> Hi Jim,
>>>>
>>>> *Sent:* Monday, February 10, 2014 1:08 PM *To:* Cathy Zhang
>>>> (paulq); sfc; [email-masked] <mailto:[email-masked]> *Subject:* Re:
>>>> [sfc] Fwd: New Version Notification for
>>>> I think each Service Function is associated with a type, such
>>>> as FW Service Function or NAT Service Function
>>>>
>>>> Function on a Service Node and is  associated with a specific
>>>> policy profile/set of that type of Service Function.
>>>>
>>>> Service Nodes (as to which Service Node to instantiate the
>>>> service instance,
>>>>
>>>> Instance on a Service Node, which means these flows will be
>>>> applied the same policy set
>>>>
>>>> BTW, I would like to suggest that the draft adds a definition
>>>> for “Service Instance” to bring everyone on the same page as to
>>>> its semantics.
>>>>
>>>> Thanks,
>>>>
>>>> Cathy
>>>>
>>>>
>>>> *Reinaldo Penno (repenno) *Sent:* Monday, February 10, 2014
>>>> 12:22 PM *To:* Jim Guichard (jguichar); Ron Parker;
>>>> [email-masked] <mailto:[email-masked]> *Cc:* Paul
>>>> Quinn (paulq); sfc; [email-masked] <mailto:[email-masked]>
>>>> policy-set-A and later instantiated with  policy-set-B. It is
>>>> still the same service function, but different instances.
>>>>
>>>> <mailto:[email-masked]>> *Date: *Monday, February 10, 2014
>>>> at 11:12 AM *To: *Ron Parker <[email-masked]
>>>> <[email-masked] <mailto:[email-masked]>> *Cc:
>>>> *"Paul Quinn (paulq)" <[email-masked]
>>>> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
>>>> <[email-masked] <mailto:[email-masked]>>, sfc
>>>> <[email-masked] <mailto:[email-masked]>> *Subject:
>>>> *Re: [sfc] Fwd: New Version Notification for
>>>> _______________________________________________ sfc mailing
>>>> list [email-masked] <mailto:[email-masked]>
>>> _______________________________________________ sfc mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>>
>