Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

From: [email-masked]
Date: Wed, 16 Apr 2014 12:17:49 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Service Function Chaining Problem Statement
        Authors         : Paul Quinn
                          Thomas Nadeau
	Filename        : draft-ietf-sfc-problem-statement-04.txt
	Pages           : 18
	Date            : 2014-04-16

Abstract:
   This document provides an overview of the issues associated with the
   deployment of service functions (such as firewalls, load balancers)
   in large-scale environments.  The term service function chaining is
   used to describe the definition and instantiation of an ordered set
   of instances of such service functions, and the subsequent "steering"
   of traffic flows through those service functions.

   The set of enabled service function chains reflect operator service
   offerings and is designed in conjunction with application delivery
   and service and network policy.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-04

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/

---

From: Lucy yong <[email-masked]>
Date: Wed, 16 Apr 2014 21:30:41 +0000

I like the new text about dataplane metadata in section 3.4.

Cheers,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 16, 2014 2:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Abstract:

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.

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

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Thu, 17 Apr 2014 08:14:45 +0000

I have a totally different view on metadata text. Before we, the SFC WG, get quite clear of the purpose of metadata, how could some possible usage be excluded at such an early stage. And why a problem statement draft limits possible capabilities of the protocol.

Section 4.6. SFC over Service Path Forking in draft-liu-sfc-use-cases-04 provides a use case that metadata may be required to carry information for decision of forwarding paths.

Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, April 17, 2014 5:31 AM
To: [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Cheers,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 16, 2014 2:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Abstract:

---

From: Ron Parker <[email-masked]>
Date: Thu, 17 Apr 2014 13:26:07 +0000

Hongyu,

I took another look at your section 4.6 and agree that it is a valid use case, in general (let's ignore TCP steering complexities for the sake of this discussion).   But perhaps the issue here is terminology.   When I look at that diagram, I think of the DPI function as also containing a reclassifier that determines that a new path ID should be followed.    With that view, the forwarding elements (i.e., Service Function Forwarder) aren't reacting, directly, to the metadata.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Hongyu Li (Julio)
Sent: Thursday, April 17, 2014 4:15 AM
To: [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, April 17, 2014 5:31 AM
To: [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Cheers,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 16, 2014 2:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Abstract:

---

From: Sharon <[email-masked]>
Date: Thu, 17 Apr 2014 06:35:40 -0700

I agree. Text shapes up nicely.
Also re-entrant re-classify recursion spelled out for dynamic forks.
We are starting to see functions designed with programability in mind that need it.

Would like to see the option of metadata as mappable (eid) key at least mentioned.
While it does require some state savings per flow (sfc is very much a flow thing ..),
It helps address the different fields that come up, the per packet overhead, 
out of band complexity-consistency.. reduces the problem to mapping,
something we have to solve anyway in many of the sfc use cases.

--szb

> On Apr 16, 2014, at 14:30, Lucy yong <[email-masked]> wrote:
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 17 Apr 2014 13:49:16 +0000

Hi Sharon,

I would like to just clarify that I understand your second point. I
believe you are saying that you would like the data plane metadata to
carry pointers (rather than the full metadata structure) that may be used
for key access into a more detailed data structure within the SF itself
correct? 

On 4/17/14, 9:35 AM, "Sharon" <[email-masked]> wrote:

>> 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: Ron Parker <[email-masked]>
Date: Thu, 17 Apr 2014 13:54:41 +0000

I think Sharon's use case is very important.   But, so long as the interpretation of metadata is not prescriptive in the problem statement, wouldn't this be more appropriate for the use cases document?

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, April 17, 2014 9:49 AM
To: Sharon; Lucy yong
Cc: [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hi Sharon,

I would like to just clarify that I understand your second point. I believe you are saying that you would like the data plane metadata to carry pointers (rather than the full metadata structure) that may be used for key access into a more detailed data structure within the SF itself correct? 

On 4/17/14, 9:35 AM, "Sharon" <[email-masked]> wrote:

>While it does require some state savings per flow (sfc is very much a 
>flow thing ..), It helps address the different fields that come up, the 
>per packet overhead, out of band complexity-consistency.. reduces the 
>problem to mapping, something we have to solve anyway in many of the 
>sfc use cases.
>
>--szb
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 17 Apr 2014 14:05:30 +0000

I agree that Sharon's use case is very important.  

This metadata feature should be captured in the SFC requirement document. I am surprised in seeing no metadata word mentioned in the requirement doc. yet.

Lucy 

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, April 17, 2014 8:55 AM
To: Jim Guichard (jguichar); Sharon; Lucy yong
Cc: [email-masked]
Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, April 17, 2014 9:49 AM
To: Sharon; Lucy yong
Cc: [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hi Sharon,

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 17 Apr 2014 16:40:50 +0000

When thinking about metadata, I have always had the mapping Sharon mentions in mind. But I agree that probably the problem statement is not the most appropriate place for stating it.

Be goode,

--
"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: SHARON BARKAI <[email-masked]>
Date: Thu, 17 Apr 2014 10:01:44 -0700

yes, its a (tough) challenge we see more of -
namely local forwarding decision based on a global context.
other examples are in the nvo3 and segment routing use cases.

mapping authority (via a key pointer) isn’t a magic solution,
but at least it consolidates the chalange  for multiple wg cases,
it can stay away from union type or complex TLV fields per packet,
and addresses inline/out-of-band race-consitency-releilecy-awarness issues Lucy and Joel raised.

i wouldn’t spell it out in the problem statemet doc,
but would mention the pointer option when introducing metadata. 

On Apr 17, 2014, at 6:49 AM, Jim Guichard (jguichar) <[email-masked]> wrote:

>> flow thing ..),

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Apr 2014 09:00:28 +0000

Hi all,

It said in section 2.6.  Transport Dependence of the PS draft:

  "Service functions can and will be deployed in networks with a range
   of transports, including under and overlays.  The coupling of service
   functions to topology requires service functions to support many
   transport encapsulations or for a transport gateway function to be
   present."

Assume the function of service chain can be divided into two layers: one is the service path layer which is responsible for steering the packets along the service path, the other is the service function layer which is responsible for applying a given service to the packet. I agree that transport dependence is bad for the service function layer. However, I don't understand why transport dependence is also bad for the service path layer. In fact, there are only two underlay transports (i.e., IP and MPLS) which need to be considered for service chain. Therefore, we just need to leverage the source routing capability associated with IP or MPLS to realize the function of the service path layer. That's to say, we can use an ordered list of IP addresses or MPLS labels carried in the packet to represent the service path. A MPLS label in the ordered list of MPLS labels (i.e., a MPLS label stack) or an IP address in the ordered list of IP addresses can be used to indicate either a service node within the service path or a service function on a given service node. Note that MPLS labels and IP addresses have been successfully used for indicating services (e.g., VPN labels and multicast addresses in the range of 224.0.0.x or FF02::x ). 

Of course, if you still think there are too much work to do, you could actually only consider the MPLS-based approach (i.e., using a MPLS label stack to represent a service path) since it could also be applicable in both IPv4 and IPv6 networks with the help of any kind of MPLS over IP encapsulation technologies. 

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
> 发送时间: 2014年4月17日 3:18
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt
> 
>

---

From: Ron Parker <[email-masked]>
Date: Fri, 18 Apr 2014 12:42:40 +0000

Xiaohu,

While the stack of IP addresses is simple, conceptually, it is quite expensive on the wire, especially with IPv6 addresses.   

A stack of MPLS labels is also conceptually simple, but the use of MPLS is not universal, especially within data center environments.   Also, this use of the MPLS labels is somewhat different, semantically, and could cause issues if used concurrently with traditional MPLS use cases.   Especially given that existing MPLS labels are downstream allocated but SFC is essentially source routed.   Perhaps that issue could be solved, but at the expense of a more complex and invasive control plane.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Friday, April 18, 2014 5:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hi all,

Best regards,
Xiaohu

> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 21 Apr 2014 08:26:43 +0000

Hi Ron,

Thanks for your comments. Please see my response inline.

> -----邮件原件-----
> 发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
> 发送时间: 2014年4月18日 20:43
> 收件人: Xuxiaohu; [email-masked]
> 抄送: [email-masked]
> 主题: Re: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D
> Action: draft-ietf-sfc-problem-statement-04.txt
> 
> Xiaohu,
> 
> While the stack of IP addresses is simple, conceptually, it is quite expensive on
> the wire, especially with IPv6 addresses.

Personally I agree. However, it seems that there are a lot of SPs who are in favor of carrying a stack of IPv6 addresses on the IPv6 packet. For more details, please see the IPv6-SR use case draft.

> A stack of MPLS labels is also conceptually simple, but the use of MPLS is not
> universal, especially within data center environments.   Also, this use of the

Within data center environments as you mentioned, the MPLS label stack would just be used for representing a particular service path, and you could still use IP-based tunnels to forward packets from one service node to another (for more details, see http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00). In other word, the MPLS label stack plays the similar role of the service path ID.

> MPLS labels is somewhat different, semantically, and could cause issues if used
> concurrently with traditional MPLS use cases.   Especially given that existing
> MPLS labels are downstream allocated but SFC is essentially source routed.

A MPLS label stack can be used to realize the source routing paradigm, see http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls-01 and http://tools.ietf.org/html/draft-gredler-spring-mpls-03. 

> Perhaps that issue could be solved, but at the expense of a more complex and
> invasive control plane.

How to simply use the MPLS label stack to realize the SFC has been described in http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00. Any comments are welcome.

Best regards,
Xiaohu

> Subject: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D
> Action: draft-ietf-sfc-problem-statement-04.txt
> 
> Hi all,
> 
> Assume the function of service chain can be divided into two layers: one is the
> service path layer which is responsible for steering the packets along the service
> path, the other is the service function layer which is responsible for applying a
> given service to the packet. I agree that transport dependence is bad for the
> service function layer. However, I don't understand why transport dependence
> is also bad for the service path layer. In fact, there are only two underlay
> transports (i.e., IP and MPLS) which need to be considered for service chain.
> Therefore, we just need to leverage the source routing capability associated with
> IP or MPLS to realize the function of the service path layer. That's to say, we can
> use an ordered list of IP addresses or MPLS labels carried in the packet to
> represent the service path. A MPLS label in the ordered list of MPLS labels (i.e., a
> MPLS label stack) or an IP address in the ordered list of IP addresses can be used
> to indicate either a service node within the service path or a service function on
> a given service node. Note that MPLS labels and IP addresses have been
> successfully used for indicating services (e.g., VPN labels and multicast addresses
> in the range of 224.0.0.x or FF02::x ).
> 
> Of course, if you still think there are too much work to do, you could actually
> only consider the MPLS-based approach (i.e., using a MPLS label stack to
> represent a service path) since it could also be applicable in both IPv4 and IPv6
> networks with the help of any kind of MPLS over IP encapsulation technologies.
> 
> Best regards,
> Xiaohu
> 
> 
> > -----邮件原件-----

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Apr 2014 12:29:01 +0200

Hi Xu,

How to simply use the MPLS label stack to realize the SFC has been
> described in http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00.
> Any comments are welcome.
>

​The draft says:​

"that packet, SN1 could further consume the metadata contained in the

NSH and meanwhile decrease the service index value within the NSH by

on
​e​
"​

I would observe after reading this draft that S
​x service node may not be capable of handling NSH of any sort (including
SR header - be it MPLS label stack or IPv6 EHs) therefor much more then
just decreasing the index value is required at SNx.

​It seems that to realize any service chain via most of today's service
nodes a full removal of NSH and re-application is required at directly
attached SNs.

That actually means that network needs to carry the state pretty much out
of band. Such state could be carried within routing protocols (today BGP is
used for that in L3VPN case) or by new overlay control plane - same as is
used to carry the metadata.

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 22 Apr 2014 01:12:17 +0000

Hi Robert,

发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年4月21日 18:29
收件人: Xuxiaohu
抄送: Ron Parker; [email-masked]; [email-masked]
主题: Re: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hi Xu,

​The draft says:​

on

​e​

"​

I would observe after reading this draft that S
​x service node may not be capable of handling NSH of any sort (including SR header - be it MPLS label stack or IPv6 EHs) therefor much more then just decreasing the index value is required at SNx.

​It seems that to realize any service chain via most of today's service nodes a full removal of NSH and re-application is required at directly attached SNs.

[Xiaohu] Your observation is correct. The SF proxy must strip the NSH and the SR header before sending the packets to the directly attached legacy service functions. When the packets was returned by service functions, the SF proxy must reimpose those headers on the packets. Meanwhile, the SF proxy must decrease the service index value by 1.

That actually means that network needs to carry the state pretty much out of band. Such state could be carried within routing protocols (today BGP is used for that in L3VPN case) or by new overlay control plane - same as is used to carry the metadata.

[Xiaohu] Did you mean that the metadata should be transferred through the control plane?

Best regards,
Xiaohu

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Apr 2014 09:28:06 +0200

> [Xiaohu] Your observation is correct. The SF proxy must strip the NSH and the
SR header before sending the packets to the directly attached legacy
service functions. When the packets was returned by service functions,
the SF proxy must reimpose those headers on the packets. Meanwhile,
the SF proxy must decrease the service index value by 1.

Good so we agree on that point.

What actually worries me a bit that to "reimpose" you need to do full
classification again - just like you do it on all ingress nodes.

Moreover how you reimpose could be also a function of service product.

> [Xiaohu] Did you mean that the metadata should be transferred through the control plane?

How else would you carry it ? It's not data plane after all. Of course
perhaps your definition of control plane = routing protocols, but I
did not mean that.

Control plane is just a information overlay of some form. Just like IN
networks in well known telephone networks :)

Cheers,
R.

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 23 Apr 2014 07:06:21 +0000

Hi,

 -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Robert Raszuk
> Sent: Tuesday, April 22, 2014 3:28 PM
> To: Xuxiaohu
> Cc: [email-masked]; Ron Parker; [email-masked]
> Subject: Re: [sfc] 答复: Why Transport Dependence is deemed as a
> problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt
> 
> SR header before sending the packets to the directly attached legacy service
> functions. When the packets was returned by service functions, the SF proxy
> must reimpose those headers on the packets. Meanwhile, the SF proxy must
> decrease the service index value by 1.
> >
> 

Actually we have a draft to talk about the legacy support. First, things have to be classified according to whether the legacy service function instance is transparent or not. Then if it is transparent, you can use different fields in the packet to map to service header and then retrieval it again. If not, things become much more complicated. Here is the link for the draft.
https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/

BR,
-Haibin

> 
> 
> >
> > That actually means that network needs to carry the state pretty much out of
> band. Such state could be carried within routing protocols (today BGP is used
> for that in L3VPN case) or by new overlay control plane - same as is used to
> carry the metadata.
> >
> >
> How else would you carry it ? It's not data plane after all. Of course perhaps
> your definition of control plane = routing protocols, but I did not mean that.
> 
> Control plane is just a information overlay of some form. Just like IN networks
> in well known telephone networks :)
> 
> Cheers,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Apr 2014 10:19:47 +0200

Hi Haibin,

Actually my comments were in regards to non transparent SF (your section 3.2).

And honestly I am not consider those as legacy. IMO even modern
service nodes should not be forced to "handle" SF headers.

So much more focus should be made to make the solutions well
understood as those directly have great impact on the entire network
control plane side. Simply stating removing all the packet/flow state
from the network is not possible.

Cheers,
R.

---

From: <[email-masked]>
Date: Thu, 24 Apr 2014 08:11:36 +0200

Dear Lucy,

A requirement draft I'm aware of (https://tools.ietf.org/html/draft-boucadair-sfc-requirements-04) includes one single item covering this point:

   REQ#22:  The solution MUST allow for the association of a context
            with the data packets.  In particular:

            A.  The solution MUST support the ability to invoke
                differentiated sets of policies for a Service Function
                (such sets of policies are called Profiles).  A profile
                denotes a set of policies configured to a local Service
                Function (e.g., content-filter-child, content-filter-
                adult).

                a.  Few profiles should be assumed per Service Function
                    to accommodate the need for scalable solutions.

                b.  A finer granularity of profiles may be configured
                    directly to each Service Function; there is indeed
                    no need to overload the design of Service Function
                    Chains with policies of low-level granularity.

Additional requirements can be added to capture and record the wg inputs. I would prefer to see first the document adopted as WG item before going that path.

Back to the point mentioned by Sharon, I do think this is worth to be considered but not in the problem statement document.

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de Lucy yong
>Envoyé : jeudi 17 avril 2014 16:06
>À : Ron Parker; Jim Guichard (jguichar); Sharon
>Cc : [email-masked]
>Objet : Re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt
>
>This metadata feature should be captured in the SFC requirement document. I
>am surprised in seeing no metadata word mentioned in the requirement doc.
>yet.
>
>Lucy
>
>I think Sharon's use case is very important.   But, so long as the
>interpretation of metadata is not prescriptive in the problem statement,
>wouldn't this be more appropriate for the use cases document?
>
>   Ron
>
>
>I would like to just clarify that I understand your second point. I believe
>you are saying that you would like the data plane metadata to carry
>pointers (rather than the full metadata structure) that may be used for key
>access into a more detailed data structure within the SF itself correct?
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 Apr 2014 15:36:17 +0000

Hi Mohamed,

Thank you for the explanation. If the metadata means the association of a context with the data packets, it is better to explicitly mention that "metadata" is often term used to such context in the requirement draft as well. This will make the requirement document better aligns with other PS and other documents. In standard, we often spend a lot of time to make censuses on one term and/or one description. 

In PS doc, it defines and explains the data plane metadata, which is one way to convey the association of a context with the data packets, there are other ways to convey such association.  

Current description in REQ#22 is not clear to me. Profiles/policies are described as some configuration at local Service Function. It is hard to draw any relationship to the association of a context with the data packets. Since the association of a context with data packets or metadata is one of main characteristics that SFC will supports, it is very important for req. doc to depict the requirements on the metadata. 

Sharon's case expresses a requirement on data plane metadata. They are others, e.g. the solution MUST provide the association between the metadata and its associated data packets in real time. I agree that we should not state such requirement in PS doc.

SFC needs a requirement doc. for sure. IMO: setting a pre-condition for continually working on a doc. is not proper. It is chair's responsibility to determine when to adopt; editor's responsibility to capture the right stuff in a doc..

Thanks,
Lucy   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 24, 2014 1:12 AM
To: Lucy yong; Ron Parker; Jim Guichard (jguichar); Sharon
Cc: [email-masked]
Subject: RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

Dear Lucy,

Cheers,
Med

>De : sfc [mailto:[email-masked]] De la part de Lucy yong Envoyé : 
>jeudi 17 avril 2014 16:06 À : Ron Parker; Jim Guichard (jguichar); 
>Sharon Cc : [email-masked] Objet : Re: [sfc] I-D Action: 
>draft-ietf-sfc-problem-statement-04.txt
>
>This metadata feature should be captured in the SFC requirement 
>document. I am surprised in seeing no metadata word mentioned in the requirement doc.
>yet.
>
>Lucy
>
>interpretation of metadata is not prescriptive in the problem 
>statement, wouldn't this be more appropriate for the use cases document?
>
>   Ron
>
>
>carry pointers (rather than the full metadata structure) that may be 
>used for key access into a more detailed data structure within the SF itself correct?
>
>>flow thing ..), It helps address the different fields that come up, 
>>the per packet overhead, out of band complexity-consistency.. reduces 
>>the problem to mapping, something we have to solve anyway in many of 
>>the sfc use cases.
>>
>>--szb
>>

---

From: <[email-masked]>
Date: Fri, 25 Apr 2014 08:52:24 +0200

Hi Lucy,

This requirement draft uses the term "context" because this is the term used in the sfc charter:

"
   - communicates context information between nodes that implement 
     service functions and Service Function Chains.
"

Cheers,
Med

>De : Lucy yong [mailto:[email-masked]]
>Envoyé : jeudi 24 avril 2014 17:36
>À : BOUCADAIR Mohamed IMT/OLN; Ron Parker; Jim Guichard (jguichar); Sharon
>Cc : [email-masked]
>Objet : RE: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt
>
>Hi Mohamed,
>
>Thank you for the explanation. If the metadata means the association of a
>context with the data packets, it is better to explicitly mention that
>"metadata" is often term used to such context in the requirement draft as
>well. This will make the requirement document better aligns with other PS
>and other documents. In standard, we often spend a lot of time to make
>censuses on one term and/or one description.
>
>In PS doc, it defines and explains the data plane metadata, which is one
>way to convey the association of a context with the data packets, there are
>other ways to convey such association.
>
>Current description in REQ#22 is not clear to me. Profiles/policies are
>described as some configuration at local Service Function. It is hard to
>draw any relationship to the association of a context with the data
>packets. Since the association of a context with data packets or metadata
>is one of main characteristics that SFC will supports, it is very important
>for req. doc to depict the requirements on the metadata.
>
>Sharon's case expresses a requirement on data plane metadata. They are
>others, e.g. the solution MUST provide the association between the metadata
>and its associated data packets in real time. I agree that we should not
>state such requirement in PS doc.
>
>SFC needs a requirement doc. for sure. IMO: setting a pre-condition for
>continually working on a doc. is not proper. It is chair's responsibility
>to determine when to adopt; editor's responsibility to capture the right
>stuff in a doc..
>
>Thanks,
>Lucy
>
>A requirement draft I'm aware of (https://tools.ietf.org/html/draft-
>boucadair-sfc-requirements-04) includes one single item covering this
>point:
>
>Additional requirements can be added to capture and record the wg inputs. I
>would prefer to see first the document adopted as WG item before going that
>path.
>
>Back to the point mentioned by Sharon, I do think this is worth to be
>considered but not in the problem statement document.
>
>Cheers,
>Med
>