Subject: Re: [sfc] SF and SFC awareness

From: "[email-masked]" <[email-masked]>
Date: Thu, 11 Dec 2014 10:17:48 -0500

So far, the only references I've seen to SF awareness has been wrt fully aware SFs and discussions around proxies for SFC-unaware SFs (a).  As the SF can process the header (c), I believe that it can be considered to be SFC-aware.  Each SF, however, might support varying degrees of SFC features. e.g. most SFC-aware DPIs will probably also support reclassification.
I haven't seen anything in the drafts that would prohibit (e) (or any of the options for that matter).
There is also a proposed mechanism for the SF to provide feedback to influence classification.
see: http://tools.ietf.org/html/draft-ww-sfc-control-plane-03

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>
Sent: Thursday, November 13, 2014
Subject: [sfc] SF and SFC awareness

Hi,

I just recently joined the SFC mailing list and catching up on SFC drafts.

Please bear with me if these questions have been already discussed.

A basic question on SFC architecture (draft-ietf-sfc-architecture-02.txt)

To what extent an SF should be aware of SFC or SFP.

The possible scenarios I see are

a)    SF is completely unaware of SFC/SFP that it is participating in.  Many existing SF functions may fall in this category.

b)    SF is aware of  SFP to the extent that it can support a simple construct such an interface-pair per SFP (left interface, right interface), where SF will take responsibility to ensure packets arriving on the left interface will be sent to right interface and vice-versa. SF itself is not aware of SFP beyond following the rules of the simple construct (interface-pair).

c)    SF is aware of  SFP by  being able to parse and preserve a special header (nsh) to gleam information about the SFP it is participating in and reflecting it back to SFF when transmitting the packets.

d)    SF is aware of SFC as a opaque entity through OAM and can pick an SFC (opaque value) through policy decisions. 

e)    SF is aware of SFC details through OAM  and can influence the selection of  next SF through policy decisions. 

The question I have is

-    Is there a need for option e) where SF is aware of next SF in SFC? Should just treating SFC as a opaque value is sufficient?

If these points are already described in some draft please point me to it.

Thanks,

Sankar

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

---

From: Ron Parker <[email-masked]>
Date: Thu, 11 Dec 2014 15:42:01 +0000

Sankar,

I think the most useful things the SFC-aware SF does wrt the SFC encapsulation knowledge would be:

a)      Use the SFC Path ID as a key for local policy selection

b)      Read and insert metadata

c)      Participate in some SFC OAM procedures

While it could also use the SFC Path ID to know which SF type is next in the sequence, I think such knowledge could be abstracted down to use case a) above – drive the local behavior based on the Path ID.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 11, 2014 10:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] SF and SFC awareness

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
Sent: Thursday, November 13, 2014
Subject: [sfc] SF and SFC awareness

Hi,

The question I have is

Thanks,

Sankar

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

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 12 Dec 2014 01:44:13 +0000

Hi Ron,

As for 1), would you please give a real use case where SFC Path ID would be used as a key for local policy selection?

Best regards,
Xiaohu

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, December 11, 2014 11:42 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] SF and SFC awareness

Sankar,

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, December 11, 2014 10:18 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SF and SFC awareness

Hi,

The question I have is

Thanks,

Sankar

---

From: Ron Parker <[email-masked]>
Date: Fri, 12 Dec 2014 01:53:08 +0000

Xiaohu,

Consider an SF for HTTP content filtering.   Let's say that there is a single instance of a server that is capable of providing either pre-adolescent or adolescent content filtering.   From an SFC perspective, we can model this as 2 distinct logical service functions -- content-filter-pre-adolescent and content-filter-adolescent.   But, these 2 logical service functions are realized by exactly 1 running instance of an entity that is capable of performing content filtering.   Now, we can have SFP 1 whose sequence is {pre-adolescent-content-filter, firewall} and SFP 2 whose sequence is {adolescent-content-filter, firewall}.   The SFF would know that both logical functions are realized by the same addressable entity (i.e., it is not necessary to use 2 distinct network locators).   When packets are progressed from SFF to the server, it can know whether to provide pre-adolescent or adolescent content filtering based on the SFP ID.

Thanks.

   Ron

________________________________
From: Xuxiaohu [[email-masked]]
Sent: Thursday, December 11, 2014 8:44 PM
To: Ron Parker; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] SF and SFC awareness

Hi Ron,

Best regards,
Xiaohu

Sankar,

   Ron

Hi,

The question I have is

Thanks,

Sankar

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 12 Dec 2014 02:00:52 +0000

Hi Ron,

Why not specify the following 2 logical service functions as two separate SFs? In this way, SFs are SFP-irrelevant and therefore they could be legacy SFs.

Best regards,
Xiaohu

From: Ron Parker [mailto:[email-masked]]
Sent: Friday, December 12, 2014 9:53 AM
To: Xuxiaohu; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] SF and SFC awareness

Xiaohu,

Thanks.

   Ron

To: Ron Parker; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Best regards,
Xiaohu

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Sankar,

While it could also use the SFC Path ID to know which SF type is next in the sequence, I think such knowledge could be abstracted down to use case a) above - drive the local behavior based on the Path ID.

   Ron

Hi,

The question I have is

Thanks,

Sankar

---

From: Ron Parker <[email-masked]>
Date: Fri, 12 Dec 2014 02:05:48 +0000

The realization of multiple SF's by the same server is neither required nor prohibited.   In the case where one chooses to support multiple SF's with the same network locator, the SFP ID would allow determination of which logical SF is being invoked.   Whether you choose to think of this as 2 distinct policies of the same generic function or whether you think of this as 2 unrelated SF's is simply a matter of perspective.   Personally, I find it useful to consider that a generalized SF can be modeled as multiple logical SF's (each visible to SFC) that differ only in their policy settings.

   Ron

________________________________
From: sfc [[email-masked]] on behalf of Xuxiaohu [[email-masked]]
Sent: Thursday, December 11, 2014 9:00 PM
To: Ron Parker; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] SF and SFC awareness

Hi Ron,

Best regards,
Xiaohu

Xiaohu,

Thanks.

   Ron

Best regards,
Xiaohu

Sankar,

   Ron

Hi,

The question I have is

Thanks,

Sankar

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 12 Dec 2014 02:23:11 +0000

Hi Ron,

IMHO, if there is no strong reason for using a single locator for multiple SFs, we'd better avoid that. Otherwise, it makes the SFC architecture a little bit ugly, for instance, it makes the SF to unnecessarily have some functionalities of the SFF (e.g., using the SFP ID to determine the next logical SF) otherwise and makes the legacy SFs inapplicable anymore. In other words, we should always consider how to make the legacy SFs work well in the SFC architecture.

Best regards,
Xiaohu

From: Ron Parker [mailto:[email-masked]]
Sent: Friday, December 12, 2014 10:06 AM
To: Xuxiaohu; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] SF and SFC awareness

   Ron

Best regards,
Xiaohu

To: Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Xiaohu,

Thanks.

   Ron

Best regards,
Xiaohu

Sankar,

   Ron

Hi,

The question I have is

Thanks,

Sankar

---

From: Ron Parker <[email-masked]>
Date: Fri, 12 Dec 2014 02:47:11 +0000

Xiaohu,

Whether the justification I provided rises to the level of a "strong reason" is a matter of opinion and you are certainly entitled to yours.

I'll also point you to the SF definition in the architecture spec (https://tools.ietf.org/html/draft-ietf-sfc-architecture-02):

   Service Function (SF):  A function that is responsible for specific
        treatment of received packets.  A Service Function can act at
        various layers of a protocol stack (e.g., at the network layer
        or other OSI layers).  As a logical component, a Service
        Function can be realized as a virtual element or be embedded in
        a physical network element.  One or multiple Service Functions
        can be embedded in the same network element.

  Ron

Sent: Thursday, December 11, 2014 9:23 PM

Hi Ron,

IMHO, if there is no strong reason for using a single locator for multiple SFs, we’d better avoid that. Otherwise, it makes the SFC architecture a little bit ugly, for instance, it makes the SF to unnecessarily have some functionalities of the SFF (e.g., using the SFP ID to determine the next logical SF) otherwise and makes the legacy SFs inapplicable anymore. In other words, we should always consider how to make the legacy SFs work well in the SFC architecture.

Best regards,
Xiaohu

   Ron

Best regards,
Xiaohu

Xiaohu,

Thanks.

   Ron

Best regards,
Xiaohu

Sankar,

   Ron

Hi,

The question I have is

Thanks,

Sankar

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Dec 2014 14:31:18 -0500

Just a minor point, in terms of the architecture if an SF performs its 
own classification and rewrites the path ID then it is an SF with a 
collocated Classifier and probably a collocated SFF for handling the 
results of the classification.  This is permitted by the archtiecture.

Yours,
Joel

On 12/11/14, 10:17 AM, [email-masked] wrote:
> So far, the only references I've seen to SF awareness has been wrt fully
> aware SFs and discussions around proxies for SFC-unaware SFs (a).  As
> the SF can process the header (c), I believe that it can be considered
> to be SFC-aware.  Each SF, however, might support varying degrees of SFC
> features. e.g. most SFC-aware DPIs will probably also support
> reclassification.
>
> ------------------------------------------------------------------------
> *From: [email-masked]<[email-masked]>
> *To: [email-masked]<[email-masked]>
> *Sent: *Thursday, November 13, 2014
> *Subject: *[sfc] SF and SFC awareness
>
>
>
> Hi,
>
> a)    SF is completely unaware of SFC/SFP that it is participating in.
> Many existing SF functions may fall in this category.
>
> b)    SF is aware of SFP to the extent that it can support a simple
> construct such an interface-pair per SFP (left interface, right
> interface), where SF will take responsibility to ensure packets arriving
> on the left interface will be sent to right interface and vice-versa. SF
> itself is not aware of SFP beyond following the rules of the simple
> construct (interface-pair).
>
> c)    SF is aware of SFP by being able to parse and preserve a special
> header (nsh) to gleam information about the SFP it is participating in
> and reflecting it back to SFF when transmitting the packets.
>
> d)    SF is aware of SFC as a opaque entity through OAM and can pick an
> SFC (opaque value) through policy decisions.
>
> e)    SF is aware of SFC details through OAM and can influence the
> selection of next SF through policy decisions.
>
> The question I have is
>
> -    Is there a need for option e) where SF is aware of next SF in SFC?
> Should just treating SFC as a opaque value is sufficient?
>
>
> [email-masked] <mailto:[email-masked]>