Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 18 Apr 2014 22:29:57 +0000

Dear WG:

This message begins a two week call for WG adoption of the document http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd May 2014.

Please respond to the SFC mailing list with any statements of approval or disapproval.

Please note:

  1.  This is not WG Last Call. The document is not final, and the WG is expected to modify the document’s content until there is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its content.
  2.  If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
  3.  If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Apr 2014 19:25:06 -0400

I support adoption of this document by the working group.  It is a good 
starting point for addressing the material it covers, and the working 
group should cover that material.

Yours,
Joel

On 4/18/14, 6:29 PM, Jim Guichard (jguichar) wrote:
> Dear WG:
>
> This message begins a two week call for WG adoption of the document
> http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending 2nd
> May 2014.
>
>  1. This is not WG Last Call. The document is not final, and the WG is
>     expected to modify the document’s content until there is WG
>     consensus that the content is solid. Therefore, please don’t oppose
>     adoption just because you want to see changes to its content.
>  2. If you have objections to adoption of the document, please state
>     your reasons why, and explain what it would take to address your
>     concerns.
>  3. If you have issues with the content, by all means raise those issues
>     and we can begin a dialog about how best to address them.
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Lucy yong <[email-masked]>
Date: Sat, 19 Apr 2014 14:12:55 +0000

Support!

Cheers,
Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 5:30 PM
To: [email-masked]
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Dear WG:

Please note:

  1.  This is not WG Last Call. The document is not final, and the WG is expected to modify the document's content until there is WG consensus that the content is solid. Therefore, please don't oppose adoption just because you want to see changes to its content.
  2.  If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
  3.  If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

---

From: ramki Krishnan <[email-masked]>
Date: Sat, 19 Apr 2014 07:36:09 -0700

Support.

Thanks,
Ramki

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 3:30 PM
To: [email-masked]
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Dear WG:

Please note:

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 19 Apr 2014 16:54:45 +0000

Support.

On 19 Apr 2014, at 00:29 , Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Please note:

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Rajeev Manur <[email-masked]>
Date: Sun, 20 Apr 2014 23:13:47 +0000

Support.

Dear WG:

Please note:

---

From: Barry Greene <[email-masked]>
Date: Mon, 21 Apr 2014 06:52:31 +0700

I support, but it could be better if 1.2 had a simple reference to "new service." It would fit with the rest of the document. 

On Apr 19, 2014, at 5:29 AM, Jim Guichard (jguichar) <[email-masked]> wrote:

> 	• This is not WG Last Call. The document is not final, and the WG is expected to modify the document’s content until there is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its content.
> 	• If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
> 	• If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 21 Apr 2014 15:36:19 +0000

I suport the adoption of this draft.

Paul

On Apr 18, 2014, at 3:29 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Please note:

---

From: Ron Parker <[email-masked]>
Date: Mon, 21 Apr 2014 17:29:51 +0000

Support.

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, April 18, 2014 6:30 PM
To: [email-masked]
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Dear WG:

Please note:

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 21 Apr 2014 13:25:03 -0700

Support!!

On Apr 18, 2014, at 3:29 PM, Jim Guichard (jguichar) <[email-masked]> wrote:

> This is not WG Last Call. The document is not final, and the WG is expected to modify the document’s content until there is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its content.
> If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
> If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

---

From: "Zarny, Myo" <[email-masked]>
Date: Mon, 21 Apr 2014 18:03:20 -0400

I like the requirements listed in 3.1.2.

Shouldn't we also call this out?

*         SFC solutions SHOULD not require any service functions to participate in the implementation of SFCs.

That is, service function nodes (LBs, proxys, FWs, etc.) need not understand anything about SFCs; they could just be performing as they are today. We could have service functions that partake in SFC implementations but they don't need to be required to.

Regards,

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: 18 April 2014 6:30 PM
To: [email-masked]
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Dear WG:

Please note:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Apr 2014 18:22:28 -0400

I would prefer not to state that as a requirement.
Where practical, we do indeed want (even need) to support existing 
service funciton implementations.
But there will be some service functions which can not be proxied and 
which can not be placed into the middle of service chains.  Trying to 
solve 100% of the cases, if possible at all, will likely dramatically 
slow the work down.

Yours,
Joel M. Halpern

On 4/21/14, 6:03 PM, Zarny, Myo wrote:
> Shouldn’t we also call this out?
>
> ·SFC solutions SHOULD not require any service functions to participate
> in the implementation of SFCs.
>
> That is, service function nodes (LBs, proxys, FWs, etc.) need not
> understand anything about SFCs; they could just be performing as they
> are today. We could have service functions that partake in SFC
> implementations but they don’t need to be required to.
>
> Regards,
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim Guichard
> (jguichar)
> *Sent:* 18 April 2014 6:30 PM
> *To:* [email-masked]
> *Subject:* [sfc] Call for adoption of
> draft-haeffner-sfc-use-case-mobility-01
>
> Dear WG:
>
> 1.This is not WG Last Call. The document is not final, and the WG is
> expected to modify the document’s content until there is WG consensus
> that the content is solid. Therefore, please don’t oppose adoption just
> because you want to see changes to its content.
>
> 2.If you have objections to adoption of the document, please state your
> reasons why, and explain what it would take to address your concerns.
>
> 3.If you have issues with the content, by all means raise those issues

---

From: Cathy Zhang <[email-masked]>
Date: Mon, 21 Apr 2014 22:22:18 +0000

Support this draft.

Agree with Myo. I would like to suggest one more callout on "3.1.2.  Requirements from use case"

*         SFC solutions SHOULD allow support traffic reclassification at any point of the chain

(eg. due to any change of the n-tuple classification fields by a service function that does not understand the service chain header, or due to chain split/forking etc.).

Thanks,
Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Zarny, Myo
Sent: Monday, April 21, 2014 3:03 PM
To: 'Jim Guichard (jguichar)'; [email-masked]'
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Regards,

Dear WG:

Please note:

---

From: "Zarny, Myo" <[email-masked]>
Date: Mon, 21 Apr 2014 18:46:52 -0400

Hi Joel,

Not sure about the comment about the need for proxying as a requirement for SFC. Not all service functions are of proxying kind. Even load balancers don't have to proxy--DSR for example. Firewalls perform permit/deny; they don't proxy. Likewise with IDS/IPS. Etc. Etc. Shouldn't we assume that service chains will consist of proxying and non-proxying kinds? Besides, I don't read that the draft requires proxying, do you?

I'm not saying service function nodes can't partake in SFC implementations-no need to stifle innovation. But do we need to require that service function nodes MUST understand SFC headers, for example? What happens to those that don't? Are they all legacy? For many users who have invested in non-SFC-understanding equipment, that's practically a non-starter. And it will likely slow adoption, IMO.

Regards,

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: 21 April 2014 6:22 PM
To: Zarny, Myo [Tech]; [email-masked]'
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

I would prefer not to state that as a requirement.
Where practical, we do indeed want (even need) to support existing service funciton implementations.
But there will be some service functions which can not be proxied and which can not be placed into the middle of service chains.  Trying to solve 100% of the cases, if possible at all, will likely dramatically slow the work down.

Yours,
Joel M. Halpern

On 4/21/14, 6:03 PM, Zarny, Myo wrote:
> *SFC solutions SHOULD not require any service functions to participate
> implementations but they don't need to be required to.
>
> Regards,
>
> *To:* [email-masked]<mailto:[email-masked]>
> http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt
> ending 2nd May 2014.
>
> expected to modify the document's content until there is WG consensus
> that the content is solid. Therefore, please don't oppose adoption
> just because you want to see changes to its content.
>
> 2.If you have objections to adoption of the document, please state
> your reasons why, and explain what it would take to address your concerns.
>

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 22 Apr 2014 08:41:56 +0200

Hi, 
Am 22.04.2014 um 00:03 schrieb Zarny, Myo <[email-masked]>:

> ·         SFC solutions SHOULD not require any service functions to participate in the implementation of SFCs.

Isn’t this a bit too strong? I assume you are coming from the legacy side, i.e., existing functions should be able to include in SFCs. However, this statement says that no function should be required to changed in order to participate in SFCs.

Or what does it mean?

  Martin

>  
> That is, service function nodes (LBs, proxys, FWs, etc.) need not understand anything about SFCs; they could just be performing as they are today. We could have service functions that partake in SFC implementations but they don’t need to be required to.
>  
> Regards,
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 22 Apr 2014 06:48:59 +0000

Hi,

As far as I understand, it says that SFC implementations should be completely oblivious to the processing performed by the service functions, and should not rely on them to actually implement chaining and paths. It simplifies the way for legacy functions being integrated in a SFC framework,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 22 Apr 2014 09:21:41 -0400

Thank you, Diego. It's exactly what I meant.

Martin, I'm coming from the user side. From an enterprise user perspective, we'd like to see existing (non-SFC-understanding) equipment (FWs, LBs, etc.) still be usable inside service chains. I think SFC solutions that can accommodate legacy equipment will find wider adoption.

Also, I'm saying "SHOULD not require", not "MUST not require". I'm not an expert on RFC-2119 terms, so I'll be fine with a more suitable wording to that effect.

Regards,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: 22 April 2014 2:49 AM
To: Martin Stiemerling
Cc: Jim Guichard (jguichar); Zarny, Myo [Tech]; [email-masked]
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Hi,

Be goode,

On 22 Apr 2014, at 08:41 , Martin Stiemerling <[email-masked]<mailto:[email-masked]>> wrote:

> Hi,
> Am 22.04.2014 um 00:03 schrieb Zarny, Myo <[email-masked]<mailto:[email-masked]>>:
>
> Isn't this a bit too strong? I assume you are coming from the legacy side, i.e., existing functions should be able to include in SFCs. However, this statement says that no function should be required to changed in order to participate in SFCs.
>
> Or what does it mean?
>
>  Martin
>
>>
>> To: [email-masked]<mailto:[email-masked]>

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

---

From: Weixinpeng <[email-masked]>
Date: Thu, 24 Apr 2014 04:04:38 +0000

Hi,
Support the document. But I still have some questions:

1. In section 6.1, it states that "The creation of service chains should
   be embedded in the business and operation support layers of the
   company and on an abstract functional level..." so what "the business and operation support layers" mean here, it's
the OSS/BSS or other entities in 3GPP network?
2. As my understanding, the requirement from operator is that the operator generates an abstract functional level service chain, and sends it to
the controller in SFC framework to form a service function chain instance, the chain compiler and mediation device in figure 10 are a functional part of controller, am I right?

Thanks,
Xinpeng

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, April 19, 2014 6:30 AM
To: [email-masked]
Subject: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Dear WG:

Please note:

---

From: <[email-masked]>
Date: Thu, 24 Apr 2014 07:41:26 +0200

Dear all,

I don't support the adoption of this draft for the reasons already listed in the list. I'm for one single use case document.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : samedi 19 avril 2014 00:30
À : [email-masked]
Objet : [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Dear WG:

Please note:

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Thu, 24 Apr 2014 10:36:51 +0000

Hi Xipeng,

Thanks for supporting our draft. We are currently working on the next edition which takes care of all the WG inputs.

Wrt section 6.1we had the complete product creation cycle in mind:

1.)    Marketing defines a product.

2.)    Product (assume a mobile access product) is typically specified by parameters like QoS for traffic classes, BW limits, volume limits, charging, etc.

3.)    Marketing asks Product Engineering to specify input to Network/Service Engineering

4.)    Network/Service Engineering maps this into network configs.

5.)    Operations finally implements and maintain this config.

So you are right. The "dream environment" for an operator would be a stack with increased abstraction towards the business-oriented layers. Idea is to think about an abstract SFC graph with branching rules specified on the "product requirements level" (metadata) and created by Product Engineering in some fancy tool box. This may be automatically translated into underlay/tunnel configs.
This fits pretty much with the WG idea of a new abstracted forwarding mechanism based on "Base Header" content already proposed in some early drafts.

Branching rules are driven by static or time/state dependent metadata context. You could make the set of metadata bigger and bigger, but the question is, what is the minimal set and how we may transfer and manage these metadata to come to a feasible and useful SFC environment the operators may (stepwise) introduce. We have to think about it. But, SFC cannot and should not try to solve all the problems on earth.

Abstraction is also not a new idea. Have for example a closer look to Brent Salisbury's recent open source work on Openstack, OVSDB within Opendaylight. This may reflect what could be done within a complete SFC framework.

For sure and explicitly stated, not all of this is subject of the SFC WG. But an operator is not only asking for a protocol. He asks for a complete solution.

What is your opinion?

Kind regards,

Walter

Von: Weixinpeng [mailto:[email-masked]]
Gesendet: Donnerstag, 24. April 2014 06:05
An: Haeffner, Walter, Vodafone DE; [email-masked]; [email-masked]
Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Research)
Betreff: RE: Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Hi,

Thanks,
Xinpeng

Dear WG:

Please note:

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 24 Apr 2014 11:40:41 -0500

Hi all,

I think there is conflict in what Figure 1 says and what Figure 6 says
regarding the NAT function.

As far as I know, 3GPP specs recommends placing NAT or NAT44 function at
PGW. I understand that as being before Gi-LAN.

If this could be clarified, please.

Regards,

Behcet

On Fri, Apr 18, 2014 at 5:29 PM, Jim Guichard (jguichar) <[email-masked]
> wrote:

> http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt ending
> 2nd May 2014.
>
>    expected to modify the document’s content until there is WG consensus that
>    the content is solid. Therefore, please don’t oppose adoption just because
>    you want to see changes to its content.
>    3. If you have issues with the content, by all means raise those
>    issues and we can begin a dialog about how best to address them.
>
>

---

From: Weixinpeng <[email-masked]>
Date: Fri, 25 Apr 2014 09:34:09 +0000

Hi Walter,
Thanks for your answer. And there are some more comments.

I think the following figure is your main solution architecture, am I right? If so, I have some questions:
(1) What is the difference with the 3GPP classifier and SFC classifier ? In my view, I think these two logic function can be integrated each other, i.e. TDF act as these two functions.
In this architecture, which node generate the service chain for certain application?
(2) As it's known, the service chain is generated by the user profile, and 3Gpp related information(i.e. RAT type , RAT load).
These information (RAT type, RAT load,) is the control plane metadata in your draft, am I right?

Do you mean that IETF SFC domain obtain these information (user profile, RAT type, RAT load.) via metadata to generate the service chain?

As my understanding the branching rule you mentioned has the same mean with match rule, e.g. 5-tuple, that used to specify which traffic will go through the SFC graph. Right?

Best Regards,
Xinpeng

From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 6:37 PM
To: Weixinpeng; [email-masked]; [email-masked]
Cc: Xiongchunshan (Sam); Luwei (Wei); Zhouhan (Joe); Zhulei (MBB Research)
Subject: AW: Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Hi Xipeng,

What is your opinion?

Kind regards,

Walter

An: Haeffner, Walter, Vodafone DE; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi,

Thanks,
Xinpeng

Dear WG:

Please note: