Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

From: <[email-masked]>
Date: Wed, 12 Feb 2014 10:49:27 +0100

Dear all,

This new version integrates inputs from NTT representatives. 

The diff can be tracked here: http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01&difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 12 février 2014 10:46
À : [email-masked]
Objet : I-D Action: draft-boucadair-sfc-requirements-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Requirements for Service Function Chaining
        Authors         : Mohamed Boucadair
                          Christian Jacquenet
                          Yuanlong Jiang
                          Ron Parker
                          Carlos Pignataro
                          Kengo Naito
	Filename        : draft-boucadair-sfc-requirements-03.txt
	Pages           : 14
	Date            : 2014-02-12

Abstract:
   This document identifies the requirements for the Service Function
   Chaining (SFC).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Dave Dolson <[email-masked]>
Date: Fri, 14 Feb 2014 22:17:34 +0000

Reading through this...

I wondering about the Discovery requirements, and wondering if they should be separated from the forwarding requirements.
I.e., can we accept a standard on the forwarding plane without addressing these discovery elements (yet) ?

Just as routing can be accomplished with manual configuration, couldn't the same be said of SFC?

And I suspect some operators would want to have a highly-controlled orchestration approach, not an auto-discovery approach.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 12, 2014 4:49 AM
To: [email-masked]
Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Dear all,

Cheers,
Med

-----Message d'origine-----

Abstract:

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

---

From: <[email-masked]>
Date: Mon, 17 Feb 2014 15:15:22 +0100

Dear Dave, 

Thank you for the comment and for raising this point. 

As you can notice in Section 3, SF discovery is a SHOULD not a MUST. The detailed discovery required applied ** only ** when such a solution is to be deployed.

An SFC solution can be deployed without such feature. FWIW, the SFC architecture defined in http://tools.ietf.org/html/draft-boucadair-sfc-framework-02   says the following:

   o  For the sake of efficiency, policy enforcement is automated (but
      policies can be statically enforced, for example).

BTW, one could even argue that a basic SFC solution must work without requiring any control plane at all. Just like Diffserv architecture!

We didn't added an explicit requirement for the static/manual config because we thought the "SHOULD" language is an implicit indication.

Do you think this should be explicated in the requirement list?

Cheers,
Med

>De : Dave Dolson [mailto:[email-masked]]
>Envoyé : vendredi 14 février 2014 23:18
>À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
>Objet : RE: I-D Action: draft-boucadair-sfc-requirements-03.txt
>
>Reading through this...
>
>I wondering about the Discovery requirements, and wondering if they should
>be separated from the forwarding requirements.
>And I suspect some operators would want to have a highly-controlled
>orchestration approach, not an auto-discovery approach.
>
>
>
>
>The diff can be tracked here: http://www.ietf.org/rfcdiff?url1=draft-
>boucadair-sfc-requirements-01&difftype=--html&submit=Go!&url2=draft-
>boucadair-sfc-requirements-03
>
>Cheers,
>Med
>

---

From: 本間俊介 <[email-masked]>
Date: Mon, 24 Feb 2014 12:05:17 +0900

Hi Med,

In terms of your comment, I assumed some use cases about scalability so 
that we can continue the discussion about scalability considerations.
#I work with K.Naito, co-author of requirement draft and think 
scalability is one of important things to consider.

Assuming the use cases listed following, the management mechanism of 
Service Function Chains might require high scalability.

1. The case that the types of SF increase:
  I assumed that the unit of applying SFC to traffic is following;
   - grouping: traffic is applied with specific SFC for each service,
     enterprise customer or region,
   - per-subscriber: traffic is applied with specific SFC for each　
     subscriber (e.g. per IP address, VLAN ID et.al),
   - per-flow: traffic is applied with specific SFC for each subscriber,
　　and objective (e.g. pre URL, application et.al).

  Some of the service providers have enormous number of subscribers, and 
the number of subscribers is up to several tens or hundreds of million. 
Therefore, in cases of per-subscriber and per-flow, the number of SFCs 
might increase explosively. Per-subscriber SFCs would be needed in the 
case that there are some SFs dedicated to each user(e.g. vCPE as user 
customized).

  Also, in case of grouping, if there are multiple groups whose policies 
are different, such as per enterprise customer and per region, the 
number of SFCs would increase (e.g. Firewalls have different policy for 
each enterprise customer).

2. The case that there are some SFs that must be classified for each 
instance:
  In case that there are SFs with the same function in the network and 
the SFs must be classified for each instance, the combination of SFs 
might increase.
  The SFs that process stateful traffic are needed to be differentiated 
per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer).

IMHO,requirements for scalability will affect SFC architecture and 
header format.

Thanks,

Shunsuke

-- 
********************************************
本間 俊介 (Homma Shunsuke)

日本電信電話株式会社
ネットワークサービスシステム研究所
転送サービス基盤プロジェクト
転送サービス制御DP

〒180-8585　東京都武蔵野市緑町3-9-11
TEL: 0422-59-3486
E-MAIL: [email-masked]
********************************************

---

From: Ron Parker <[email-masked]>
Date: Mon, 24 Feb 2014 03:39:03 +0000

Shunsuke-san,

While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical.  But, there is another way to view this aspect of the problem.  Let's take your per-subscriber customized firewall as a hypothetical example.  If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced.   One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall.    Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. 

If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. 

   Ron

> On Feb 23, 2014, at 10:04 PM, "本間俊介" <[email-masked]> wrote:
> 
> Hi Med,
> 
> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations.
> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider.
> 
> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability.
> 
> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized).
> 
> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer).
> 
> 2. The case that there are some SFs that must be classified for each instance:
> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase.
> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer).
> 
> IMHO,requirements for scalability will affect SFC architecture and header format.
> 
> Thanks,
> 
> Shunsuke
>

---

From: Chris Frederick <[email-masked]>
Date: Mon, 24 Feb 2014 22:25:39 +0000

Agreed.
To restate this slightly, if the SFC steering/decision locus is capable of evaluating multiple orthogonal policy conditions then this issue is obviated; subscribers become an aggregate of 'what they are' + are not simply 'who they are'. 
As Ron states, this awareness may be derived from LDAP lookup, RADIUS, Gx, pre-provisioned rules, etc.
To illustrate w/ an example, we might say something like this:
If subscriber X is using youtube, and is on a congested cell, and is on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the chain consists of service functions a, b, and c.
There's no need to enter a static SFC rule/chain for subscriber X (or any subscriber). In fact, it's not desirable anyway because all of the above conditions may evaluate to True, save one ("is on a congested cell"), and the resultant chain might be altered (perhaps to bypass a video optimization service function).
This also goes to the earlier comments Ron + I made about consolidating the flow recognition + decision-making entity in a single (suitably policy-aware) node to reduce the complexity + to scale properly. Thx,
/c

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, February 23, 2014 10:39 PM
To: 本間俊介
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Shunsuke-san,

   Ron

>> The diff can be tracked here: 
>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01&
>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03
>> 
>> Cheers,
>> Med
>> 
>> De : I-D-Announce [mailto:[email-masked]] De la part 
>> de [email-masked] Envoyé : mercredi 12 février 2014 10:46 À 
>> : [email-masked] Objet : I-D Action: 
>> draft-boucadair-sfc-requirements-03.txt
>> 
>> 
>> 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.
>> 
>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

---

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

Hi all,

In Mobile, per-subscriber value-added-service (VAS) is valuable and is a culture of personalisation i.e. a user is a sole owner of a device. To date with the legacy circuit-switched voice-centric network aka CS voice, we already have per-subscriber VAS in the form of supplementary services i.e. voice mail, diversion etc. and in the Packet Data world, the PCRF architecture was developed with that (per-subscriber service) in mind. What is lacking at the moment is the per-subscriber SFC on the Gi/SGi user plane capability to monetize with VAS as what we have been doing with CS.

In my opinion, it is a very important aspect of SFC. I agree there will be scalability challenge but the value of this capability justifies the challenge. The scalability as Ron has indicated, will be more on the "control plane" which needs to a) identify the user and b)determine the SFs required and c)signal the network and the SFs for SFC. The Mobile network with personalisation culture in mind has plenty of resources for the SFC to leverage for per-subscribers service.

The number of SFCs may not be high as the number of VASes normally will be limited to a small number. We don't need per-subscriber SFC but a capability to map each subscriber to one of the SFC in the VAS catalogue. Take Ron's example of a per-subscriber's firewall. A service provider would not likely to offer a per-subscriber network-based FW where a subscriber can use a portal to configure the way they can do on a RG or a software FW on a PC. It would likely offer a generic Gi stateful firewall so that unsolicited traffic cannot be sent to the UE.  

As we are looking at a Requirements document here, we should focus more on the requirements (in this document) rather than go into solution mode and perhaps think ahead that it may be too hard then back out the requirements.

I fully agree, scalability will likely influence architecture (solution mode) so it needs to be included.

Regards,
Chuong

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, 24 February 2014 2:39 PM
To: 本間俊介
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Shunsuke-san,

   Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 24 Feb 2014 18:36:11 -0500

Being able to give each subscriber the services they want is clearly 
necessary for any mobile, residential, or even business service in this 
environment.

But that does not mean we should want or expect that the number of 
different service chains is on the same order as the number of users. 
One of the advantages of ingress classification is that many users can 
use the same service chain.

Yours,
Joel

---

From: "Pham, Chuong D" <[email-masked]>
Date: Tue, 25 Feb 2014 10:41:09 +1100

Joel,
Fully agree. I said the same but reading my message again, I realised that I might have caused confusion. Agree that the number of service chains is needed to be limited but classifying each subscriber into these service chains is an important requirement.
Regards,
Chuong

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, 25 February 2014 10:36 AM
To: Pham, Chuong D; Ron Parker; 本間俊介
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Being able to give each subscriber the services they want is clearly necessary for any mobile, residential, or even business service in this environment.

But that does not mean we should want or expect that the number of different service chains is on the same order as the number of users. 
One of the advantages of ingress classification is that many users can use the same service chain.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 24 Feb 2014 23:45:22 +0000

Thanks, Chris.

I do think there are lots of efficiencies when the flow learner (classifier) and policy evaluator (PDP) are co-located.   However, architecturally, I wouldn't mandate that they be co-located.   

    Ron

-----Original Message-----
From: Chris Frederick [mailto:[email-masked]] 
Sent: Monday, February 24, 2014 5:26 PM
To: Ron Parker; 本間俊介
Cc: [email-masked]; [email-masked]
Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Agreed.
This also goes to the earlier comments Ron + I made about consolidating the flow recognition + decision-making entity in a single (suitably policy-aware) node to reduce the complexity + to scale properly. Thx, /c

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, February 23, 2014 10:39 PM
To: 本間俊介
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Shunsuke-san,

   Ron

---

From: Chris Frederick <[email-masked]>
Date: Mon, 24 Feb 2014 23:46:43 +0000

Yes, agreed on that.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, February 24, 2014 6:45 PM
To: Chris Frederick; 本間俊介
Cc: [email-masked]; [email-masked]
Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Thanks, Chris.

    Ron

-----Original Message-----
From: Chris Frederick [mailto:[email-masked]]
Sent: Monday, February 24, 2014 5:26 PM
To: Ron Parker; 本間俊介
Cc: [email-masked]; [email-masked]
Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Agreed.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, February 23, 2014 10:39 PM
To: 本間俊介
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Shunsuke-san,

   Ron

---

From: Kengo Naito <[email-masked]>
Date: Tue, 25 Feb 2014 10:30:44 +0900

Hello Ron, Chris,

I also understood that evaluating policy conditions is an efficient 
function for recognizing subscribers.
Do you think this should be one of the requirements?

If there is no statements (or definitions), there would be SFs that may 
not co-operate with sfc evaluated policies.

Thanks,
Kengo

-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: [email-masked]
TEL: +81 422-59-4949
----------------------------------------

---

From: Ron Parker <[email-masked]>
Date: Tue, 25 Feb 2014 01:43:24 +0000

Kengo-san,

We've tried to leave it up to the innovation of the implementer to determine what metadata to collect, how to collect it, and how to implement policy evaluation that examines the metadata along with the flow properties.   In practice, this means that some implementations could combine, for example, a 3gpp PDN-Gateway, SFC classifier, and SFC PDP, bringing together subscriber information, flow information, and service orchestration to one place.   However, all of those functions are logically separate and other implementers may find reason to not co-locate them.

   Ron

-----Original Message-----
From: Kengo Naito [mailto:[email-masked]] 
Sent: Monday, February 24, 2014 8:31 PM
To: Chris Frederick; Ron Parker
Cc: "本間俊介(homma shunsuke)"; [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Hello Ron, Chris,

I also understood that evaluating policy conditions is an efficient function for recognizing subscribers.
Do you think this should be one of the requirements?

If there is no statements (or definitions), there would be SFs that may not co-operate with sfc evaluated policies.

Thanks,
Kengo

(2014/02/25 8:46), Chris Frederick wrote:
> This also goes to the earlier comments Ron + I made about 
> consolidating the flow recognition + decision-making entity in a 
> single (suitably policy-aware) node to reduce the complexity + to 
> scale properly. Thx, /c
>

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 25 Feb 2014 10:59:39 +0900

Hi Ron, Chris,

Thank you for your reply.

I think that your points are following:
in case that there are some SFs as user customized,
per-subscriber SFCs shouldn't be made, but the SFs should recognize
subscribers by IP address or metadata.

Of course, it is one of the solutions.
However, in this case, I think that SFs as user customized might be 
required to have a

function to recognize each subscriber.

On the other hand, I think that there are cases when the function can't 
be adopted,
such like SFs are current equipment that don't have function to 
recognize metadata.

How do we handle these cases?
Any new problems or requirements may occur?

regards,

Shunsuke

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

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

---

From: Kengo Naito <[email-masked]>
Date: Tue, 25 Feb 2014 11:02:55 +0900

Ron,

In terms of classifiers, I agree with you that it is an implementation 
matter.
To avoid misunderstanding, let me ask you this:
Then, implementers should also determine what metadata to collect at the 
classifier (with policy evaluator),
and also, how to handle it in SFs, maybe in virtual appliances, and also 
maybe in virtual switches (or load balancers) in front of them, right?

Kengo

---

From: Ron Parker <[email-masked]>
Date: Tue, 25 Feb 2014 02:13:53 +0000

Yes, all of that is an implementation matter.

Wrt load balancers, see some of the previous discussion that was attempting to differentiate load balancing of midbox service functions vs. load balancer as a service function.   In the former case, we may choose to make the classifier/PDP aware of the fact that a service function is multiply instantiated.

   Ron

-----Original Message-----
From: Kengo Naito [mailto:[email-masked]] 
Sent: Monday, February 24, 2014 9:03 PM
To: Ron Parker
Cc: Chris Frederick; [email-masked]; "本間俊介(homma shunsuke)"; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Ron,

In terms of classifiers, I agree with you that it is an implementation matter.
To avoid misunderstanding, let me ask you this:
Then, implementers should also determine what metadata to collect at the classifier (with policy evaluator), and also, how to handle it in SFs, maybe in virtual appliances, and also maybe in virtual switches (or load balancers) in front of them, right?

Kengo

(2014/02/25 10:43), Ron Parker wrote:
>>>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-0
>>>> 1
>>>> &

---

From: Chris Frederick <[email-masked]>
Date: Tue, 25 Feb 2014 05:17:31 +0000

Hi Shunsuke-san,
I acknowledge the comments about these being implementation matters, but I've offered some thoughts inline with your mail below. Thx,
/c

-----Original Message-----
From: Shunsuke Homma [mailto:[email-masked]] 
Sent: Monday, February 24, 2014 9:00 PM
To: Chris Frederick; Ron Parker
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Hi Ron, Chris,

I think that your points are following:
in case that there are some SFs as user customized, per-subscriber SFCs shouldn't be made, but the SFs should recognize subscribers by IP address or metadata.
CF>> My point was that I don't see it as desirable to have specific per-subscriber SFC rules (as in static rules, like subscriber_Chris=SFC_a_b_c), with a rule for every sub, in that sense. Better is a scenario where the SFC chain controller is subscriber-aware + able to evaluate multiple orthogonal flow + subscriber conditions in real time, and formulate a chain on the basis of those dynamic conditions.  

Of course, it is one of the solutions.
However, in this case, I think that SFs as user customized might be required to have a function to recognize each subscriber.
CF>> I wasn't actually thinking in terms of SF (re)classification; I've previously commented on why I think that idea is somewhat fraught (i.e. because modification of the flow path by a service function within the chain could result in a 'breaking' of the chain or flow. If there is not bidirectional symmetry in the flow and service function elements in the chain can make routing decisions, then there's some metadata correlation to work out, at minimum). I do agree that the SFC chain controller would need to be subscriber-aware though.

On the other hand, I think that there are cases when the function can't be adopted, such like SFs are current equipment that don't have function to recognize metadata.
CF>> Agreed. This speaks to my comment above + to the advantages some of us have mentioned viz a consolidated policy-based steering/PDP/SFC chain controller entity. 

regards,

Shunsuke

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 25 Feb 2014 17:48:38 +0900

Hi Chuong, Joel,

 >Agree that the number of service chains is needed to be limited but 
 >classifying each subscriber into these service chains is an important 
 >requirement.
I agree.

In my opinion, we should realize that there are some problems or 
requirements  in case that the number of subscribers and SFs are 
increase, and confirm what the problems and requirements are.

Regards,

Shunsuke

---

From: Kengo Naito <[email-masked]>
Date: Tue, 25 Feb 2014 18:48:21 +0900

Ron,

(2014/02/25 11:13), Ron Parker wrote:
> Wrt load balancers, see some of the previous discussion that was attempting to differentiate load balancing of midbox service functions vs. load balancer as a service function.
Thank you for pointing.

>   In the former case, we may choose to make the classifier/PDP aware of the fact that a service function is multiply instantiated.
Okay, and in any case, the common fact is that the number of service 
chains is needed to be limited but classifying each subscriber into 
service chains, and recognize policies, is an important requirement, as 
Chuong says in the thread.
I also agree this point.

Thanks,
Kengo

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 25 Feb 2014 21:25:19 +0900

Hi Chris,

Do you mean that, for retaining integrity of chains, management of 
subscribers should be provided not by SFs, but by SFC controller?

If so, the problem is that the number of chains that SFC controller must 
manage is large, and it is the same problem I said, I think.

Regards,

Shunsuke

---

From: Chris Frederick <[email-masked]>
Date: Tue, 25 Feb 2014 14:43:37 +0000

Hi Shunsuke-san,
I recognize that ultimately, this is an implementation decision and not something to be mandated as a hard 'rule'. I just wanted to highlight what is possible + what we believe to be best practices in this area, based on our experience.
That said, yes, I believe that in practical (real-world) terms, it makes sense to deemphasize the '(re)classification' role of SFs in most cases, for reasons I've stated previously (questions of metadata sharing between SFs, issues related to retaining integrity of chains/breaking flows, etc.).
To your comment about scaling the SFC Controller, I would just say that there are commercially deployed SFC Controllers today that do this, i.e. sit inline in consumer networks, receive/inspect millions of concurrent bidirectional flows, + make real-time SFC steering and sequencing decisions based on flow, subscriber, session, and network conditions. 
Obviously, differences in vendor capabilities, as well as architectural decisions viz consolidating vs. distributing different SFC functions like flow classification, PDP/SFC Controller, steering/lb, etc, all will have an impact here. Best,
/c

-----Original Message-----
From: Shunsuke Homma [mailto:[email-masked]] 
Sent: Tuesday, February 25, 2014 7:25 AM
To: Chris Frederick; Ron Parker
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Hi Chris,

Do you mean that, for retaining integrity of chains, management of subscribers should be provided not by SFs, but by SFC controller?

If so, the problem is that the number of chains that SFC controller must manage is large, and it is the same problem I said, I think.

Regards,

Shunsuke

(2014/02/25 14:17), Chris Frederick wrote:
> Hi Shunsuke-san,
> I acknowledge the comments about these being implementation matters, 
> but I've offered some thoughts inline with your mail below. Thx, /c
>

---

From: Ron Parker <[email-masked]>
Date: Tue, 25 Feb 2014 14:49:53 +0000

Expanding on Chris' comments, I don't think the practical limitations are wrt the number of fully-qualified 5-tuples, but rather the number of distinct treatment sequences that arise from those flows.   Of the 100's of millions of flows that might be tracked by a high end classifier, perhaps the number of unique sequences that arise are in the 1000's.    If applying a fixed-line or mobile service provider perspective, the number of chains would be proportional to the number of distinct end-to-end service plans offered and then multiplied by the flow-aware subsetting that can be managed by the classifier (i.e., subscriber is subject to service function A then B then C but B only needs TCP/80 traffic, A only needs UDP traffic, ...).

   Ron

-----Original Message-----
From: Chris Frederick [mailto:[email-masked]] 
Sent: Tuesday, February 25, 2014 9:44 AM
To: Shunsuke Homma; Ron Parker
Cc: [email-masked]; [email-masked]
Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Hi Shunsuke-san,
I recognize that ultimately, this is an implementation decision and not something to be mandated as a hard 'rule'. I just wanted to highlight what is possible + what we believe to be best practices in this area, based on our experience.
That said, yes, I believe that in practical (real-world) terms, it makes sense to deemphasize the '(re)classification' role of SFs in most cases, for reasons I've stated previously (questions of metadata sharing between SFs, issues related to retaining integrity of chains/breaking flows, etc.).
To your comment about scaling the SFC Controller, I would just say that there are commercially deployed SFC Controllers today that do this, i.e. sit inline in consumer networks, receive/inspect millions of concurrent bidirectional flows, + make real-time SFC steering and sequencing decisions based on flow, subscriber, session, and network conditions. 
Obviously, differences in vendor capabilities, as well as architectural decisions viz consolidating vs. distributing different SFC functions like flow classification, PDP/SFC Controller, steering/lb, etc, all will have an impact here. Best, /c

-----Original Message-----
From: Shunsuke Homma [mailto:[email-masked]]
Sent: Tuesday, February 25, 2014 7:25 AM
To: Chris Frederick; Ron Parker
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Hi Chris,

Regards,

Shunsuke

---

From: <[email-masked]>
Date: Tue, 25 Feb 2014 16:42:16 +0100

Hi Chuong,

I agree classification can be subscriber-aware. 

BTW, this requirement draft already covers this point: classification rules are policy-based and deployment-specific. The wording can be enhanced to call out "subscriber-aware" in addition to flow characteristics:

   REQ#18:  The solution MUST NOT make any assumption on how the traffic
            is to be bound to a given chaining policy.  In other words,
            classification rules are deployment-specific and policy-
            based.  For instance, classification can rely on a subset of
            the information carried in a received packet such as 5-tuple
            classification.

Cheers,
Med

>De : sfc [mailto:[email-masked]] De la part de Pham, Chuong D
>Envoyé : mardi 25 février 2014 00:12
>À : Ron Parker; 本間俊介
>Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]
>Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt
>
>Hi all,
>
>In Mobile, per-subscriber value-added-service (VAS) is valuable and is a
>culture of personalisation i.e. a user is a sole owner of a device. To date
>with the legacy circuit-switched voice-centric network aka CS voice, we
>already have per-subscriber VAS in the form of supplementary services i.e.
>voice mail, diversion etc. and in the Packet Data world, the PCRF
>architecture was developed with that (per-subscriber service) in mind. What
>is lacking at the moment is the per-subscriber SFC on the Gi/SGi user plane
>capability to monetize with VAS as what we have been doing with CS.
>
>In my opinion, it is a very important aspect of SFC. I agree there will be
>scalability challenge but the value of this capability justifies the
>challenge. The scalability as Ron has indicated, will be more on the
>"control plane" which needs to a) identify the user and b)determine the SFs
>required and c)signal the network and the SFs for SFC. The Mobile network
>with personalisation culture in mind has plenty of resources for the SFC to
>leverage for per-subscribers service.
>
>The number of SFCs may not be high as the number of VASes normally will be
>limited to a small number. We don't need per-subscriber SFC but a
>capability to map each subscriber to one of the SFC in the VAS catalogue.
>Take Ron's example of a per-subscriber's firewall. A service provider would
>not likely to offer a per-subscriber network-based FW where a subscriber
>can use a portal to configure the way they can do on a RG or a software FW
>on a PC. It would likely offer a generic Gi stateful firewall so that
>unsolicited traffic cannot be sent to the UE.
>
>As we are looking at a Requirements document here, we should focus more on
>the requirements (in this document) rather than go into solution mode and
>perhaps think ahead that it may be too hard then back out the requirements.
>
>While a theoretical case can be made for one or more SFCs per subscriber,
>for reasons you state, it isn't practical.  But, there is another way to
>view this aspect of the problem.  Let's take your per-subscriber customized
>firewall as a hypothetical example.  If there were only one firewall,
>instead, and it was capable of local policy evaluation based on subscriber,
>the number of SFCs would be vastly reduced.   One way for that to happen
>would be to simply use the source/destination IP address from the packet
>and some out of band lookup mechanism like LDAP or RADIUS at the firewall.
>Another approach to determine who the subscriber is would be for the SFC
>classifier to add a distinct subscriber id as metadata to the service
>header (eg, an IMSI) and still use LDAP, etc. at the firewall.
>
>If the problem is changed slightly so that the firewall policy is per group
>of subscribers, where there are perhaps 10s of groups, then yet another
>approach is to model the firewall as a distinct logical firewall per
>firewall policy set (they could all reside in the same machine or VM) and
>to coordinate the classifier's policy accordingly.
>
>   Ron
>
>
>might increase explosively. Per-subscriber SFCs would be needed in the case
>that there are some SFs dedicated to each user(e.g. vCPE as user
>customized).
>>
>are different, such as per enterprise customer and per region, the number
>of SFCs would increase (e.g. Firewalls have different policy for each
>enterprise customer).
>>
>> In case that there are SFs with the same function in the network and the
>SFs must be classified for each instance, the combination of SFs might
>increase.
>> The SFs that process stateful traffic are needed to be differentiated per
>instance (e.g. Firewall, Contents-Cache, and Video-Optimizer).
>>

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 26 Feb 2014 16:26:17 +0900

Hi Chris, Ron,

I understood that you said.
And I agree with you that the method using metadata is one of the 
methods for recognizing subscribers.
But this problem is implementation matters, so it is not at the stage 
for discussion yet, I think.

What I want to say is that there are requests for distinct services per 
subscriber, so that SFC architecture should be scalable.

Regards,

Shunsuke

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Feb 2014 12:31:41 +0000

Even if subscribers can self configure their services via a portal, the number of distinct combinations that arise will still be finite.  That is, in a population of 100000000 subscribers, surely some will end up with equivalent services?

   Ron

> On Feb 26, 2014, at 2:25 AM, "Shunsuke Homma" <[email-masked]> wrote:
> 
> Hi Chris, Ron,
> 
> And I agree with you that the method using metadata is one of the methods for recognizing subscribers.
> But this problem is implementation matters, so it is not at the stage for discussion yet, I think.
> 
> What I want to say is that there are requests for distinct services per subscriber, so that SFC architecture should be scalable.
> 
> Regards,
> 
> Shunsuke
> 
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Feb 2014 14:42:20 +0000

Right and the point being what you want to do is share SFCs across subscribers and implement within the SFC any differentiation in terms of policy for subscribers that consume the same set of services.

Sent from my iPhone

> On Feb 26, 2014, at 7:32 AM, "Ron Parker" <[email-masked]> wrote:
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Feb 2014 15:21:02 +0000

I agree with Jim.

We have also pointed out that there are at least 2 approaches to differentiated policy **within** a service function.   The first is that the service function is responsible for determining which policies to apply in a manner that is private to it (perhaps using RADIUS, or LDAP, or some other external lookup mechanism).    This approach may, in some cases, benefit from a subscriber identity being passed in the inband metadata.

The second, which is well suited when the number of distinct policy sets is small (e.g., content-filter-adult, content-filter-child), is to model the service function as having multiple logical instances of itself, each implying a distinct policy set.   In this approach, SFCs are built such that any given chain would include at most one of the logical instances.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2014 9:42 AM
To: Ron Parker
Cc: Shunsuke Homma; Chris Frederick; [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Sent from my iPhone

>>> Obviously, differences in vendor capabilities, as well as 
>>> architectural decisions viz consolidating vs. distributing different 
>>> SFC functions like flow classification, PDP/SFC Controller, 
>>> steering/lb, etc, all will have an impact here. Best, /c
>>> 
>>>> I acknowledge the comments about these being implementation 
>>>> matters, but I've offered some thoughts inline with your mail 
>>>> below. Thx, /c
>>>> 
>>>>>>> De : I-D-Announce [mailto:[email-masked]] De la 
>>>>>>> part de [email-masked] Envoyé : mercredi 12 février 
>>>>>>> 2014 10:46 À
>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirement
>>>>>>> s-0
>>>>>>> 3
>>>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>>>>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 26 Feb 2014 15:50:29 +0000

Also, earlier we discussed the benefits of orthogonal treatment of forwarding information vs. meta-data.
I.e., some part of the protocol should indicate that path, and a different part of the protocol should indicate the treatment or policy set to be used.
Earlier it was suggested that the forwarding information should be in a fixed-size header.

So, in the limit, there could be a single (bi-directional) forwarding path over which millions of different policy treatments are conveyed.
E.g., one forwarding path for each direction (really two paths), with subscriber identifier in the meta-data. 

Benefits:
- forwarding elements are agnostic about the meta-data, keeping the forwarding tables as small as possible and using fixed-size headers for optimal performance
- SFs are agnostic about the forwarding information, using only the relevant meta-data.
- the meta-data is not required in every packet. E.g., it could be sent with the first packet of a layer4 connection, or perhaps out of band.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, February 26, 2014 10:21 AM
To: Jim Guichard (jguichar)
Cc: Chris Frederick; [email-masked]; Shunsuke Homma; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

I agree with Jim.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2014 9:42 AM
To: Ron Parker
Cc: Shunsuke Homma; Chris Frederick; [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Sent from my iPhone

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Feb 2014 16:03:11 +0000

Dave,

I find the conveyance of a policy key from the classifier to the service functions very attractive.   

However, I don't think a global key that is interpreted equally by all service functions is practical.   Some service functions may have only a very small quantity of policy sets while others may be very granular.     With a global key, when additional policy sets are added to some service function, all service functions would need to know how to translate those new global keys into something locally significant.    

An alternative, pushing a stack of per-service-function policy keys onto the packet so that each service function can see its own locally significant policy key, has its issues, too, since it is theoretically unbounded and adds overhead to every packet.

A possible workaround to the stack of policy keys is to signal this in a control plane from the classifier to the service functions.   But, signaling at the micro-flow level is very impractical in terms of scale and adds significant complexity to avoid the first packet race condition that could arise.   In my opinion, the control plane should operate at the chain setup and maintenance level and not at the microflow level.

Lastly, an approach that I think could work for bidirectional flows (the vast majority of practical use cases, IMO) is to have an inband mechanism to deliver long lived metadata.    The stack of policy keys could be delivered inband in the first N packets of the flow.    The reverse flow would piggyback inband acknowledgements from the service functions that the long term metadata has been received.    At that point, the classifier would no longer add the long lived metadata to the flow.

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2014 10:50 AM
To: Ron Parker; Jim Guichard (jguichar)
Cc: Chris Frederick; [email-masked]; Shunsuke Homma; [email-masked]
Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Benefits:

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, February 26, 2014 10:21 AM
To: Jim Guichard (jguichar)
Cc: Chris Frederick; [email-masked]; Shunsuke Homma; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

I agree with Jim.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, February 26, 2014 9:42 AM
To: Ron Parker
Cc: Shunsuke Homma; Chris Frederick; [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Sent from my iPhone

---

From: Dave Dolson <[email-masked]>
Date: Wed, 26 Feb 2014 16:15:42 +0000

That in-band method of sending data is interesting.

My main point was the orthogonality of per-packet forwarding tags and the meta-data to convey policy treatment. I did not mean to imply one meta-data parameter is appropriate for all elements.

Since your idea does not put the meta-data in each packet, I suspect we are in agreement on the separation of forwarding information from policy keys.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2014 11:03 AM
To: Dave Dolson; Jim Guichard (jguichar)
Cc: Chris Frederick; [email-masked]; Shunsuke Homma; [email-masked]
Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Dave,

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2014 10:50 AM
To: Ron Parker; Jim Guichard (jguichar)
Cc: Chris Frederick; [email-masked]; Shunsuke Homma; [email-masked]
Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Benefits:

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, February 26, 2014 10:21 AM
To: Jim Guichard (jguichar)
Cc: Chris Frederick; [email-masked]; Shunsuke Homma; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

I agree with Jim.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, February 26, 2014 9:42 AM
To: Ron Parker
Cc: Shunsuke Homma; Chris Frederick; [email-masked]; [email-masked]
Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt

Sent from my iPhone

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Feb 2014 16:51:53 +0000

Absolutely, the service header has 2 aspects -- conveyance of information used for steering (ie chain id) and conveyance of other helpful information (ie metadata). 

   Ron

> On Feb 26, 2014, at 11:15 AM, "Dave Dolson" <[email-masked]> wrote:
> 
>>>>>>>> part de [email-masked] Envoye : mercredi 12 fevrier
>>>>>>>> 2014 10:46 A