Subject: [sfc] draft-rijsman-sfc-metadata-considerations

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 3 Mar 2014 06:35:06 -0500

I like the doc - well written.

Section 4.3 on metadata encoding.

It seems there's clear need for variable sized metadata
(at least for http/app you  seem to indicate the desire for it).
For a datapath per-packet metadata, i feel the need is just as important.
Are we limited by the fact that existing hardware may not be
able to handle TLVs? For example, I dont have a problem handling TLVs in a
software datapath.

cheers,
jamal

---

From: Ron Parker <[email-masked]>
Date: Mon, 3 Mar 2014 13:42:35 +0000

Jamal,

As an alternative, the network service header could contain a fixed mandatory portion and a variable optional portion.   The fixed mandatory portion would contain the total length of the service header (fixed portion plus optional portion).   This approach would allow entities concerned solely with SFC steering to easily ignore the metatadata which is intended to be consumed and/or repeated by the various service functions.

   Ron

---Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Monday, March 03, 2014 11:35 AM
To: [email-masked]; [email-masked]
Cc: sfc
Subject: [sfc] draft-rijsman-sfc-madata-considerations

It seems there's clear need for variable sized metadata (at least for http/app you  seem to indicate the desire for it).
For a datapath per-packet metadata, i feel the need is just as important.
Are we limited by the fact that existing hardware may not be able to handle TLVs? For example, I dont have a problem handling TLVs in a software datapath.

cheers,
jamal

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 3 Mar 2014 08:46:34 -0500

Ron,

I will be happy with such a compromise.

cheers,
jamal

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 3 Mar 2014 17:07:43 +0000

We need to be a bit careful with large metadata, specifically from
architectural considerations. Let me give you an example:
SFC SC1 :: SF1@SN1 : SF2@SN5 : SF3@SN8

SN1 & SN8 can deal with metadata and need the metadata. However, SN5
can't, it is a legacy SN. What do we do with the metadata when it comes to
steering the packet (only) to SN5 - throw it, cache it, say not supported Š

Surendra.

On 3/3/14 1:42 PM, "Ron Parker" <[email-masked]> wrote:

>Jamal,
>
>As an alternative, the network service header could contain a fixed
>mandatory portion and a variable optional portion.   The fixed mandatory
>portion would contain the total length of the service header (fixed
>portion plus optional portion).   This approach would allow entities
>concerned solely with SFC steering to easily ignore the metatadata which
>is intended to be consumed and/or repeated by the various service
>functions.
>
>   Ron
>
>
>---Original Message-----
>It seems there's clear need for variable sized metadata (at least for
>http/app you  seem to indicate the desire for it).
>Are we limited by the fact that existing hardware may not be able to
>handle TLVs? For example, I dont have a problem handling TLVs in a
>software datapath.
>
>cheers,
>jamal
>

---

From: Ron Parker <[email-masked]>
Date: Mon, 3 Mar 2014 17:36:34 +0000

A legacy SF would be front ended by an SFC proxy which would strip and readd the encapsulation.   The size or variability of the encapsulation doesn't enter into that aspect of it. 

   Ron

> On Mar 3, 2014, at 5:07 PM, "Surendra Kumar (smkumar)" <[email-masked]> wrote:
> 
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 3 Mar 2014 13:16:31 -0500

I think ignoring the metadata you dont understand is the sane thing to
do.

cheers,
jamal

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 3 Mar 2014 19:11:33 +0000

The below description is about proxy - we need to define the behavior.

Surendra.

On 3/3/14 5:36 PM, "Ron Parker" <[email-masked]> wrote:

>A legacy SF would be front ended by an SFC proxy which would strip and
>readd the encapsulation.   The size or variability of the encapsulation
>doesn't enter into that aspect of it.
>
>   Ron
>
>

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 3 Mar 2014 20:05:30 +0000

Ron,

A proxy approach would work for metadata that can be reconstructed from a fairly static & predefined context. But I don't see how we this can do that for more session/flow/packet-specific metadata.

Take an example. Say a form of accounting-session-id is attached to all packets for service functions (say SN1 and SN8 in the example below) to generate their own accounting logs in such a way that they can be correlated by an accounting server. The service chain starts (SF0/SN0) by a BNG or PGW which assigns such an accounting-session-id based on its knowledge of user sessions. 

SN5 doesn't recognize such metadata. At best, the proxy will strip it before forwarding to SN5. Which processes the packet and ends up generating some data flow towards SN8 (maybe the same packet, maybe modified or new packets). 

Then if traffic associated with multiple sessions has to traverse SN5 in a concurrent manner, I just don't know how a proxy approach can work to reconstruct what SN8 needs. Do you?

Personally, I reached a conclusion that we can deal with metadata-aware service chains and with metadata-neutral service chains, but a mix of both seems hard to achieve, at least when using packet header ('inband marking') techniques. This is what we meant in the challenge described in section 4.2.

Tx
Jerome

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 2:12 PM
To: Ron Parker
Cc: Jamal Hadi Salim; Jerome Moisand; Bruno Rijsman; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Surendra.

On 3/3/14 5:36 PM, "Ron Parker" <[email-masked]> wrote:

>>can't, it is a legacy SN. What do we do with the metadata when it 
>>comes to  steering the packet (only) to SN5 - throw it, cache it, say 
>>not supported Š
>> 
>> 
>> Surendra.
>> 
>>> concerned solely with SFC steering to easily ignore the metatadata 
>>>which  is intended to be consumed and/or repeated by the various 
>>>service  functions.
>>> 
>>>  Ron
>>> 
>>> 
>>> ---Original Message-----
>>> It seems there's clear need for variable sized metadata (at least 
>>>for  http/app you  seem to indicate the desire for it).

---

From: Ron Parker <[email-masked]>
Date: Mon, 3 Mar 2014 22:49:34 +0000

It is true that functions like an HTTP proxy or SIP proxy may emit packets towards the core that don't correlate with packets received from the access and therefore, may not be good candidates to function in an SFC-unaware mode of operation.   NAT is another counter example, creating the same problem but by a different mechanism.   This is a great motivator to make those functions SFC-aware :).

However, before we discard the concept of proxy for legacy services entirely, there are some service functions that would function quite nicely in this mode of operation.   Some that come to mind are inline TDF, PCEF, and non-NAT firewall.

   Ron

-----Original Message-----
From: Bruno Rijsman [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 9:07 PM
To: Jerome Moisand; Surendra Kumar (smkumar); Ron Parker
Cc: Jamal Hadi Salim; sfc
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

To rephrase and possibly clarify what Jerome already said: stripping and re-attaching metadata is very difficult if not impossible.

Imagine that a proxy receives a packet P, strips and buffers the meta-data, and injects the stripped packet P into the Service Function.

The proxy has to re-attach the buffered meta-data when the Service Function has finished processing the packet P and sends it out again.

The difficult part is: how does the proxy recognize packet P when it is sent out again?

There may be multiple packets 'in transit' with the exact same 5-tuple.

The service function may drop, re-order, insert packets.

The service function may modify packets, including the 5-tuple (e.g. NAT or non-transparent proxy).

-- Bruno

-----Original Message-----
From: Jerome Moisand 
Sent: Monday, March 03, 2014 3:06 PM
To: Surendra Kumar (smkumar); Ron Parker
Cc: Jamal Hadi Salim; Bruno Rijsman; sfc
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Ron,

Tx
Jerome

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 2:12 PM
To: Ron Parker
Cc: Jamal Hadi Salim; Jerome Moisand; Bruno Rijsman; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Surendra.

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 4 Mar 2014 01:22:27 +0000

This is somewhat similar to how Radius/Diameter handles vendor specific
AVPs. A vendor can define its own AVP. Upon receipt a node will process
the AVP it is interested and ignore rest of them.

I am NOT suggesting a AVP scheme for SFC header at all for many reasons. I
also think there will be some well known metadata options that will make
sense for vast majority of applications and it will be worthwhile to
figure those out. For example say HTTP proxy needs to insert a per
subscriber value XYZ which is only interesting to another proxy device.
Devices already use http header insertion/removal for this type of
metadata exchange and there is no need to pollute SFC metadata.

However if a proxy enhances the classification result then that may be
worthwhile to put into SFC metadata.

Regards.

Sumandra

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 4 Mar 2014 09:34:43 +0000

Want to add one more point to what Sumandra said. 

It is important to make it clear who "consumes" the metadata. Is it the "service function" that consumes the Metadata? Or is it the "network node"?

For all the use cases presented at SFC session, I noticed the following characteristics of metadata:

1. the "metadata" are "consumed" by the "service functions". 

2. The metadata are associated with "flows". 

Today's "metadata" to (or among) service functions are either handled by messages or service functions themselves. They don't need network nodes to terminate or add extra headers. 

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Monday, March 03, 2014 7:22 PM
To: Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

This is somewhat similar to how Radius/Diameter handles vendor specific AVPs. A vendor can define its own AVP. Upon receipt a node will process the AVP it is interested and ignore rest of them.

I am NOT suggesting a AVP scheme for SFC header at all for many reasons. I also think there will be some well known metadata options that will make sense for vast majority of applications and it will be worthwhile to figure those out. For example say HTTP proxy needs to insert a per subscriber value XYZ which is only interesting to another proxy device.
Devices already use http header insertion/removal for this type of metadata exchange and there is no need to pollute SFC metadata.

However if a proxy enhances the classification result then that may be worthwhile to put into SFC metadata.

Regards.

Sumandra

On 3/3/14, 9:07 AM, "Surendra Kumar (smkumar)" <[email-masked]> wrote:

>can't, it is a legacy SN. What do we do with the metadata when it comes 
>to steering the packet (only) to SN5 - throw it, cache it, say not 
>supported Š
>
>
>Surendra.
>

---

From: Alla Goldner <[email-masked]>
Date: Tue, 4 Mar 2014 09:43:24 +0000

Hi Linda,

What do you mean by "2. The metadata are associated with "flows"."?

Some of the presentations associated metadata with "Application identifier" (correctly, I believe). 

Best regards,

Alla Goldner
Director of Mobile Technologies and Standards
Allot Communications
Tel +972 9 7619251
Cell +972 54 2493985
Fax +972 9 7443626
[email-masked] 
www.allot.com

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, March 04, 2014 11:35 AM
To: Sumandra Majee; Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Monday, March 03, 2014 7:22 PM
To: Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Regards.

Sumandra

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc
##############################################################################################
This message is intended only for the designated recipient(s).It may contain confidential or proprietary information.
If you are not the designated recipient, you may not review, copy or distribute this message.
If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. 
Thank you.
##############################################################################################

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 4 Mar 2014 10:13:58 +0000

I interpret packets associated with an "application" as a flow, do you? 

linda

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]] 
Sent: Tuesday, March 04, 2014 3:43 AM
To: Linda Dunbar; Sumandra Majee; Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Linda,

Best regards,

Alla Goldner
Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 [email-masked] www.allot.com

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, March 04, 2014 11:35 AM
To: Sumandra Majee; Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Monday, March 03, 2014 7:22 PM
To: Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Regards.

Sumandra

---

From: Alla Goldner <[email-masked]>
Date: Tue, 4 Mar 2014 10:41:18 +0000

Hi Linda,

In case service data flows are deducible (i.e. can be communicated in such a way that it doesn't create extensive signaling overload) - application can be identified by those service data flows (e.g. 5 tuples) without necessarily an explicit means for application identifier.
In case it can't be done (so called applications with non-deducible service data flow) - means of Application identifier are required. In this particular case, medatada would be associated with Application Identifier, in case of a need.

Best regards,

Alla Goldner

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Tuesday, March 04, 2014 12:14 PM
To: Alla Goldner; Sumandra Majee; Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

linda

-----Original Message-----
From: Alla Goldner [mailto:[email-masked]]
Sent: Tuesday, March 04, 2014 3:43 AM
To: Linda Dunbar; Sumandra Majee; Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Linda,

Best regards,

Alla Goldner

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, March 04, 2014 11:35 AM
To: Sumandra Majee; Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Monday, March 03, 2014 7:22 PM
To: Surendra Kumar (smkumar); Ron Parker; Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Regards.

Sumandra

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 4 Mar 2014 15:47:45 +0000

Let me start and say that there have to be tradeoffs in supporting legacy
SNs and just as such in supporting advanced functionality.

Flow aware proxies can support "concise" metadata - this what I originally
alluded to. Further, metadata is assumed to be fairly static for the life
of the flow. I can't think of any example where it is not true although
there may be some and I don't know if they are worth solving.

IOW, flow awareness and concise metadata is the key. Lack of which we need
to reclassify to determine the metadata which will be expensive.

Obviously, we are trying to accommodate legacy services and it is not
unfair to have constraints.

Surendra.

On 3/3/14 9:06 PM, "Bruno Rijsman" <[email-masked]> wrote:

>To rephrase and possibly clarify what Jerome already said: stripping and
>re-attaching metadata is very difficult if not impossible.
>
>Imagine that a proxy receives a packet P, strips and buffers the
>meta-data, and injects the stripped packet P into the Service Function.
>
>The proxy has to re-attach the buffered meta-data when the Service
>Function has finished processing the packet P and sends it out again.
>
>A proxy approach would work for metadata that can be reconstructed from a
>fairly static & predefined context. But I don't see how we this can do
>that for more session/flow/packet-specific metadata.
>
>Take an example. Say a form of accounting-session-id is attached to all
>packets for service functions (say SN1 and SN8 in the example below) to
>generate their own accounting logs in such a way that they can be
>correlated by an accounting server. The service chain starts (SF0/SN0) by
>a BNG or PGW which assigns such an accounting-session-id based on its
>knowledge of user sessions.
>
>SN5 doesn't recognize such metadata. At best, the proxy will strip it
>before forwarding to SN5. Which processes the packet and ends up
>generating some data flow towards SN8 (maybe the same packet, maybe
>modified or new packets).
>
>Then if traffic associated with multiple sessions has to traverse SN5 in
>a concurrent manner, I just don't know how a proxy approach can work to
>reconstruct what SN8 needs. Do you?
>
>Personally, I reached a conclusion that we can deal with metadata-aware
>service chains and with metadata-neutral service chains, but a mix of
>both seems hard to achieve, at least when using packet header ('inband
>marking') techniques. This is what we meant in the challenge described in
>section 4.2.
>
>Tx
>Jerome
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 4 Mar 2014 15:59:23 +0000

Sumandra,

>the AVP it is interested and ignore rest of them.
SK> Ah, the proxy we are talking is not a proxy SF/SN. It is SFC proxy -
arch component. The scenario is that there is a legacy SN in the middle of
two SNs that are SFC-service header aware. In which case, the legacy SN
will not receive any metadata, so no question of ignoring part of it.

>worthwhile to put into SFC metadata.
SK> Speaking generally, yes, metadata does add value. Where I see lot of
confusion exists is in trying overlaid the data plane with something that
should be handled out-of-band or via control-palne.

Surendra.
>>to

---

From: Bruno Rijsman <[email-masked]>
Date: Mon, 3 Mar 2014 21:06:38 +0000

-- Bruno

-----Original Message-----
From: Jerome Moisand 
Sent: Monday, March 03, 2014 3:06 PM
To: Surendra Kumar (smkumar); Ron Parker
Cc: Jamal Hadi Salim; Bruno Rijsman; sfc
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Ron,

Tx
Jerome

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 2:12 PM
To: Ron Parker
Cc: Jamal Hadi Salim; Jerome Moisand; Bruno Rijsman; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Surendra.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 04 Mar 2014 11:22:58 -0500

You assert that metadata is static for the life of the flow.  While that 
is true of some metadata (for example, the subscriber ID), it is untrue 
of other metadata.  For example, if the metadata reflects the result of 
DPI, then on an HTTP connection it will change for each request or reply 
that is seen (of which there are many on one TCP connection, which is 
one flow.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 4 Mar 2014 16:46:28 +0000

I'm saying it is mostly static, IOW, does not change on every packet.

Surendra.

On 3/4/14 4:22 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>> The service function may modify packets, including the 5-tuple (e.g.
>>>NAT
>>> or non-transparent proxy).
>>>
>>> -- Bruno
>>>

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 4 Mar 2014 20:00:27 +0000

>>Further, metadata is assumed to be fairly static for the life
of the flow.

Depends on the App and what the service chain is configured for. But the
above statement is not really true for vast majority of HTTP traffic. As
Joel said there could be a static part like subscriber id and variable
part. For example consider the classification of a generic youtube flow
and it goes something like,
   1) SYN pkt: IP and TCP   > classification_metadata : IP, TCP
   2) Next few incoming: HTTP  > IP, TCP, HTTP
   3) Response1: > IP, TCP, HTTP, perhaps says javascript
   4) Req2/Response2 : IP, TCP, HTTP, Image
   5) If the same flow starts the video feed then the classification
result would actually change from Image->video

Assuming metadata would be static is a very sweeping assumption that I am
not comfortable with.

Our own product would benefit if the previous node could have annotated a
flow with metadata when the product is configured for dynamic service
chaining. The experience also taught us that different metadata has
different lifetime.

Regards.

Sumandra

---

From: David Allan I <[email-masked]>
Date: Wed, 5 Mar 2014 10:54:48 +0000

I'm leaning towards "impossible"

I was thinking serialization with a timeout was the only ugly hack possible (which converts firewalls into huge bottlenecks), but if the SF can reorder packets, even that cannot be made to work.

D

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Bruno Rijsman
Sent: Monday, March 03, 2014 9:07 PM
To: Jerome Moisand; Surendra Kumar (smkumar); Ron Parker
Cc: sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

-- Bruno

-----Original Message-----
From: Jerome Moisand 
Sent: Monday, March 03, 2014 3:06 PM
To: Surendra Kumar (smkumar); Ron Parker
Cc: Jamal Hadi Salim; Bruno Rijsman; sfc
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Ron,

Tx
Jerome

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 2:12 PM
To: Ron Parker
Cc: Jamal Hadi Salim; Jerome Moisand; Bruno Rijsman; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Surendra.

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 5 Mar 2014 11:26:16 +0000

While I can appreciate this discussion, I STILL have not seen a suggestion
that doesn't provide a better benefit/performance trade-off than imbedded
metadata (or why it SHOULDN'T be used).

Preservation of metadata in a chain when a non-compliant device is
involved will be fraught with an "external-response-loop" problem whether
you went with an oob server or an oob communication protocol (assuming a
non-compliant device doesn't implement the oob communication protocol -
truly non-compliant), particularly for the per-packet, dynamic examples
cited.  

For those cases where this dynamic is not the case, the "static" metadata
cases, burdening them with the oob server (which remains "optional" with
the SFC metadata header - as described earlier, use the SPI as an external
lookup key if you so choose) and/or an oob communication/control_plane
protocol (more to implement on each SFC, which IMO, will just
protract/expand the field of non-compliant devices) doesn't seem to be a
very good option (to me) ...when (it seems) everyone agrees that some of the
more dynamic problems are intractable.

Was there a proposal that I missed?

On 3/5/14 5:54 AM, "David Allan I" <[email-masked]> wrote:

>I was thinking serialization with a timeout was the only ugly hack
>possible (which converts firewalls into huge bottlenecks), but if the SF
>can reorder packets, even that cannot be made to work.
>
>D
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 5 Mar 2014 15:30:43 +0000

We may be mixing multiple things here.

Inline. 

On 3/4/14 8:00 PM, "Sumandra Majee" <[email-masked]> wrote:

>above statement is not really true for vast majority of HTTP traffic.
SK> I responded earlier - read "mostly and not every pkt".

>As
SK> First, This boils down to carrying an ApplicationID which changes from
Javascript to Image to Video in your example.
All L4-7 SNs should be able to understand IP, TCP, HTTP and I know you
don't mean to suggest a DPI is need to tell them about the basic
protocols. I can see a nonstandard port case, which may be an exception.

Second,the APP-ID can be carried to the SNs if they understand the
service-header or can be cached in the SFC-proxy. I don't see a problem
here.

Third, a flow cannot exist without providing a good-put. IOW, after the 5
message, there is a probably a couple of seconds of Video coming down the
pipe ?

>Assuming metadata would be static is a very sweeping assumption that I am
SK> see above

>chaining. The experience also taught us that different metadata has
SK> if the product supports whatever service header SFC standardizes, it
should benefit.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 5 Mar 2014 19:18:34 +0000

Let me change the question a little; assume that *all* SF's along a given service chain are  *metadata capable* (can process SFC encap without the need for a proxy). In this case do you see a problem?

Sent from my iPhone

> On Mar 3, 2014, at 3:06 PM, "Jerome Moisand" <[email-masked]> wrote:
> 
> Ron,
>

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 5 Mar 2014 19:58:10 +0000

Having fun in London? ;-)

Yes, this is what I was pondering about, have homogeneously service chains, either metadata capable (all SFs involved) or metadata-neutral (none of them). Not perfect, but could be good enough. Maybe add some stitching capable/neutral. 

Note that when I say 'metadata-neutral', this is from the perspective of the data plane (aka inband marking, or lack thereof), but this doesn't preclude an SF to use some out-of-band mechanism to get such metadata. Control plane or some other way (e.g. database query). Or maybe it doesn't need to at all.

Then the questions would shift a bit:

1. what is the most reasonable way (protocol-wise) to assemble metadata-neutral service chains? (i.e. address the service path layer described in section 4.8 of the I-D and no more)

2. if we assume packet inband marking (ala NSH) for metadata-aware service chains, is there a reasonable way (programmer-friendly) to inject SF-level metadata in SF software using traditional APIs (sockets, etc)? Is it more practical than 'other means' (e.g. out-of-band, etc)? Would an hybrid approach of sorts be valuable? Weigh pros & cons...

Cheers,
Jerome

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2014 2:19 PM
To: Jerome Moisand
Cc: Surendra Kumar (smkumar); Ron Parker; Bruno Rijsman; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Sent from my iPhone

>>> comes to  steering the packet (only) to SN5 - throw it, cache it, 
>>> say not supported Š
>>> 
>>> 
>>> Surendra.
>>> 
>>>> Are we limited by the fact that existing hardware may not be able 
>>>> to handle TLVs? For example, I dont have a problem handling TLVs in 
>>>> a software datapath.
>>>> 
>>>> cheers,
>>>> jamal
>>>>

---

From: Ron Parker <[email-masked]>
Date: Wed, 5 Mar 2014 20:18:10 +0000

When we say metadata capable, let's be precise about what constitutes metadata.   In previous discussion, the information necessary for steering (i.e., the presumed chain id) is not considered to be metadata.   So, conceptually, a service function could be cognizant of both the steering aspects and the metadata, the steering aspects only, or neither.    We've pretty much agreed that being ignorant of the steering aspects is not feasible except for simplistic service functions that neither change nor initiate fully qualified flows.    On the other hand, being ignorant of metadata seems to pose little problem to most service functions unless they are built around a supposition of always having some particular kind of metatadata (e.g., an IMSI or MSISDN value).

Regarding implementation issues around sockets, etc., I don't think that should unduly flavor what we are trying to accomplish.   Different implementations will have different restrictions and different ways of overcoming those restrictions.

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2014 7:58 PM
To: Jim Guichard (jguichar)
Cc: Surendra Kumar (smkumar); Ron Parker; Bruno Rijsman; sfc; Jamal Hadi Salim
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Cheers,
Jerome

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, March 05, 2014 2:19 PM
To: Jerome Moisand
Cc: Surendra Kumar (smkumar); Ron Parker; Bruno Rijsman; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Sent from my iPhone

---

From: Qin Wu <[email-masked]>
Date: Thu, 6 Mar 2014 12:59:47 +0000

Regarding what the metadata is , One thing confusing me here is how metadata is distributed to SFs in the service chain, by control plane or by data plane? 
Is metadata processed by some of SFs in the service chain or by all the SFs in the service chain? Can some of SFs ignore the metadata processing?

Regards!
-Qin

-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年3月6日 4:18
收件人: Jerome Moisand; Jim Guichard (jguichar)
抄送: Bruno Rijsman; Surendra Kumar (smkumar); sfc; Jamal Hadi Salim
主题: Re: [sfc] draft-rijsman-sfc-metadata-considerations

   Ron

-----Original Message-----
From: Jerome Moisand [mailto:[email-masked]]
Sent: Wednesday, March 05, 2014 7:58 PM
To: Jim Guichard (jguichar)
Cc: Surendra Kumar (smkumar); Ron Parker; Bruno Rijsman; sfc; Jamal Hadi Salim
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Cheers,
Jerome

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Wednesday, March 05, 2014 2:19 PM
To: Jerome Moisand
Cc: Surendra Kumar (smkumar); Ron Parker; Bruno Rijsman; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Sent from my iPhone

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 6 Mar 2014 13:02:30 +0000

Hi Jamal,

You said "It seems there's clear need for variable sized metadata".. I am
not so convinced and would like to better understand the requirements
before passing judgement. If we look at the use cases as presented thus
far into the WG I have yet to see a single example of the need (noting
that desire is not the same as need) - I am not saying there is no
requirement but rather that we should not jump to the conclusion and build
standards around a theory.

---

From: Thomas D Nadeau <[email-masked]>
Date: Thu, 6 Mar 2014 13:08:25 +0000

very good point!

> On Mar 6, 2014, at 13:02, "Jim Guichard (jguichar)" <[email-masked]> wrote:
> 
> Hi Jamal,
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 6 Mar 2014 09:20:14 -0500

On Thu, Mar 6, 2014 at 8:02 AM, Jim Guichard (jguichar)
<[email-masked]> wrote:
> before passing judgement.

Thanks for not passing judgement.  Two reasons:
The app level metadata stuff needs it. I was infering that the packet
level stuff needs because we need it in ForCES (and there was several
postings that stated this was the case; the obstacle seems to be it is hard
to do in hardware).

In the case of ForCES:
We have s/ware implementations which are deployed (and is part of our
current charter).
My desire is to find common ground - we need to work on other
transports at ForCES.
And this could be that opportunity where we dont have to go and invent our own.

>If we look at the use cases as presented thus

The mailing list is supposed to be complementing those discussions. It is what
I am doing.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 06 Mar 2014 09:50:10 -0500

The answer is clearly that multiple mechanisms are quite possible.
For example, if the operating environment has systems which correlate IP 
address and policy data, the applications may contact those systems for 
information.  That has nothing to do with service chaining.

Since we are defining the service chainging data plane encapsulation, 
the issue for us to particularly to define the mechanism for carrying 
in-band metadata.

The APIs or packet processing used by the applications to access that 
metadata are probably something we need to make sure can be provided. 
it is not clear that we want to.  For one thing, it may be different in 
different application environments.

Yours,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 6 Mar 2014 16:30:25 +0000

Hi Jerome,

> 1. what is the most reasonable way (protocol-wise) to assemble metadata-neutral service chains? (i.e. address the service path layer described in section 4.8 of the I-D and no more)

PQ>  In the dataplane, we've defined the concept of a SFC encap proxy.  Using this element, metadata-neutral (or  "non-participant") node receives packets without the encap (and therefore without the associated metadata).

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 6 Mar 2014 16:31:18 +0000

Ron,

Some comments inline.

Paul

On Mar 5, 2014, at 3:18 PM, Ron Parker <[email-masked]> wrote:

> When we say metadata capable, let's be precise about what constitutes metadata.   In previous discussion, the information necessary for steering (i.e., the presumed chain id) is not considered to be metadata.   So, conceptually, a service function could be cognizant of both the steering aspects and the metadata, the steering aspects only, or neither.    We've pretty much agreed that being ignorant of the steering aspects is not feasible except for simplistic service functions that neither change nor initiate fully qualified flows.

PQ>  We need to be a bit more specific here with how we define "ignorant".  A SF does not need to know how to steer, or where to steer to (wrt transport), but in many cases, being able to alter both steering and perhaps "location" within a graph are key.

>    On the other hand, being ignorant of metadata seems to pose little problem to most service functions unless they are built around a supposition of always having some particular kind of metatadata (e.g., an IMSI or MSISDN value).
> 

PQ>  Many services, today, utilize implicit metadata, usually delivered via overloaded fields or via some form of control plane binding.  

> Regarding implementation issues around sockets, etc., I don't think that should unduly flavor what we are trying to accomplish.   Different implementations will have different restrictions and diff…

PQ>  I'm with you :)

---

From: Ron Parker <[email-masked]>
Date: Thu, 6 Mar 2014 18:19:16 +0000

Hi, Paul.

I think the relevant point is the level of isolation between the SF and SFF that are proposed in draft-quinn-sfc-arch.   Since many service functions can modify the 5-tuple header and/or initiate subordinate flows, it becomes necessary to transfer the steering-related information (i.e., chain-id) bidirectionally between the SF and SFF.    Strictly speaking, this doesn't make the SF fully cognizant of how to steer traffic, but there is a relationship between the SF and the steering function for this class of SF's.   As we've discussed, only a class of simplistic SF's can avoid knowledge of even the chain-id.

   Ron

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Thursday, March 06, 2014 4:31 PM
To: Ron Parker
Cc: Jerome Moisand; Jim Guichard (jguichar); Bruno Rijsman; Surendra Kumar (smkumar); sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Ron,

Some comments inline.

Paul

PQ>  I'm with you :)

> 1. what is the most reasonable way (protocol-wise) to assemble 
> metadata-neutral service chains? (i.e. address the service path layer 
> described in section 4.8 of the I-D and no more)
> 
>>>> SN1 & SN8 can deal with metadata and need the metadata. However, 
>>>> SN5 can't, it is a legacy SN. What do we do with the metadata when 
>>>> it comes to  steering the packet (only) to SN5 - throw it, cache 
>>>> it, say not supported Š
>>>> 
>>>> 
>>>> Surendra.
>>>> 
>>>>> to handle TLVs? For example, I dont have a problem handling TLVs 
>>>>> in a software datapath.
>>>>> 
>>>>> cheers,
>>>>> jamal
>>>>>

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 6 Mar 2014 20:39:10 +0000

[SM] A DPI typically doesn¹t classify a flow as HTTP based on port 80. It
is an indication and that is combined with the knowledge of packet length,
HDR presence etc. So this step is typically happening at 4/5th pkt of the
flow.

[SM]Yes it is possible to remember all previous app id. However if the
flow morphs into a different type then the service node might be confused.
For example transaction 1 has a mime-type of image followed by a video
trans (mime-type mp4). Some of these are perhaps implementation detail but
we should call those out.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 6 Mar 2014 21:14:44 +0000

Hi Ron,

On Mar 6, 2014, at 1:19 PM, Ron Parker <[email-masked]> wrote:

> Hi, Paul.
> 
> I think the relevant point is the level of isolation between the SF and SFF that are proposed in draft-quinn-sfc-arch.   Since many service functions can modify the 5-tuple header and/or initiate subordinate flows, it becomes necessary to transfer the steering-related information (i.e., chain-id) bidirectionally between the SF and SFF.    Strictly speaking, this doesn't make the SF fully cognizant of how to steer traffic, but there is a relationship between the SF and the steering function for this class of SF's.  

Yes, the SF doesn't know anything about steering from a forwarding perspective, however, it can change information used later for path selection.  The reason I draw this architecture distinction is that I want to ensure there's no (accidental) implication that SFs understand forwarding (i.e. contain routing or switching table).  Rather, using our framework, they, when needed, manipulate a simple identifier.

>  As we've discussed, only a class of simplistic SF's can avoid knowledge of even the chain-id.

Agreed :)

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Fri, 7 Mar 2014 08:34:12 +0000

Hello Jim

I have seen cases in Gi LAN, where subscriber related information is passed to a Web Proxy for HTTP header enrichment (aimed at some
Web Content providers partners of the Mobile Operator). Information was an coded (persistent) subscriber id derived from the MSISDN, and couple of f
customer profile related fields.

In an sfc based Gi LAN, this entity should receive from the Classifier

- A classification of the Content Provider ( Id, Category) based on traffic analysis
- The MSISDN of the subscriber
- Two subscriber policy fields (not tied to PCRF but belonging to the Subscriber DB) (Subscriber category, sub-category)
- A session id (for logging and tracking purposes)

The objective being to avoid having  the HTTP Proxy to become a trusted application (interogate the subscriber DB, etc..)

Nicolas

________________________________________
From: Jim Guichard (jguichar) [[email-masked]]
Sent: Thursday, March 06, 2014 2:02 PM
To: Jamal Hadi Salim; [email-masked]; [email-masked]
Cc: sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Jamal,

---

From: Ron Parker <[email-masked]>
Date: Fri, 7 Mar 2014 08:52:21 +0000

Nicolas,

I see similar requirements from the 3gpp EPC side.  I would like to propose an OUI / TLV based approach where the reserved OUI can be used for agreed upon types of common metadata and vendor or other organizational OUIs can be used to quickly innovate in the networks.   Simultaneously, I would also like to consider mechanisms that are optimized for long lived flows so as to limit the negative effects of packet growth. 

   Ron

> On Mar 7, 2014, at 8:34 AM, "Nicolas BOUTHORS" <[email-masked]> wrote:
> 
> Hello Jim
>

---

From: Pankaj Garg <[email-masked]>
Date: Fri, 7 Mar 2014 09:25:38 +0000

I agree with Ron. There is similar requirement on the datacenter networks to be able to pass metadata. The proposed encapsulation (draft-gross-geneve-00) allows metadata to be carried using an OUI/TLV based approach. The metadata can be standard based metadata or vendor specific metadata. A single frame can carry multiple vendor specific metadata as well. The solution is not tied to service chaining itself and allows metadata to be usable for cases beyond service chaining such as carrying secure hash of the packet in the metadata etc.

Thanks
Pankaj

> From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
> Sent: Friday, March 7, 2014 2:22 PM
> To: Nicolas BOUTHORS
> Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
> I see similar requirements from the 3gpp EPC side.  I would like to propose an
> OUI / TLV based approach where the reserved OUI can be used for agreed
> upon types of common metadata and vendor or other organizational OUIs
> can be used to quickly innovate in the networks.   Simultaneously, I would
> also like to consider mechanisms that are optimized for long lived flows so as
> to limit the negative effects of packet growth.
> 
>    Ron
> 
> 
> > I have seen cases in Gi LAN, where subscriber related information is
> > passed to a Web Proxy for HTTP header enrichment (aimed at some Web
> > Content providers partners of the Mobile Operator). Information was an
> coded (persistent) subscriber id derived from the MSISDN, and couple of f
> > - Two subscriber policy fields (not tied to PCRF but belonging to the
> > Subscriber DB) (Subscriber category, sub-category)
> > The objective being to avoid having  the HTTP Proxy to become a
> > trusted application (interogate the subscriber DB, etc..)
> >
> >
> > Nicolas
> >
> >
> > You said "It seems there's clear need for variable sized metadata".. I
> > am not so convinced and would like to better understand the
> > requirements before passing judgement. If we look at the use cases as
> > presented thus far into the WG I have yet to see a single example of
> > the need (noting that desire is not the same as need) - I am not
> > saying there is no requirement but rather that we should not jump to
> > the conclusion and build standards around a theory.
> >
> >
> >

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 11 Mar 2014 17:48:43 +0000

Hi Ron,

We can certainly have this discussion but we should first consider what information is necessary and if said information can fit within a fixed number of contexts in the majority of cases. Remember, the goal of being able to pass metadata through the network is to enhance service delivery, not pass the entire works of Shakespeare ;-)

Sent from my iPhone

> On Mar 7, 2014, at 3:52 AM, "Ron Parker" <[email-masked]> wrote:
> 
> Nicolas,
>

---

From: Ron Parker <[email-masked]>
Date: Tue, 11 Mar 2014 19:19:02 +0000

Jim,

At the Vancouver meeting, there was a nice presentation that showed 2 cooperative and non-contiguous service functions.   The first one added a service-function-specific priority value to the packet.   The other service-function interpreted that value for overload control purposes.    I think that is an innovative use case that points to the need for flexible metadata.     Getting agreement on how many nuggets of some fixed sized metadata that will be supported will not be impossible, IMO.

    Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2014 1:49 PM
To: Ron Parker
Cc: Nicolas BOUTHORS; Jamal Hadi Salim; [email-masked]; [email-masked]; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Ron,

Sent from my iPhone

>> Content providers partners of the Mobile Operator). Information was an coded (persistent) subscriber id derived from the MSISDN, and couple of f customer profile related fields.
>> 
>> You said "It seems there's clear need for variable sized metadata".. 
>> I am not so convinced and would like to better understand the

---

From: Ron Parker <[email-masked]>
Date: Tue, 11 Mar 2014 19:30:37 +0000

Sorry, typo.

I meant:

	Getting agreement on how many nuggets of some fixed sized metadata that will be supported will not be possible, IMO.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, March 11, 2014 3:19 PM
To: Jim Guichard (jguichar)
Cc: Nicolas BOUTHORS; [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Jim,

    Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 1:49 PM
To: Ron Parker
Cc: Nicolas BOUTHORS; Jamal Hadi Salim; [email-masked]; [email-masked]; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Ron,

Sent from my iPhone

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 11 Mar 2014 19:51:36 +0000

Why do you need variable length metadata for this use case?

Sent from my iPhone

> On Mar 11, 2014, at 3:19 PM, "Ron Parker" <[email-masked]> wrote:
> 
> Jim,
>

---

From: Ron Parker <[email-masked]>
Date: Tue, 11 Mar 2014 19:59:51 +0000

Jim,

I don't see how we can anticipate what form every type of metadata will take that will be useful to existing and future service functions.   I also don't see how we can anticipate exactly how many pieces of metadata would be necessary at any point along the chain.  By attempting to do so, I feel we would be limiting innovation. 

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2014 3:52 PM
To: Ron Parker
Cc: Nicolas BOUTHORS; Jamal Hadi Salim; [email-masked]; [email-masked]; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Sent from my iPhone

> We can certainly have this discussion but we should first consider 
> what information is necessary and if said information can fit within a 
> fixed number of contexts in the majority of cases. Remember, the goal 
> of being able to pass metadata through the network is to enhance 
> service delivery, not pass the entire works of Shakespeare ;-)
> 
> Sent from my iPhone
> 
>>> - Two subscriber policy fields (not tied to PCRF but belonging to 
>>> the Subscriber DB) (Subscriber category, sub-category)
>>> requirements before passing judgement. If we look at the use cases 
>>> as presented thus far into the WG I have yet to see a single example 
>>> of the need (noting that desire is not the same as need) - I am not

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 12 Mar 2014 08:09:06 +0000

I think we must make a distinction between:

- Metadata which should be part of the header defined as in band marking.
- Metadata with can be passed out of band, for example congruent out of band signaling defined in the draft

The former calls for a limited space in the header, true, The latter however does not incur any space limitation and is still fairly efficient and it remains compatible with a fixed size header used to route those signaling messages along the chain's service functions.

Nicolas
Sent: Tuesday, March 11, 2014 6:48 PM

Hi Ron,

Sent from my iPhone

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 12 Mar 2014 08:12:05 +0000

+1

On 12/03/14 09:09, "Nicolas BOUTHORS" <[email-masked]> wrote:

>The former calls for a limited space in the header, true, The latter
>however does not incur any space limitation and is still fairly efficient
>and it remains compatible with a fixed size header used to route those
>signaling messages along the chain's service functions.
>
>Nicolas
>We can certainly have this discussion but we should first consider what
>information is necessary and if said information can fit within a fixed
>number of contexts in the majority of cases. Remember, the goal of being
>able to pass metadata through the network is to enhance service delivery,
>not pass the entire works of Shakespeare ;-)
>
>Sent from my iPhone
>
>> I see similar requirements from the 3gpp EPC side.  I would like to
>>propose an OUI / TLV based approach where the reserved OUI can be used
>>for agreed upon types of common metadata and vendor or other
>>organizational OUIs can be used to quickly innovate in the networks.
>>Simultaneously, I would also like to consider mechanisms that are
>>optimized for long lived flows so as to limit the negative effects of
>>packet growth.
>>
>>   Ron
>>
>>
>>>passed to a Web Proxy for HTTP header enrichment (aimed at some
>>> Web Content providers partners of the Mobile Operator). Information
>>>was an coded (persistent) subscriber id derived from the MSISDN, and
>>>couple of f
>>>am

---

From: Ron Parker <[email-masked]>
Date: Wed, 12 Mar 2014 11:43:14 +0000

Nicolas,

I understand the concept for out of band signaling of metadata, but I am concerned that it introduces significant complexity due to the potential race condition of receiving the real packet before the metadata.  While the real packet could indicate that out of band metadata is expected, how can we guarantee the order of reception?  What if switching or routing nodes apply hash based load balancing?  What if the load balancing understands SFC encaps and looks beyond it to the original header to get better entropy?  Can we guarantee that the metadata and real packet will follow the exact same path?  If we can not, then implementations will need to add ingress queuing to cope with the scenario. 

Also, do you feel that the increase in implementation complexity at the service functions is reasonable?

Thanks. 

   Ron

> On Mar 12, 2014, at 4:09 AM, "Nicolas BOUTHORS" <[email-masked]> wrote:
>

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 12 Mar 2014 12:52:16 +0000

Hello Ron,

Sending out of band congruent metadata may not be the answer to all needs but it is one tool 
that we should keep.

Not all metadata is tied to a specific packet, for example a policy change in PCRF could lead
to some metadata signaling, the reaction time need not be immediate, few ms may not matter.

As you point, if a packet is tied to a metadata a correlation info can be set in both packet to 
deal with it (i.e metadata expected flag in the SFC header, plus an id)

Finally we can still send some limited metadata within a header. This could be used for load balancers
in particular if we agree on a convention to locate "coarse grain policy" / "fine grain policy" on reserved context 
headers. 

This seems to open up a lot of flexibility / innovations.

On your last point, there is a question on how to make metadata available to a Service Function. Current 
socket connections for example do not allow to retrieve IP header options. So I assume that SFC aware Service Functions will need some (asynchronous ?) API to retrieve SFC header information as well as in-band metadata.   I don't see out of band metadata transport adding complexity,  the same API can probably apply.

The alternative option, allowing variable sized metadata in the SFC header has some drawbacks as well,
one being fragmentation, and some switches expecting as well to look at end user traffic headers for link load balancing.  I would agree that if we can accept these issues, then sending off-line congruent metadata looses 
its interest.

We need to take into account  that both in-band and congruent out-of-band metadata transport is not reliable. A packet loss  triggering retransmission would not lead to the identical reconstruction of the associated metadata.  
In some cases, we might thus even need non-congruent out-of-band reliable metadata transport.

Nicolas
________________________________________
From: Ron Parker [[email-masked]]
Sent: Wednesday, March 12, 2014 12:43 PM
To: Nicolas BOUTHORS
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Nicolas,

Thanks.

   Ron

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Mar 2014 13:25:12 +0000

Of course that particular priority use-case can be accomplished with IPv4 ToS or IPv6 Traffic Class.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, March 11, 2014 3:19 PM
To: Jim Guichard (jguichar)
Cc: Nicolas BOUTHORS; [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Jim,

    Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2014 1:49 PM
To: Ron Parker
Cc: Nicolas BOUTHORS; Jamal Hadi Salim; [email-masked]; [email-masked]; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Ron,

Sent from my iPhone

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Mar 2014 10:21:21 -0400

For in-band metadata, the API for access can easily be synchronous.
Out of band metadata needs different handling.
There are many cases where out-of-band metadata is useful and 
appropriate.  But they do not cover all needs by any stretch.

Even if each piece of in-band metadata is of fixed length, there are 
many different kinds of metatype.  Trying to say "there will be exactly 
four pieces, and they will be of types t1, t2, t3, and t4" is simply too 
specific for even 80% of the needs.

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 14:42:48 +0000

Fully agree with Joe.

We should not require a fix length for in-band metadata but also not leave it for freely usage. In fact, when a service node inserts SFC header on a (encapsulated) packet and send to next service node, SFC header itself can be seen as a metadata. 

Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, March 12, 2014 9:21 AM
To: Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

For in-band metadata, the API for access can easily be synchronous.
Out of band metadata needs different handling.
There are many cases where out-of-band metadata is useful and appropriate.  But they do not cover all needs by any stretch.

Even if each piece of in-band metadata is of fixed length, there are many different kinds of metatype.  Trying to say "there will be exactly four pieces, and they will be of types t1, t2, t3, and t4" is simply too specific for even 80% of the needs.

Yours,
Joel

On 3/12/14, 8:52 AM, Nicolas BOUTHORS wrote:
> Hello Ron,
>
> Sending out of band congruent metadata may not be the answer to all 
> needs but it is one tool that we should keep.
>
> Not all metadata is tied to a specific packet, for example a policy 
> change in PCRF could lead to some metadata signaling, the reaction time need not be immediate, few ms may not matter.
>
> As you point, if a packet is tied to a metadata a correlation info can 
> be set in both packet to deal with it (i.e metadata expected flag in 
> the SFC header, plus an id)
>
> Finally we can still send some limited metadata within a header. This 
> could be used for load balancers in particular if we agree on a 
> convention to locate "coarse grain policy" / "fine grain policy" on reserved context headers.
>
> The alternative option, allowing variable sized metadata in the SFC 
> header has some drawbacks as well, one being fragmentation, and some 
> switches expecting as well to look at end user traffic headers for link load balancing.  I would agree that if we can accept these issues, then sending off-line congruent metadata looses its interest.
>
>> what information is necessary and if said information can fit within 
>> a fixed number of contexts in the majority of cases. Remember, the 
>> goal of being able to pass metadata through the network is to enhance 
>>>> I have seen cases in Gi LAN, where subscriber related information 
>>>> is passed to a Web Proxy for HTTP header enrichment (aimed at some 
>>>> Web Content providers partners of the Mobile Operator). Information was an coded (persistent) subscriber id derived from the MSISDN, and couple of f customer profile related fields.
>>>>
>>>> You said "It seems there's clear need for variable sized 
>>>> metadata".. I am not so convinced and would like to better 
>>>> understand the requirements before passing judgement. If we look at 
>>>> the use cases as presented thus far into the WG I have yet to see a 
>>>> single example of the need (noting that desire is not the same as 
>>>> need) - I am not saying there is no requirement but rather that we 
>>>> should not jump to the conclusion and build standards around a theory.
>>>>
>>>>
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Mar 2014 12:17:50 -0400

I think it is important to keep a strong distinction between metadata
(which is for use by applications) and the service chaining information
in the base service chain header, which is for use by the service chain
support mechanisms.

Yours,
Joel

On 3/12/14, 10:42 AM, Lucy yong wrote:
> Fully agree with Joe.
>
> We should not require a fix length for in-band metadata but also not
> leave it for freely usage. In fact, when a service node inserts SFC
> header on a (encapsulated) packet and send to next service node, SFC
> header itself can be seen as a metadata.
>
> Lucy
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Joel M. Halpern Sent: Wednesday, March 12, 2014 9:21 AM To:
> Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard (jguichar);
> [email-masked]; sfc; Jamal Hadi Salim Subject: Re: [sfc]
> draft-rijsman-sfc-metadata-considerations
>
> Out of band metadata needs different handling. There are many cases
> where out-of-band metadata is useful and appropriate.  But they do
> not cover all needs by any stretch.
>
> many different kinds of metatype.  Trying to say "there will be
> exactly four pieces, and they will be of types t1, t2, t3, and t4" is
> simply too specific for even 80% of the needs.
>
> Yours, Joel
>
>> Sending out of band congruent metadata may not be the answer to
>> all needs but it is one tool that we should keep.
>>
>> Not all metadata is tied to a specific packet, for example a
>> policy change in PCRF could lead to some metadata signaling, the
>> reaction time need not be immediate, few ms may not matter.
>>
>> As you point, if a packet is tied to a metadata a correlation info
>> can be set in both packet to deal with it (i.e metadata expected
>> flag in the SFC header, plus an id)
>>
>> Finally we can still send some limited metadata within a header.
>> This could be used for load balancers in particular if we agree on
>> a convention to locate "coarse grain policy" / "fine grain policy"
>> on reserved context headers.
>>
>> On your last point, there is a question on how to make metadata
>> available to a Service Function. Current socket connections for
>> example do not allow to retrieve IP header options. So I assume
>> that SFC aware Service Functions will need some (asynchronous ?)
>> API to retrieve SFC header information as well as in-band metadata.
>> I don't see out of band metadata transport adding complexity,  the
>> same API can probably apply.
>>
>> The alternative option, allowing variable sized metadata in the
>> SFC header has some drawbacks as well, one being fragmentation, and
>> some switches expecting as well to look at end user traffic headers
>> for link load balancing.  I would agree that if we can accept these
>> issues, then sending off-line congruent metadata looses its
>> interest.
>>
>> We need to take into account  that both in-band and congruent
>> out-of-band metadata transport is not reliable. A packet loss
>> triggering retransmission would not lead to the identical
>> reconstruction of the associated metadata. In some cases, we might
>> thus even need non-congruent out-of-band reliable metadata
>> transport.
>>
>>
>>
>> Nicolas ________________________________________ From: Ron Parker
>> [[email-masked]] Sent: Wednesday, March 12, 2014
>> 12:43 PM To: Nicolas BOUTHORS Cc: Jim Guichard (jguichar);
>> [email-masked]; sfc; Jamal Hadi Salim Subject: Re: [sfc]
>> draft-rijsman-sfc-metadata-considerations
>>
>> Nicolas,
>>
>> I understand the concept for out of band signaling of metadata, but
>> I am concerned that it introduces significant complexity due to the
>> potential race condition of receiving the real packet before the
>> metadata.  While the real packet could indicate that out of band
>> metadata is expected, how can we guarantee the order of reception?
>> What if switching or routing nodes apply hash based load balancing?
>> What if the load balancing understands SFC encaps and looks beyond
>> it to the original header to get better entropy?  Can we guarantee
>> that the metadata and real packet will follow the exact same path?
>> If we can not, then implementations will need to add ingress
>> queuing to cope with the scenario.
>>
>>> - Metadata which should be part of the header defined as in band
>>> marking. - Metadata with can be passed out of band, for example
>>> congruent out of band signaling defined in the draft
>>>
>>> The former calls for a limited space in the header, true, The
>>> latter however does not incur any space limitation and is still
>>> fairly efficient and it remains compatible with a fixed size
>>> header used to route those signaling messages along the chain's
>>> service functions.
>>>
>>> Nicolas ________________________________________ From: Jim
>>> Guichard (jguichar) [[email-masked]] Sent: Tuesday, March 11,
>>> 2014 6:48 PM To: Ron Parker Cc: Nicolas BOUTHORS;
>>> [email-masked]; sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>> draft-rijsman-sfc-metadata-considerations
>>>
>>> Hi Ron,
>>>
>>> We can certainly have this discussion but we should first
>>> consider what information is necessary and if said information
>>> can fit within a fixed number of contexts in the majority of
>>> cases. Remember, the goal of being able to pass metadata through
>>> the network is to enhance service delivery, not pass the entire
>>> works of Shakespeare ;-)
>>>
>>> Sent from my iPhone
>>>
>>>> I see similar requirements from the 3gpp EPC side.  I would
>>>> like to propose an OUI / TLV based approach where the reserved
>>>> OUI can be used for agreed upon types of common metadata and
>>>> vendor or other organizational OUIs can be used to quickly
>>>> innovate in the networks.   Simultaneously, I would also like
>>>> to consider mechanisms that are optimized for long lived flows
>>>> so as to limit the negative effects of packet growth.
>>>>
>>>> Ron
>>>>
>>>>
>>>>> I have seen cases in Gi LAN, where subscriber related
>>>>> information is passed to a Web Proxy for HTTP header
>>>>> enrichment (aimed at some Web Content providers partners of
>>>>> the Mobile Operator). Information was an coded (persistent)
>>>>> subscriber id derived from the MSISDN, and couple of f
>>>>> - A classification of the Content Provider ( Id, Category)
>>>>> based on traffic analysis - The MSISDN of the subscriber -
>>>>> Two subscriber policy fields (not tied to PCRF but belonging
>>>>> to the Subscriber DB) (Subscriber category, sub-category) - A
>>>>> session id (for logging and tracking purposes)
>>>>>
>>>>> The objective being to avoid having  the HTTP Proxy to become
>>>>> a trusted application (interogate the subscriber DB, etc..)
>>>>>
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>> ________________________________________ From: Jim Guichard
>>>>> (jguichar) [[email-masked]] Sent: Thursday, March 06,
>>>>> 2014 2:02 PM To: Jamal Hadi Salim; [email-masked];
>>>>> [email-masked] Cc: sfc Subject: Re: [sfc]
>>>>> draft-rijsman-sfc-metadata-considerations
>>>>>
>>>>> Hi Jamal,
>>>>>
>>>>> understand the requirements before passing judgement. If we
>>>>> look at the use cases as presented thus far into the WG I
>>>>> have yet to see a single example of the need (noting that
>>>>> desire is not the same as need) - I am not saying there is no
>>>>> requirement but rather that we should not jump to the
>>>>> conclusion and build standards around a theory.
>>>>>
>>>>>
>>>>>
>>>>>> It seems there's clear need for variable sized metadata (at
>>>>>> least for http/app you  seem to indicate the desire for
>>>>>> it). For a datapath per-packet metadata, i feel the need is
>>>>>> just as important. Are we limited by the fact that existing
>>>>>> hardware may not be able to handle TLVs? For example, I
>>>>>> dont have a problem handling TLVs in a software datapath.
>>>>>>
>>>>>> cheers, jamal
>>>>>>
>>>>>> _______________________________________________ sfc mailing
>>>>>> list [email-masked]
>>>>> _______________________________________________ sfc mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>>
>>>
>>
>> _______________________________________________ sfc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 12 Mar 2014 16:38:55 +0000

+1.

‹ Carlos.

-----Original Message-----
From: Joel Halpern <[email-masked]>
Date: Wednesday, March 12, 2014 at 12:17 PM
To: Lucy yong <[email-masked]>, Nicolas BOUTHORS
<[email-masked]>, Ron Parker <[email-masked]>
Cc: Jim Guichard <[email-masked]>, "[email-masked]"
<[email-masked]>, sfc <[email-masked]>, Jamal Hadi Salim
<[email-masked]>
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 17:19:35 +0000

Hi Joel,

I agree. We need to differentiate the metadata used by service function and SFC header. The metadata term means carrying some states along with the packet. IMO: SFC header is a kind of metadata carried on packet for next service node to use. In the context of SFC, we have term for SFC header and the metadata that was carried between service functions, or between service functions and classifiers/service nodes, which is what the draft focus.

Thanks,
Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2014 11:18 AM
To: Lucy yong; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

I think it is important to keep a strong distinction between metadata (which is for use by applications) and the service chaining information in the base service chain header, which is for use by the service chain support mechanisms.

Yours,
Joel

On 3/12/14, 10:42 AM, Lucy yong wrote:
> where out-of-band metadata is useful and appropriate.  But they do not 
> cover all needs by any stretch.
>
>> change in PCRF could lead to some metadata signaling, the reaction 
>> time need not be immediate, few ms may not matter.
>>
>> can be set in both packet to deal with it (i.e metadata expected flag 
>> in the SFC header, plus an id)
>>
>> This could be used for load balancers in particular if we agree on a 
>> example do not allow to retrieve IP header options. So I assume that 
>> SFC aware Service Functions will need some (asynchronous ?) API to 
>> retrieve SFC header information as well as in-band metadata.
>> switches expecting as well to look at end user traffic headers for 
>> link load balancing.  I would agree that if we can accept these 
>> issues, then sending off-line congruent metadata looses its interest.
>>
>> thus even need non-congruent out-of-band reliable metadata transport.
>>
>>
>>
>> I understand the concept for out of band signaling of metadata, but I 
>> am concerned that it introduces significant complexity due to the 
>> What if the load balancing understands SFC encaps and looks beyond it 
>> to the original header to get better entropy?  Can we guarantee that 
>> the metadata and real packet will follow the exact same path?
>> If we can not, then implementations will need to add ingress queuing 
>> to cope with the scenario.
>>
>>> however does not incur any space limitation and is still fairly 
>>> efficient and it remains compatible with a fixed size header used to 
>>> route those signaling messages along the chain's service functions.
>>>
>>> Nicolas ________________________________________ From: Jim Guichard 
>>> (jguichar) [[email-masked]] Sent: Tuesday, March 11,
>>> goal of being able to pass metadata through the network is to 
>>> enhance service delivery, not pass the entire works of Shakespeare 
>>> ;-)
>>>
>>> Sent from my iPhone
>>>
>>>> propose an OUI / TLV based approach where the reserved OUI can be 
>>>> used for agreed upon types of common metadata and vendor or other 
>>>> organizational OUIs can be used to quickly
>>>> to consider mechanisms that are optimized for long lived flows so 
>>>> as to limit the negative effects of packet growth.
>>>>
>>>> Ron
>>>>
>>>>
>>>>> Web Content providers partners of the Mobile Operator). 
>>>>> Information was an coded (persistent) subscriber id derived from 
>>>>> the MSISDN, and couple of f customer profile related fields.
>>>>>
>>>>> - A classification of the Content Provider ( Id, Category) based 
>>>>> on traffic analysis - The MSISDN of the subscriber - Two 
>>>>> subscriber policy fields (not tied to PCRF but belonging to the 
>>>>> Subscriber DB) (Subscriber category, sub-category) - A session id 
>>>>> (for logging and tracking purposes)
>>>>>
>>>>> understand the requirements before passing judgement. If we look 
>>>>> at the use cases as presented thus far into the WG I have yet to 
>>>>> see a single example of the need (noting that desire is not the 
>>>>> same as need) - I am not saying there is no requirement but rather 
>>>>> that we should not jump to the conclusion and build standards 
>>>>> around a theory.
>>>>>
>>>>>
>>>>>
>>>>>> for http/app you  seem to indicate the desire for it). For a 
>>>>>> datapath per-packet metadata, i feel the need is just as 
>>>>>> important. Are we limited by the fact that existing hardware may 
>>>>>> not be able to handle TLVs? For example, I dont have a problem 
>>>>>> handling TLVs in a software datapath.
>>>>>>
>>>>>> cheers, jamal
>>>>>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 12 Mar 2014 13:24:48 -0400

Lucy, you say "the metadata term means ..."  The definition you then 
provide is a definition of the set of information we are proposing that 
we put in the SFC header.  I, and others, have been using the term 
metadata more narrowly.  We can use whatever definition we want.  But we 
do need to agree on the definition.
For the purposes of the WG, it seems much more useful to use the term 
metadata for the narrower description.

Yours,
Joel

On 3/12/14, 1:19 PM, Lucy yong wrote:
> Hi Joel,
>
> I agree. We need to differentiate the metadata used by service
> function and SFC header. The metadata term means carrying some states
> along with the packet. IMO: SFC header is a kind of metadata carried
> on packet for next service node to use. In the context of SFC, we
> have term for SFC header and the metadata that was carried between
> service functions, or between service functions and
> classifiers/service nodes, which is what the draft focus.
>
> Thanks, Lucy
>
>
>
>
>
> -----Original Message----- From: Joel M. Halpern
> [mailto:[email-masked]] Sent: Wednesday, March 12, 2014 11:18
> AM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard
> (jguichar); [email-masked]; sfc; Jamal Hadi Salim Subject: Re:
> [sfc] draft-rijsman-sfc-metadata-considerations
>
> (which is for use by applications) and the service chaining
> information in the base service chain header, which is for use by the
> service chain support mechanisms.
>
> Yours, Joel
>
>> We should not require a fix length for in-band metadata but also
>> not leave it for freely usage. In fact, when a service node inserts
>> SFC header on a (encapsulated) packet and send to next service
>> node, SFC header itself can be seen as a metadata.
>>
>> Lucy
>>
>> -----Original Message----- From: sfc [mailto:[email-masked]]
>> On Behalf Of Joel M. Halpern Sent: Wednesday, March 12, 2014 9:21
>> AM To: Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard (jguichar);
>> For in-band metadata, the API for access can easily be
>> synchronous. Out of band metadata needs different handling. There
>> are many cases where out-of-band metadata is useful and
>> Even if each piece of in-band metadata is of fixed length, there
>> are many different kinds of metatype.  Trying to say "there will
>> be exactly four pieces, and they will be of types t1, t2, t3, and
>> t4" is simply too specific for even 80% of the needs.
>>
>> Yours, Joel
>>
>>> As you point, if a packet is tied to a metadata a correlation
>>> info can be set in both packet to deal with it (i.e metadata
>>> expected flag in the SFC header, plus an id)
>>>
>>> This could be used for load balancers in particular if we agree
>>> on a convention to locate "coarse grain policy" / "fine grain
>>> policy" on reserved context headers.
>>>
>>> API to retrieve SFC header information as well as in-band
>>> metadata. I don't see out of band metadata transport adding
>>> complexity,  the same API can probably apply.
>>>
>>> SFC header has some drawbacks as well, one being fragmentation,
>>> and some switches expecting as well to look at end user traffic
>>> headers for link load balancing.  I would agree that if we can
>>> accept these issues, then sending off-line congruent metadata
>>> looses its interest.
>>>
>>> reconstruction of the associated metadata. In some cases, we
>>> might thus even need non-congruent out-of-band reliable metadata
>>> transport.
>>>
>>>
>>>
>>> Nicolas ________________________________________ From: Ron
>>> Parker [[email-masked]] Sent: Wednesday, March
>>> 12, 2014 12:43 PM To: Nicolas BOUTHORS Cc: Jim Guichard
>>> (jguichar); [email-masked]; sfc; Jamal Hadi Salim Subject:
>>> Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>
>>> Nicolas,
>>>
>>> I understand the concept for out of band signaling of metadata,
>>> but I am concerned that it introduces significant complexity due
>>> to the potential race condition of receiving the real packet
>>> before the metadata.  While the real packet could indicate that
>>> out of band metadata is expected, how can we guarantee the order
>>> of reception? What if switching or routing nodes apply hash based
>>> load balancing? What if the load balancing understands SFC encaps
>>> and looks beyond it to the original header to get better entropy?
>>> Can we guarantee that the metadata and real packet will follow
>>> the exact same path? If we can not, then implementations will
>>> need to add ingress queuing to cope with the scenario.
>>>
>>>> - Metadata which should be part of the header defined as in
>>>> band marking. - Metadata with can be passed out of band, for
>>>> example congruent out of band signaling defined in the draft
>>>>
>>>> Guichard (jguichar) [[email-masked]] Sent: Tuesday, March
>>>> 11, 2014 6:48 PM To: Ron Parker Cc: Nicolas BOUTHORS;
>>>> cases. Remember, the goal of being able to pass metadata
>>>> through the network is to enhance service delivery, not pass
>>>> the entire works of Shakespeare ;-)
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> like to propose an OUI / TLV based approach where the
>>>>> reserved OUI can be used for agreed upon types of common
>>>>> metadata and vendor or other organizational OUIs can be used
>>>>> to quickly innovate in the networks.   Simultaneously, I
>>>>> would also like to consider mechanisms that are optimized for
>>>>> long lived flows so as to limit the negative effects of
>>>>> packet growth.
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>>> Two subscriber policy fields (not tied to PCRF but
>>>>>> belonging to the Subscriber DB) (Subscriber category,
>>>>>> sub-category) - A session id (for logging and tracking
>>>>>> purposes)
>>>>>>
>>>>>> The objective being to avoid having  the HTTP Proxy to
>>>>>> become a trusted application (interogate the subscriber DB,
>>>>>> etc..)
>>>>>>
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>> ________________________________________ From: Jim
>>>>>> Guichard (jguichar) [[email-masked]] Sent: Thursday,
>>>>>> March 06, 2014 2:02 PM To: Jamal Hadi Salim;
>>>>>> [email-masked]; [email-masked] Cc: sfc Subject:
>>>>>> Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>>>
>>>>>> Hi Jamal,
>>>>>>
>>>>>> desire is not the same as need) - I am not saying there is
>>>>>> no requirement but rather that we should not jump to the
>>>>>>> (at least for http/app you  seem to indicate the desire
>>>>>>> for it). For a datapath per-packet metadata, i feel the
>>>>>>> need is just as important. Are we limited by the fact
>>>>>>> that existing hardware may not be able to handle TLVs?
>>>>>>> For example, I dont have a problem handling TLVs in a
>>>>>>> software datapath.
>>>>>>>
>>>>>>> cheers, jamal
>>>>>>>
>>>>>>> _______________________________________________ sfc
>>>>>>> mailing list [email-masked]
>>>>>> _______________________________________________ sfc
>>>>>> mailing list [email-masked]

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 18:13:15 +0000

Hi Joel,

I agree that we need using the same definition for a term, but disagree that the metadata definition here is a set of information put in the SFC header. This may be too narrow or lead to a particular solution. I am fine with this definition in the problem statement w/ minor tweak (suggested on mailing list).

Dataplane Metadata: Data plane metadata provides the ability to
       exchange information between the classifiers and service functions,
       between service functions, and service functions and the classifiers|service nodes.

There may be a solution that a service function passes some information to attached service node without using SFC header.

Thanks,
Lucy

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2014 12:25 PM
To: Lucy yong; Joel M. Halpern; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Lucy, you say "the metadata term means ..."  The definition you then provide is a definition of the set of information we are proposing that we put in the SFC header.  I, and others, have been using the term metadata more narrowly.  We can use whatever definition we want.  But we do need to agree on the definition.
For the purposes of the WG, it seems much more useful to use the term metadata for the narrower description.

Yours,
Joel

On 3/12/14, 1:19 PM, Lucy yong wrote:
> on packet for next service node to use. In the context of SFC, we have 
> term for SFC header and the metadata that was carried between service 
> functions, or between service functions and classifiers/service nodes, 
> which is what the draft focus.
>
> Thanks, Lucy
>
>
>
>
>
> [mailto:[email-masked]] Sent: Wednesday, March 12, 2014 11:18 AM 
> To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard 
>>> retrieve SFC header information as well as in-band metadata. I don't 
>>> see out of band metadata transport adding complexity,  the same API 
>>> can probably apply.
>>>
>>> [email-masked]; sfc; Jamal Hadi Salim Subject:
>>> it to the original header to get better entropy?
>>> Can we guarantee that the metadata and real packet will follow the 
>>> exact same path? If we can not, then implementations will need to 
>>> add ingress queuing to cope with the scenario.
>>>
>>>> fairly efficient and it remains compatible with a fixed size header 
>>>> used to route those signaling messages along the chain's service 
>>>> functions.
>>>>
>>>> (jguichar) [[email-masked]] Sent: Tuesday, March 11, 2014 6:48 
>>>> PM To: Ron Parker Cc: Nicolas BOUTHORS; [email-masked]; sfc; 
>>>> Jamal Hadi Salim Subject: Re: [sfc] 
>>>> what information is necessary and if said information can fit 
>>>> within a fixed number of contexts in the majority of cases. 
>>>> Remember, the goal of being able to pass metadata through the 
>>>> network is to enhance service delivery, not pass the entire works 
>>>> of Shakespeare ;-)
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> I see similar requirements from the 3gpp EPC side.  I would like 
>>>>> to propose an OUI / TLV based approach where the reserved OUI can 
>>>>> be used for agreed upon types of common metadata and vendor or 
>>>>> other organizational OUIs can be used
>>>>> would also like to consider mechanisms that are optimized for long 
>>>>> lived flows so as to limit the negative effects of packet growth.
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>>> is passed to a Web Proxy for HTTP header enrichment (aimed at 
>>>>>> some Web Content providers partners of the Mobile Operator). 
>>>>>> Subscriber DB) (Subscriber category,
>>>>>> (jguichar) [[email-masked]] Sent: Thursday, March 06, 2014 
>>>>>> 2:02 PM To: Jamal Hadi Salim; [email-masked]; 
>>>>>> [email-masked] Cc: sfc Subject:
>>>>>> same as need) - I am not saying there is no requirement but 
>>>>>> rather that we should not jump to the conclusion and build 
>>>>>>> least for http/app you  seem to indicate the desire for it). For 
>>>>>>> a datapath per-packet metadata, i feel the need is just as 
>>>>>>> not be able to handle TLVs?
>>>>>>> For example, I dont have a problem handling TLVs in a software 
>>>>>>> datapath.
>>>>>>>
>>>>>>> cheers, jamal
>>>>>>>

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 12 Mar 2014 18:16:45 +0000

I think Ron raises very valid points. A variable length metadata allows the flexibility of carrying different lengths and different types of metadata for 
different usage scenarios some of which we might not perceive today. 
I can see two potential issues associated with a fixed length metadata in the service chain header. One is the waste of buffer memory and network BW 
for delivering every packet carrying empty metadata bytes in a deployment scenario which does not need those metadata. 
On the other hand, if a deployment scenario requires more types or lengths than what we define today in the fixed size of metadata, there is no space for that, 
and we have to consider another extension or a new header as well as backward compatibility issue...

As to the mechanism of transporting the variable-length metadata, both in-band and out-of-band mechanisms could work as discussed in other emails, 
and in-band avoids the complication and extra latency associated with dealing of out-of-sync issue.

Should we consider separating the information into fixed length mandatory fields and variable length optional fields? The mandatory fields carry "SFC path setup" related information. The variable length optional fields carry application/service/content etc. related information in TLV format.

Thanks,
Cathy 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, March 11, 2014 1:00 PM
To: Jim Guichard (jguichar)
Cc: Nicolas BOUTHORS; [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Jim,

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2014 3:52 PM
To: Ron Parker
Cc: Nicolas BOUTHORS; Jamal Hadi Salim; [email-masked]; [email-masked]; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Sent from my iPhone

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Mar 2014 14:18:44 -0400

My inclination would be to tune that definition to distinguish between
dataplane carried information intended for use by service funcitons
(whatever the origin), and dataplane carried information intended for
dataplane forwarding components.

Yours,
Joel

> Hi Joel,
>
> I agree that we need using the same definition for a term, but
> disagree that the metadata definition here is a set of information
> put in the SFC header. This may be too narrow or lead to a particular
> solution. I am fine with this definition in the problem statement w/
> minor tweak (suggested on mailing list).
>
> There may be a solution that a service function passes some
> information to attached service node without using SFC header.
>
> Thanks, Lucy
>
>
> -----Original Message----- From: Joel Halpern Direct
> [mailto:[email-masked]] Sent: Wednesday, March 12, 2014
> 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas BOUTHORS; Ron
> Parker Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal
> Hadi Salim Subject: Re: [sfc]
> provide is a definition of the set of information we are proposing
> that we put in the SFC header.  I, and others, have been using the
> term metadata more narrowly.  We can use whatever definition we want.
> But we do need to agree on the definition. For the purposes of the
> WG, it seems much more useful to use the term metadata for the
> narrower description.
>
> Yours, Joel
>
>> function and SFC header. The metadata term means carrying some
>> states along with the packet. IMO: SFC header is a kind of metadata
>> carried on packet for next service node to use. In the context of
>> SFC, we have term for SFC header and the metadata that was carried
>> between service functions, or between service functions and
>> I think it is important to keep a strong distinction between
>> metadata (which is for use by applications) and the service
>> chaining information in the base service chain header, which is for
>> use by the service chain support mechanisms.
>>
>> Yours, Joel
>>
>>> not leave it for freely usage. In fact, when a service node
>>> inserts SFC header on a (encapsulated) packet and send to next
>>> service node, SFC header itself can be seen as a metadata.
>>>
>>> Lucy
>>>
>>> -----Original Message----- From: sfc
>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern Sent:
>>> Wednesday, March 12, 2014 9:21 AM To: Nicolas BOUTHORS; Ron
>>> Parker Cc: Jim Guichard (jguichar); [email-masked]; sfc;
>>>> policy change in PCRF could lead to some metadata signaling,
>>>> the reaction time need not be immediate, few ms may not
>>>> matter.
>>>>
>>>> Finally we can still send some limited metadata within a
>>>> header. This could be used for load balancers in particular if
>>>> we agree on a convention to locate "coarse grain policy" /
>>>> "fine grain policy" on reserved context headers.
>>>>
>>>> On your last point, there is a question on how to make
>>>> metadata available to a Service Function. Current socket
>>>> connections for example do not allow to retrieve IP header
>>>> options. So I assume that SFC aware Service Functions will need
>>>> some (asynchronous ?) API to retrieve SFC header information as
>>>> well as in-band metadata. I don't see out of band metadata
>>>> transport adding complexity,  the same API can probably apply.
>>>>
>>>> might thus even need non-congruent out-of-band reliable
>>>> metadata transport.
>>>>
>>>>
>>>>
>>>> (jguichar); [email-masked]; sfc; Jamal Hadi Salim
>>>> but I am concerned that it introduces significant complexity
>>>> due to the potential race condition of receiving the real
>>>> packet before the metadata.  While the real packet could
>>>> indicate that out of band metadata is expected, how can we
>>>> guarantee the order of reception? What if switching or routing
>>>> nodes apply hash based load balancing? What if the load
>>>> balancing understands SFC encaps and looks beyond it to the
>>>> original header to get better entropy? Can we guarantee that
>>>> Also, do you feel that the increase in implementation
>>>> complexity at the service functions is reasonable?
>>>>
>>>> Thanks.
>>>>
>>>> Ron
>>>>
>>>>> The former calls for a limited space in the header, true,
>>>>> The latter however does not incur any space limitation and is
>>>>> still fairly efficient and it remains compatible with a fixed
>>>>> size header used to route those signaling messages along the
>>>>> chain's service functions.
>>>>>
>>>>> [email-masked]; sfc; Jamal Hadi Salim Subject: Re:
>>>>> consider what information is necessary and if said
>>>>> information can fit within a fixed number of contexts in the
>>>>> majority of cases. Remember, the goal of being able to pass
>>>>> metadata through the network is to enhance service delivery,
>>>>>> metadata and vendor or other organizational OUIs can be
>>>>>> used to quickly innovate in the networks.   Simultaneously,
>>>>>> I would also like to consider mechanisms that are optimized
>>>>>> for long lived flows so as to limit the negative effects of
>>>>>> packet growth.
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>>> enrichment (aimed at some Web Content providers partners
>>>>>>> of the Mobile Operator). Information was an coded
>>>>>>> (persistent) subscriber id derived from the MSISDN, and
>>>>>>> couple of f customer profile related fields.
>>>>>>>
>>>>>>> - A classification of the Content Provider ( Id,
>>>>>>> Category) based on traffic analysis - The MSISDN of the
>>>>>>> subscriber - Two subscriber policy fields (not tied to
>>>>>>> PCRF but belonging to the Subscriber DB) (Subscriber
>>>>>>> category, sub-category) - A session id (for logging and
>>>>>>> tracking purposes)
>>>>>>>
>>>>>>> become a trusted application (interogate the subscriber
>>>>>>> DB, etc..)
>>>>>>>
>>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>>
>>>>>>> [email-masked]; [email-masked] Cc: sfc
>>>>>>> Subject: Re: [sfc]
>>>>>>> metadata".. I am not so convinced and would like to
>>>>>>> better understand the requirements before passing
>>>>>>> judgement. If we look at the use cases as presented thus
>>>>>>> far into the WG I have yet to see a single example of the
>>>>>>> need (noting that desire is not the same as need) - I am
>>>>>>> not saying there is no requirement but rather that we

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 18:33:13 +0000

Joel, I interpret that you suggests that distinguish the exchange information data plane carried between service functions and the exchange information data plane carried from a service function to a service node. Is this right understanding? 
Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2014 1:19 PM
To: Lucy yong; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

My inclination would be to tune that definition to distinguish between dataplane carried information intended for use by service funcitons (whatever the origin), and dataplane carried information intended for dataplane forwarding components.

Yours,
Joel

> disagree that the metadata definition here is a set of information put 
> in the SFC header. This may be too narrow or lead to a particular 
> 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas BOUTHORS; Ron Parker 
> Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi 
> Salim Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>
> But we do need to agree on the definition. For the purposes of the WG, 
> it seems much more useful to use the term metadata for the narrower 
> description.
>
> Yours, Joel
>
>>> On Behalf Of Joel M. Halpern Sent:
>>> Wednesday, March 12, 2014 9:21 AM To: Nicolas BOUTHORS; Ron Parker 
>>> Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi 
>>> Salim Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>
>>> exactly four pieces, and they will be of types t1, t2, t3, and t4" 
>>> is simply too specific for even 80% of the needs.
>>>
>>> Yours, Joel
>>>
>>>> header has some drawbacks as well, one being fragmentation, and 
>>>> [email-masked]; sfc; Jamal Hadi Salim
>>>>>> other organizational OUIs can be
>>>>>> I would also like to consider mechanisms that are optimized for 
>>>>>> long lived flows so as to limit the negative effects of packet 
>>>>>> growth.
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>>> information is passed to a Web Proxy for HTTP header enrichment 
>>>>>>> (aimed at some Web Content providers partners of the Mobile 
>>>>>>> Operator). Information was an coded
>>>>>>> (persistent) subscriber id derived from the MSISDN, and couple 
>>>>>>> of f customer profile related fields.
>>>>>>>
>>>>>>> subscriber - Two subscriber policy fields (not tied to PCRF but 
>>>>>>> sub-category) - A session id (for logging and tracking purposes)
>>>>>>>
>>>>>>>> least for http/app you  seem to indicate the desire for it). 
>>>>>>>> For a datapath per-packet metadata, i feel the need is just as 
>>>>>>>> important. Are we limited by the fact that existing hardware 
>>>>>>>> may not be able to handle TLVs?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Mar 2014 15:01:57 -0400

I was trying to word it carefully not to focus on who puts the 
information in, but only on who consumes the information.  Information 
for service functions may come from the ingress classifier or from other 
service functions.  Information for the forwarding will generally come 
from the ingress classifier, but in special cases may be provided by 
service functions.  (I keep wanting to get rid of those special cases, 
but so far there seem to be just enough of them to warrant covering in 
the solution.  And more importantly, significant support for it in the 
working group.)

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 19:13:57 +0000

Joel, See below.
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, March 12, 2014 2:02 PM
To: Lucy yong; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

I was trying to word it carefully not to focus on who puts the information in, but only on who consumes the information.  Information for service functions may come from the ingress classifier or from other service functions. 
[Lucy] this is the one case using metadata in your view.
 Information for the forwarding will generally come from the ingress classifier, but in special cases may be provided by service functions.  (I keep wanting to get rid of those special cases, but so far there seem to be just enough of them to warrant covering in the solution.  And more importantly, significant support for it in the working group.)
[Lucy] This is the second case using metadata in your view (but you don't like it).

And you suggest distinguishing these two cases when discussing about metadata usage. Is that right understanding?

Lucy 

Yours,
Joel

On 3/12/14, 2:33 PM, Lucy yong wrote:
> Salim
>>> AM
>>> metadata (which is for use by applications) and the service chaining 
>>> information in the base service chain header, which is for use by 
>>> the service chain support mechanisms.
>>>
>>> Yours, Joel
>>>
>>>> are many different kinds of metatype.  Trying to say "there will be 
>>>>> out of band metadata is expected, how can we guarantee the order of reception?
>>>>>> can fit within a fixed number of contexts in the majority of cases.
>>>>>>> to propose an OUI / TLV based approach where the reserved OUI 
>>>>>>> can be used for agreed upon types of common metadata and vendor 
>>>>>>> or other organizational OUIs can be
>>>>>>>> look at the use cases as presented thus far into the WG I have 
>>>>>>>> yet to see a single example of the need (noting that desire is 
>>>>>>>> not the same as need) - I am not saying there is no requirement 
>>>>>>>> but rather that we should not jump to the conclusion and build

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Mar 2014 15:34:33 -0400

Yes, I am trying to consistently distinguish those two cases when 
talking about the information carried with packets in service chains.

Yours,
Joel

On 3/12/14, 3:13 PM, Lucy yong wrote:
> Joel, See below. -----Original Message----- From: sfc
> Wednesday, March 12, 2014 2:02 PM To: Lucy yong; Nicolas BOUTHORS;
> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]; sfc;
> information in, but only on who consumes the information.
> Information for service functions may come from the ingress
> classifier or from other service functions. [Lucy] this is the one
> case using metadata in your view. Information for the forwarding will
> generally come from the ingress classifier, but in special cases may
> be provided by service functions.  (I keep wanting to get rid of
> those special cases, but so far there seem to be just enough of them
> to warrant covering in the solution.  And more importantly,
> significant support for it in the working group.) [Lucy] This is the
> second case using metadata in your view (but you don't like it).
>
> And you suggest distinguishing these two cases when discussing about
> metadata usage. Is that right understanding?
>
> Lucy
>
> Yours, Joel
>
>> Joel, I interpret that you suggests that distinguish the exchange
>> information data plane carried between service functions and the
>> exchange information data plane carried from a service function to
>> a service node. Is this right understanding? Lucy
>>
>> [mailto:[email-masked]] Sent: Wednesday, March 12, 2014 1:19
>> PM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard
>> My inclination would be to tune that definition to distinguish
>> between dataplane carried information intended for use by service
>> funcitons (whatever the origin), and dataplane carried information
>> intended for dataplane forwarding components.
>>
>> Yours, Joel
>>
>>
>>> Hi Joel,
>>>
>>> disagree that the metadata definition here is a set of
>>> information put in the SFC header. This may be too narrow or lead
>>> to a particular solution. I am fine with this definition in the
>>> problem statement w/ minor tweak (suggested on mailing list).
>>>
>>> exchange information between the classifiers and service
>>> functions, between service functions, and service functions and
>>> the classifiers|service nodes.
>>>
>>> [mailto:[email-masked]] Sent: Wednesday, March 12,
>>> 2014 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas BOUTHORS;
>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked];
>>> sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>> Lucy, you say "the metadata term means ..."  The definition you
>>> then provide is a definition of the set of information we are
>>> proposing that we put in the SFC header.  I, and others, have
>>> been using the term metadata more narrowly.  We can use whatever
>>> definition we want. But we do need to agree on the definition.
>>> For the purposes of the WG, it seems much more useful to use the
>>> term metadata for the narrower description.
>>>
>>> Yours, Joel
>>>
>>>> states along with the packet. IMO: SFC header is a kind of
>>>> metadata carried on packet for next service node to use. In the
>>>> context of SFC, we have term for SFC header and the metadata
>>>> that was carried between service functions, or between service
>>>> functions and classifiers/service nodes, which is what the
>>>> draft focus.
>>>>
>>>> Thanks, Lucy
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [mailto:[email-masked]] Sent: Wednesday, March 12, 2014
>>>> 11:18 AM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim
>>>> Guichard (jguichar); [email-masked]; sfc; Jamal Hadi
>>>> Salim Subject: Re: [sfc]
>>>> chaining information in the base service chain header, which is
>>>> for use by the service chain support mechanisms.
>>>>
>>>> Yours, Joel
>>>>
>>>>> We should not require a fix length for in-band metadata but
>>>>> also not leave it for freely usage. In fact, when a service
>>>>> node inserts SFC header on a (encapsulated) packet and send
>>>>> to next service node, SFC header itself can be seen as a
>>>>> metadata.
>>>>>
>>>>> Lucy
>>>>>
>>>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>>>> Sent: Wednesday, March 12, 2014 9:21 AM To: Nicolas BOUTHORS;
>>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked];
>>>>> sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>>>> synchronous. Out of band metadata needs different handling.
>>>>> Even if each piece of in-band metadata is of fixed length,
>>>>> there are many different kinds of metatype.  Trying to say
>>>>> "there will be exactly four pieces, and they will be of types
>>>>> t1, t2, t3, and t4" is simply too specific for even 80% of
>>>>> the needs.
>>>>>
>>>>> Yours, Joel
>>>>>
>>>>>> Sending out of band congruent metadata may not be the
>>>>>> answer to all needs but it is one tool that we should
>>>>>> keep.
>>>>>>
>>>>>> Not all metadata is tied to a specific packet, for example
>>>>>> a policy change in PCRF could lead to some metadata
>>>>>> signaling, the reaction time need not be immediate, few ms
>>>>>> may not matter.
>>>>>>
>>>>>> As you point, if a packet is tied to a metadata a
>>>>>> correlation info can be set in both packet to deal with it
>>>>>> (i.e metadata expected flag in the SFC header, plus an id)
>>>>>>
>>>>>> header. This could be used for load balancers in particular
>>>>>> if we agree on a convention to locate "coarse grain policy"
>>>>>> / "fine grain policy" on reserved context headers.
>>>>>>
>>>>>> options. So I assume that SFC aware Service Functions will
>>>>>> need some (asynchronous ?) API to retrieve SFC header
>>>>>> information as well as in-band metadata. I don't see out of
>>>>>> band metadata transport adding complexity,  the same API
>>>>>> can probably apply.
>>>>>>
>>>>>> The alternative option, allowing variable sized metadata in
>>>>>> the SFC header has some drawbacks as well, one being
>>>>>> fragmentation, and some switches expecting as well to look
>>>>>> at end user traffic headers for link load balancing.  I
>>>>>> would agree that if we can accept these issues, then
>>>>>> sending off-line congruent metadata looses its interest.
>>>>>>
>>>>>> We need to take into account  that both in-band and
>>>>>> congruent out-of-band metadata transport is not reliable. A
>>>>>> packet loss triggering retransmission would not lead to the
>>>>>> identical reconstruction of the associated metadata. In
>>>>>> some cases, we might thus even need non-congruent
>>>>>> out-of-band reliable metadata transport.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Parker [[email-masked]] Sent: Wednesday,
>>>>>> March 12, 2014 12:43 PM To: Nicolas BOUTHORS Cc: Jim
>>>>>> Guichard (jguichar); [email-masked]; sfc; Jamal Hadi
>>>>>> Salim Subject: Re: [sfc]
>>>>>> I understand the concept for out of band signaling of
>>>>>> metadata, but I am concerned that it introduces significant
>>>>>> complexity due to the potential race condition of receiving
>>>>>> the real packet before the metadata.  While the real packet
>>>>>> could indicate that out of band metadata is expected, how
>>>>>> can we guarantee the order of reception? What if switching
>>>>>> or routing nodes apply hash based load balancing? What if
>>>>>> the load balancing understands SFC encaps and looks beyond
>>>>>> it to the original header to get better entropy? Can we
>>>>>> guarantee that the metadata and real packet will follow the
>>>>>> exact same path? If we can not, then implementations will
>>>>>>> - Metadata which should be part of the header defined as
>>>>>>> in band marking. - Metadata with can be passed out of
>>>>>>> band, for example congruent out of band signaling defined
>>>>>>> in the draft
>>>>>>>
>>>>>>> The latter however does not incur any space limitation
>>>>>>> and is still fairly efficient and it remains compatible
>>>>>>> with a fixed size header used to route those signaling
>>>>>>> messages along the chain's service functions.
>>>>>>>
>>>>>>> Nicolas ________________________________________ From:
>>>>>>> Jim Guichard (jguichar) [[email-masked]] Sent:
>>>>>>> Tuesday, March 11, 2014 6:48 PM To: Ron Parker Cc:
>>>>>>> Nicolas BOUTHORS; [email-masked]; sfc; Jamal Hadi
>>>>>>> Salim Subject: Re: [sfc]
>>>>>>> We can certainly have this discussion but we should
>>>>>>> first consider what information is necessary and if said
>>>>>>> information can fit within a fixed number of contexts in
>>>>>>> the majority of cases. Remember, the goal of being able
>>>>>>> to pass metadata through the network is to enhance
>>>>>>>> I see similar requirements from the 3gpp EPC side.  I
>>>>>>>> would like to propose an OUI / TLV based approach where
>>>>>>>> the reserved OUI can be used for agreed upon types of
>>>>>>>> common metadata and vendor or other organizational OUIs
>>>>>>>> can be used to quickly innovate in the networks.
>>>>>>>> Simultaneously, I would also like to consider
>>>>>>>> mechanisms that are optimized for long lived flows so
>>>>>>>>> I have seen cases in Gi LAN, where subscriber
>>>>>>>>> related information is passed to a Web Proxy for HTTP
>>>>>>>>> header enrichment (aimed at some Web Content
>>>>>>>>> providers partners of the Mobile Operator).
>>>>>>>>> Information was an coded (persistent) subscriber id
>>>>>>>>> derived from the MSISDN, and couple of f customer
>>>>>>>>> profile related fields.
>>>>>>>>>
>>>>>>>>> Category) based on traffic analysis - The MSISDN of
>>>>>>>>> the subscriber - Two subscriber policy fields (not
>>>>>>>>> tied to PCRF but belonging to the Subscriber DB)
>>>>>>>>> (Subscriber category, sub-category) - A session id
>>>>>>>>> The objective being to avoid having  the HTTP Proxy
>>>>>>>>> to become a trusted application (interogate the
>>>>>>>>> subscriber DB, etc..)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Guichard (jguichar) [[email-masked]] Sent:
>>>>>>>>> Thursday, March 06, 2014 2:02 PM To: Jamal Hadi
>>>>>>>>> Salim; [email-masked]; [email-masked] Cc:
>>>>>>>>> sfc Subject: Re: [sfc]
>>>>>>>>> You said "It seems there's clear need for variable
>>>>>>>>> sized metadata".. I am not so convinced and would
>>>>>>>>> like to better understand the requirements before
>>>>>>>>> passing judgement. If we look at the use cases as
>>>>>>>>> presented thus far into the WG I have yet to see a
>>>>>>>>> single example of the need (noting that desire is not
>>>>>>>>> the same as need) - I am not saying there is no
>>>>>>>>>> It seems there's clear need for variable sized
>>>>>>>>>> metadata (at least for http/app you  seem to
>>>>>>>>>> indicate the desire for it). For a datapath
>>>>>>>>>> per-packet metadata, i feel the need is just as
>>>>>>>>>> important. Are we limited by the fact that existing
>>>>>>>>>> hardware may not be able to handle TLVs? For
>>>>>>>>>> example, I dont have a problem handling TLVs in a
>>>>>>>>>> software datapath.
>>>>>>>>>>
>>>>>>>>>> cheers, jamal
>>>>>>>>>>

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 20:16:31 +0000

Great. Then we may consider two special metadata definitions in the problem statement so we can all use the same definitions. Here is my suggested text and like to hear you and other's input and suggestions.

Dataplane Metadata: Data plane metadata provides the ability to
exchange information between the elements in a service function chaining. In this context, there are two types of data plane metadata.
       
Service Function Metadata: the information exchanged between classifier and service functions, between service functions to facilitate service functions on the packet treatment.

Steering Metadata: the information from service functions to a classifier or service node for traffic forwarding purpose. 

-end

Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2014 2:35 PM
To: Lucy yong; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Yes, I am trying to consistently distinguish those two cases when talking about the information carried with packets in service chains.

Yours,
Joel

On 3/12/14, 3:13 PM, Lucy yong wrote:
> Wednesday, March 12, 2014 2:02 PM To: Lucy yong; Nicolas BOUTHORS; Ron 
> Information for service functions may come from the ingress classifier 
> or from other service functions. [Lucy] this is the one case using 
> metadata in your view. Information for the forwarding will generally 
> come from the ingress classifier, but in special cases may be provided 
> by service functions.  (I keep wanting to get rid of those special 
> cases, but so far there seem to be just enough of them to warrant 
> covering in the solution.  And more importantly, significant support 
> for it in the working group.) [Lucy] This is the second case using 
> metadata in your view (but you don't like it).
>
>> exchange information data plane carried from a service function to a 
>> service node. Is this right understanding? Lucy
>>
>> [mailto:[email-masked]] Sent: Wednesday, March 12, 2014 1:19 PM 
>>> put in the SFC header. This may be too narrow or lead to a 
>>> particular solution. I am fine with this definition in the problem 
>>> statement w/ minor tweak (suggested on mailing list).
>>>
>>> 2014 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas BOUTHORS; Ron 
>>> term metadata more narrowly.  We can use whatever definition we 
>>> want. But we do need to agree on the definition.
>>>> Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim 
>>>>> On Behalf Of Joel M. Halpern
>>>>> Sent: Wednesday, March 12, 2014 9:21 AM To: Nicolas BOUTHORS; Ron 
>>>>>> on a convention to locate "coarse grain policy"
>>>>>>> Nicolas BOUTHORS; [email-masked]; sfc; Jamal Hadi Salim 
>>>>>>>> innovate in the networks.
>>>>>>>> Simultaneously, I would also like to consider mechanisms that 
>>>>>>>> are optimized for long lived flows so as to limit the negative 
>>>>>>>> effects of packet growth.
>>>>>>>>
>>>>>>>> Ron
>>>>>>>>
>>>>>>>>
>>>>>>>>> the Mobile Operator).
>>>>>>>>> Information was an coded (persistent) subscriber id derived 
>>>>>>>>> from the MSISDN, and couple of f customer profile related 
>>>>>>>>> fields.
>>>>>>>>>
>>>>>>>>> subscriber - Two subscriber policy fields (not tied to PCRF 
>>>>>>>>> but belonging to the Subscriber DB) (Subscriber category, 
>>>>>>>>> (jguichar) [[email-masked]] Sent:
>>>>>>>>> Thursday, March 06, 2014 2:02 PM To: Jamal Hadi Salim; 
>>>>>>>>> [email-masked]; [email-masked] Cc:
>>>>>>>>> sfc Subject: Re: [sfc]
>>>>>>>>> not the same as need) - I am not saying there is no 
>>>>>>>>>> For a datapath per-packet metadata, i feel the need is just 
>>>>>>>>>> as important. Are we limited by the fact that existing 
>>>>>>>>>> hardware may not be able to handle TLVs? For example, I dont 
>>>>>>>>>> have a problem handling TLVs in a software datapath.
>>>>>>>>>>
>>>>>>>>>> cheers, jamal
>>>>>>>>>>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Mar 2014 20:54:33 +0000

Maybe it is just words, but I'm in favor of using different words for forwarding chain identifier and optional meta information.

The forwarding information absolutely must be understood by every element in the chain in order for the packet to go where it is supposed to. Previously we have discussed a 32-bit identifier will be sufficient to enumerate all required network paths, and a fixed size header is useful for those who want hardware solutions. (It is also useful for software solutions, because a table indexed by a variable-length string is slower than a table indexed by an integer.)

In contrast, understanding the meta-data is optionally understood, and ideally is opaque to those elements that don't need it.

I see them as orthogonal. Forwarding requires the path identifier and the meta-data is opaque. Functions require the meta-data and the path identifier is opaque.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, March 12, 2014 4:17 PM
To: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

       

-end

Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2014 2:35 PM
To: Lucy yong; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 12 Mar 2014 20:56:01 +0000

I for one don't agree and think we are over complicating what should be straightforward. The SFC encapsulation should enable two things:

1. Steering of selected flows through a service chain; this is the service function path.
2. Passing of context associated with a given flow within said service function path. This context information may be consumed by a SF (an application ID is an example) or may be consumed by the forwarding elements (a vrf-ID is an example).

Sent from my iPhone

> On Mar 12, 2014, at 4:16 PM, "Lucy yong" <[email-masked]> wrote:
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 21:03:37 +0000

Dave,

I do not disagree what you say. Metadata is optional for sure. But you also talk about SFC header. My suggested text is about the medadata definition only, orthogonal to the path identifier in SFC header.

Regards,
Lucy 

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2014 3:55 PM
To: Lucy yong; Joel M. Halpern; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, March 12, 2014 4:17 PM
To: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Dataplane Metadata: Data plane metadata provides the ability to exchange information between the elements in a service function chaining. In this context, there are two types of data plane metadata.

-end

Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, March 12, 2014 2:35 PM
To: Lucy yong; Nicolas BOUTHORS; Ron Parker
Cc: Jim Guichard (jguichar); [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 21:13:35 +0000

Hi Jim, 

1. Steering of selected flows through a service chain; this is the service function path.
2. Passing of context associated with a given flow within said service function path. This context information may be consumed by a SF (an application ID is an example) or may be consumed by the forwarding elements (a vrf-ID is an example).
[Lucy] Do you call the context as metadata or not? Do we have another term here beside SFC header and metadata. I see that you don't want to separate what is consumed by SF and what is consumed by the forwarding elements.

Lucy

Sent from my iPhone

>>>> proposing that we put in the SFC header.  I, and others, have been 
>>>> using the term metadata more narrowly.  We can use whatever 
>>>>> context of SFC, we have term for SFC header and the metadata that 
>>>>> was carried between service functions, or between service 
>>>>> functions and classifiers/service nodes, which is what the draft focus.
>>>>> 
>>>>> Thanks, Lucy
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>>> 12, 2014
>>>>>>> of reception? What if switching or routing nodes apply hash 
>>>>>>> based load balancing? What if the load balancing understands SFC 
>>>>>>> encaps and looks beyond it to the original header to get better entropy?

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 12 Mar 2014 21:38:23 +0000

Hi Lucy,

No. I am simply saying we should not overcomplicate the problem statement
with text that adds little to no value in my opinion. Whether we call it
metadata, or context, has no bearing on the fact that the problem
statement already clearly states we need to be able to pass information
between SF¹s and between the network & SF¹s.

On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked]> wrote:

>
>Hi Jim, 
>
>I for one don't agree and think we are over complicating what should be
>straightforward. The SFC encapsulation should enable two things:
>
>2. Passing of context associated with a given flow within said service
>function path. This context information may be consumed by a SF (an
>application ID is an example) or may be consumed by the forwarding
>elements (a vrf-ID is an example).
>[Lucy] Do you call the context as metadata or not? Do we have another
>term here beside SFC header and metadata. I see that you don't want to
>separate what is consumed by SF and what is consumed by the forwarding
>elements.
>
>Lucy
>
>Sent from my iPhone
>
>> Great. Then we may consider two special metadata definitions in the
>>problem statement so we can all use the same definitions. Here is my
>>suggested text and like to hear you and other's input and suggestions.
>> 
>> exchange information between the elements in a service function
>>chaining. In this context, there are two types of data plane metadata.
>> 
>> Service Function Metadata: the information exchanged between classifier
>>and service functions, between service functions to facilitate service
>>functions on the packet treatment.
>> 
>> Steering Metadata: the information from service functions to a
>>classifier or service node for traffic forwarding purpose.
>> 
>> -end
>> 
>> Lucy
>> 
>>

---

From: Lucy yong <[email-masked]>
Date: Wed, 12 Mar 2014 22:17:48 +0000

Hi Jim,

SFC WG had so many discussions on metadata, why is that? IMO: part of it is because we have too general definition on metadata in this context which opens up so many ideas people could think of. If we don't want overcomplicated solutions, we need to narrow down the problem statement too. For example, "between the network & SFs", what the network do you mean here? Should we be more specific on that? Joel suggests distinguishing the metadata based on usage of it, if that helps clarify the discussion, what is wrong to state them in the problem statement, so people can use the same defined terms for the discussions. We often spend a lot of times in the discussions because of not a precise term definition or one term interpreted with many ways. 

Why do you think that this metadata definition overcomplicate problem statements? It only adds three lines.

Thanks,
Lucy

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2014 4:38 PM
To: Lucy yong
Cc: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker; [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Lucy,

No. I am simply saying we should not overcomplicate the problem statement with text that adds little to no value in my opinion. Whether we call it metadata, or context, has no bearing on the fact that the problem statement already clearly states we need to be able to pass information between SF¹s and between the network & SF¹s.

On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked]> wrote:

>> Service Function Metadata: the information exchanged between 
>>classifier and service functions, between service functions to 
>>facilitate service functions on the packet treatment.
>> 
>>> case using metadata in your view. Information for the forwarding 
>>> will generally come from the ingress classifier, but in special 
>>> cases may be provided by service functions.  (I keep wanting to get 
>>> rid of those special cases, but so far there seem to be just enough 
>>> of them to warrant covering in the solution.  And more importantly, 
>>>> PM
>>>>>>> be exactly four pieces, and they will be of types t1, t2, t3, 
>>>>>>> and t4" is simply too specific for even 80% of the needs.
>>>>>>> 
>>>>>>> Yours, Joel
>>>>>>> 
>>>>>>>> the reaction time need not be immediate, few ms may not matter.
>>>>>>>> 
>>>>>>>> that SFC aware Service Functions will need some (asynchronous 
>>>>>>>> ?) API to retrieve SFC header information as well as in-band 
>>>>>>>>> latter however does not incur any space limitation and is 
>>>>>>>>>> to quickly innovate in the networks.
>>>>>>>>>> are optimized for long lived flows so as to limit the 
>>>>>>>>>> negative effects of packet growth.
>>>>>>>>>> 
>>>>>>>>>> Ron
>>>>>>>>>> 
>>>>>>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 12 Mar 2014 22:29:10 +0000

This is only my opinion Lucy; I would suggest discussing with the problem statement editors to get their input.

Sent from my iPhone

> On Mar 12, 2014, at 6:18 PM, "Lucy yong" <[email-masked]> wrote:
> 
> Hi Jim,
>

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 13 Mar 2014 01:10:08 +0000

I think we will overcomplicate by trying to define types of metadata and
define who the consumers can or can not be. For example say a video
optimizer annotates the transaction or a flow with it’s load info/queue
depth. This could be consumed by an intelligent steering device or by a
service function like load balancer. So is this a Dataplane metadata or
steering metadata. I am ok with covering the use cases rather than strict
definition. 

The original thread started with the debate around the variable length
metadata. One example that comes to my mind is subscriber ID. This could
IMSI or SIP uri or classic [email-masked]. Each are of different
length. Typically Radius and Diameter uses AVP to carry the subscriber
info.

https://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-pa
rameters-37

Also isn’t it limiting to say that SFC header can never carry variable
length metadata, for the future use case that we don’t know of now. I am
sure the collective wisdom of this group can provide more examples.

My 2 cents.

Sumandra

On 3/12/14, 3:17 PM, "Lucy yong" <[email-masked]> wrote:

>Hi Jim,
>
>SFC WG had so many discussions on metadata, why is that? IMO: part of it
>is because we have too general definition on metadata in this context
>which opens up so many ideas people could think of. If we don't want
>overcomplicated solutions, we need to narrow down the problem statement
>too. For example, "between the network & SFs", what the network do you
>mean here? Should we be more specific on that? Joel suggests
>distinguishing the metadata based on usage of it, if that helps clarify
>the discussion, what is wrong to state them in the problem statement, so
>people can use the same defined terms for the discussions. We often spend
>a lot of times in the discussions because of not a precise term
>definition or one term interpreted with many ways.
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 13 Mar 2014 03:24:27 +0000

Dave,

Inline.

On 3/12/14 1:54 PM, "Dave Dolson" <[email-masked]> wrote:

>Maybe it is just words, but I'm in favor of using different words for
>forwarding chain identifier and optional meta information.
>
>
>The forwarding information absolutely must be understood by every element
>in the chain in order for the packet to go where it is supposed to.
SK> Just making sure. I would say "every forwarding element" just to avoid
the MUST on the service nodes. Service nodes MAY understand it.

>Previously we have discussed a 32-bit identifier will be sufficient to
>enumerate all required network paths, and a fixed size header is useful
>for those who want hardware solutions. (It is also useful for software
>solutions, because a table indexed by a variable-length string is slower
>than a table indexed by an integer.)
>
>In contrast, understanding the meta-data is optionally understood, and
>ideally is opaque to those elements that don't need it.
>
>I see them as orthogonal. Forwarding requires the path identifier and the
>meta-data is opaque. Functions require the meta-data and the path
>identifier is opaque.
SK> Although the above is true in some cases, it may not be in *all*
cases. We do not want to mandate this instead allow for metadata to be
interpreted by the forwarder as well as the service function. Just as
such, the path id although mostly relevant to a forwarder, may be used by
a service node - to not restrict implementation.

Surendra.
>exchange information between the elements in a service function chaining.
>In this context, there are two types of data plane metadata.
>       
>Steering Metadata: the information from service functions to a classifier
>or service node for traffic forwarding purpose.
>
>-end
>
>Lucy
>
>
>Yes, I am trying to consistently distinguish those two cases when talking
>about the information carried with packets in service chains.
>
>Yours,
>Joel
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 13 Mar 2014 03:55:00 +0000

Lucy,

On 3/12/14 3:17 PM, "Lucy yong" <[email-masked]> wrote:

>Hi Jim,
>
>SFC WG had so many discussions on metadata, why is that?
SK> Most of the discussion related to this has been on the size of it
(lately) as well as whether we need it (while back - we've moved past
this).

>IMO: part of it is because we have too general definition on metadata in
>this context which opens up so many ideas people could think of. If we
>don't want overcomplicated solutions, we need to narrow down the problem
>statement too. For example, "between the network & SFs", what the network
>do you mean here? Should we be more specific on that? Joel suggests
SK> Just copying from the PS:
--
Data plane metadata provides the ability to
exchange information between the network and service functions,
between service functions, and service functions and the network.

--
It is a lucid definition. We are unnecessarily making the word "network"
controversial, IMO.

Surendra.

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 13 Mar 2014 14:43:25 +0000

I see no real gain in subdividing the term "metadata".

---

From: Lucy yong <[email-masked]>
Date: Thu, 13 Mar 2014 14:49:21 +0000

Snip..
SK> Just copying from the PS:
--
Data plane metadata provides the ability to exchange information between the network and service functions, between service functions, and service functions and the network.

[Lucy] This is my point. "The network" is too general here, which brings metadata great power to do many things. This is why people invent ideas here, which causes a lot of debates on metadata usage potentials. We should not spend a lot of times on that debates and judge which usage is valuable or not. Thus, for the SFC work, it will be helpful if we can narrow down a bit. Joel makes explicitly two cases, which is helpful to develop use cases for each case. I would like to see that the problem statement can be more specific on metadata definition, which may be helpful in less focusing on it and moving forward.

Lucy 

Surendra.

>Cc: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker; 
>No. I am simply saying we should not overcomplicate the problem 
>statement with text that adds little to no value in my opinion. Whether 
>we call it metadata, or context, has no bearing on the fact that the 
>problem statement already clearly states we need to be able to pass 
>information between SF¹s and between the network & SF¹s.
>
>
>>I for one don't agree and think we are over complicating what should 
>>be straightforward. The SFC encapsulation should enable two things:
>>
>>>> significant support for it in the working group.) [Lucy] This is 
>>>> the second case using metadata in your view (but you don't like it).
>>>> 
>>>> And you suggest distinguishing these two cases when discussing 
>>>> about metadata usage. Is that right understanding?
>>>> 
>>>> Lucy
>>>> 
>>>> Yours, Joel
>>>> 
>>>>>>>> node inserts SFC header on a (encapsulated) packet and send to 
>>>>>>>> next service node, SFC header itself can be seen as a metadata.
>>>>>>>> 
>>>>>>>> Lucy
>>>>>>>> 
>>>>>>>> t1, t2, t3, and t4" is simply too specific for even 80% of the needs.
>>>>>>>> 
>>>>>>>> Yours, Joel
>>>>>>>> 
>>>>>>>>> Sending out of band congruent metadata may not be the answer 
>>>>>>>>> to all needs but it is one tool that we should keep.
>>>>>>>>> 
>>>>>>>>> This could be used for load balancers in particular if we 
>>>>>>>>> agree on a convention to locate "coarse grain policy"
>>>>>>>>> need some (asynchronous
>>>>>>>>> fragmentation, and some switches expecting as well to look at 
>>>>>>>>> end user traffic headers for link load balancing.  I would 
>>>>>>>>> agree that if we can accept these issues, then sending 
>>>>>>>>> off-line congruent metadata looses its interest.
>>>>>>>>> 
>>>>>>>>> March 12, 2014
>>>>>>>>>complexity due to the potential race condition of receiving the 
>>>>>>>>>real packet before the metadata.  While the real packet could 
>>>>>>>>>original header to get better entropy?
>>>>>>>>>>> Simultaneously, I would also like to consider mechanisms 
>>>>>>>>>>> that are optimized for long lived flows so as to limit the 
>>>>>>>>>>>>> For a datapath per-packet metadata, i feel the need is 
>>>>>>>>>>>>> just as important. Are we limited by the fact that 
>>>>>>>>>>>>> existing hardware may not be able to handle TLVs? For 
>>>>>>>>>>>>> example, I dont have a problem handling TLVs in a software datapath.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> cheers, jamal
>>>>>>>>>>>>>

---

From: Lucy yong <[email-masked]>
Date: Thu, 13 Mar 2014 14:50:31 +0000

IMO: it is helpful in use case development at least.

Lucy

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 13 Mar 2014 15:41:32 +0000

The word "metadata" is a purposely ambiguous term "data that provides
information about other data".  It is used to avoid THIS discussion.

For example, I propose we define "tequila metadata" because, frankly, I
will need to order a triple-shot if we keep attempting to define something
that, by definition, is ambiguous.  I'd like my bartender to understand me
specifically when I say "I need a shot".

On 3/13/14 7:49 AM, "Lucy yong" <[email-masked]> wrote:

>Data plane metadata provides the ability to exchange information between
>the network and service functions, between service functions, and service
>functions and the network.
>
>--
>[Lucy] This is my point. "The network" is too general here, which brings
>metadata great power to do many things. This is why people invent ideas
>here, which causes a lot of debates on metadata usage potentials. We
>should not spend a lot of times on that debates and judge which usage is
>valuable or not. Thus, for the SFC work, it will be helpful if we can
>narrow down a bit. Joel makes explicitly two cases, which is helpful to
>develop use cases for each case. I would like to see that the problem
>statement can be more specific on metadata definition, which may be
>helpful in less focusing on it and moving forward.
>
>Lucy 
>
>Surendra.
>
>
>>
>>Thanks,
>>Lucy
>>

---

From: Lucy yong <[email-masked]>
Date: Thu, 13 Mar 2014 16:57:28 +0000

Snip..

The word "metadata" is a purposely ambiguous term "data that provides information about other data".  It is used to avoid THIS discussion.
[Lucy] Then this goal already failed in SFC. How many people debated and how many mails related to it? Why? 

Lucy

For example, I propose we define "tequila metadata" because, frankly, I will need to order a triple-shot if we keep attempting to define something that, by definition, is ambiguous.  I'd like my bartender to understand me specifically when I say "I need a shot".

On 3/13/14 7:49 AM, "Lucy yong" <[email-masked]> wrote:

>Data plane metadata provides the ability to exchange information 
>between the network and service functions, between service functions, 
>and service functions and the network.
>
>--
>[Lucy] This is my point. "The network" is too general here, which 
>brings metadata great power to do many things. This is why people 
>invent ideas here, which causes a lot of debates on metadata usage 
>potentials. We should not spend a lot of times on that debates and 
>judge which usage is valuable or not. Thus, for the SFC work, it will 
>be helpful if we can narrow down a bit. Joel makes explicitly two 
>cases, which is helpful to develop use cases for each case. I would 
>like to see that the problem statement can be more specific on metadata 
>definition, which may be helpful in less focusing on it and moving forward.
>
>Lucy
>
>Surendra.
>
>
>>
>>Thanks,
>>Lucy
>>
>>statement with text that adds little to no value in my opinion. 
>>Whether we call it metadata, or context, has no bearing on the fact 
>>that the problem statement already clearly states we need to be able 
>>to pass information between SF¹s and between the network & SF¹s.
>>
>>
>>>2. Passing of context associated with a given flow within said 
>>>service function path. This context information may be consumed by a 
>>>SF (an application ID is an example) or may be consumed by the 
>>>forwarding elements (a vrf-ID is an example).
>>>term here beside SFC header and metadata. I see that you don't want 
>>>to separate what is consumed by SF and what is consumed by the 
>>>forwarding elements.
>>>
>>>Lucy
>>>
>>>Sent from my iPhone
>>>
>>>>> cases may be provided by service functions.  (I keep wanting to 
>>>>> get rid of those special cases, but so far there seem to be just 
>>>>> enough of them to warrant covering in the solution.  And more 
>>>>> importantly, significant support for it in the working group.) 
>>>>>> exchange information data plane carried from a service function 
>>>>>> to a service node. Is this right understanding? Lucy
>>>>>> 
>>>>>> funcitons (whatever the origin), and dataplane carried 
>>>>>> information intended for dataplane forwarding components.
>>>>>> 
>>>>>> Yours, Joel
>>>>>> 
>>>>>> 
>>>>>>> Hi Joel,
>>>>>>> 
>>>>>>> information put in the SFC header. This may be too narrow or 
>>>>>>> lead to a particular solution. I am fine with this definition in 
>>>>>>> the problem statement w/ minor tweak (suggested on mailing list).
>>>>>>> 
>>>>>>>>>>could indicate that out of band metadata is expected, how can 
>>>>>>>>>>we guarantee the order of reception? What if switching or 
>>>>>>>>>>routing nodes apply hash based load balancing? What if the 
>>>>>>>>>>load balancing understands SFC encaps and looks beyond it to 
>>>>>>>>>>the original header to get better entropy?
>>>>>>>>>> Can we guarantee that the metadata and real packet will 
>>>>>>>>>>follow the exact same path? If we can not, then 
>>>>>>>>>>implementations will need to add ingress queuing to cope with the scenario.
>>>>>>>>>> 
>>>>>>>>>>> The latter however does not incur any space limitation and 
>>>>>>>>>>> is still fairly efficient and it remains compatible with a 
>>>>>>>>>>> fixed size header used to route those signaling messages 
>>>>>>>>>>> along the chain's service functions.
>>>>>>>>>>> 
>>>>>>>>>>>> used to quickly innovate in the networks.
>>>>>>>>>>>>> of the Mobile Operator).
>>>>>>>>>>>>> derived from the MSISDN, and couple of f customer profile 
>>>>>>>>>>>>> related fields.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> category,
>>>>>>>>>>>>> DB,
>>>>>>>>>>>>> understand the requirements before passing judgement. If 
>>>>>>>>>>>>> we look at the use cases as presented thus far into the WG 
>>>>>>>>>>>>> I have yet to see a single example of the need (noting 
>>>>>>>>>>>>> that desire is not the same as need) - I am not saying 
>>>>>>>>>>>>> there is no requirement but rather that we should not jump 
>>>>>>>>>>>>> to the conclusion and build standards around a theory.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>>for it).

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 13 Mar 2014 18:36:35 +0000

Let me please try to bring this discussion back to the problem statement.
We have a milestone for next month that I would very much like to make.

Lucy, Joel, could I ask that you work together to consolidate inputs and
propose text for the problem statement? Could you please share that
proposed text with the mailing list and if there are no major objections,
work directly with the editors of the problem statement to integrate new
text where necessary.

Many thanks. 

On 3/13/14, 12:57 PM, "Lucy yong" <[email-masked]> wrote:

>will need to order a triple-shot if we keep attempting to define
>something that, by definition, is ambiguous.  I'd like my bartender to
>understand me specifically when I say "I need a shot".
>
>>>>>>>>>>>header.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 13 Mar 2014 14:17:49 -0400

Precisely; the whole point is that it is opaque/malleable in nature. 

	--Tom

---

From: Lucy yong <[email-masked]>
Date: Thu, 13 Mar 2014 18:34:54 +0000

Opaque to what? Current definition does not imply that at all. It basically allows a metadata to be exchanged by any element in the chain.

Lucy

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, March 13, 2014 1:18 PM
To: Ken Gray (kegray)
Cc: Lucy yong; Surendra Kumar (smkumar); Guichard Jim; Nicolas BOUTHORS; sfc; Jamal Hadi Salim; Ron Parker; [email-masked]; Joel M. Halpern
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

	--Tom

On Mar 13, 2014:11:41 AM, at 11:41 AM, Ken Gray (kegray) <[email-masked]> wrote:

> For example, I propose we define "tequila metadata" because, frankly, 
> I will need to order a triple-shot if we keep attempting to define 
>> like to see that the problem statement can be more specific on 
>> metadata definition, which may be helpful in less focusing on it and moving forward.
>> 
>> Lucy
>> 
>> Surendra.
>> 
>> 
>>> 
>>> Thanks,
>>> Lucy
>>> 
>>>> I for one don't agree and think we are over complicating what 
>>>> should be straightforward. The SFC encapsulation should enable two things:
>>>> 
>>>> service function path. This context information may be consumed by 
>>>> a SF (an application ID is an example) or may be consumed by the 
>>>> [Lucy] Do you call the context as metadata or not? Do we have 
>>>> another term here beside SFC header and metadata. I see that you 
>>>> don't want to separate what is consumed by SF and what is consumed 
>>>> by the forwarding elements.
>>>> 
>>>> Lucy
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> Great. Then we may consider two special metadata definitions in 
>>>>> the problem statement so we can all use the same definitions. Here 
>>>>> is my suggested text and like to hear you and other's input and suggestions.
>>>>> 
>>>>>> Wednesday, March 12, 2014 2:02 PM To: Lucy yong; Nicolas 
>>>>>> BOUTHORS; Ron Parker Cc: Jim Guichard (jguichar); 
>>>>>> classifier or from other service functions. [Lucy] this is the 
>>>>>> one case using metadata in your view. Information for the 
>>>>>> forwarding will generally come from the ingress classifier, but 
>>>>>> in special cases may be provided by service functions.  (I keep 
>>>>>> wanting to get rid of those special cases, but so far there seem 
>>>>>> to be just enough of them to warrant covering in the solution.  
>>>>>> And more importantly, significant support for it in the working 
>>>>>> group.) [Lucy] This is the second case using metadata in your view (but you don't like it).
>>>>>> 
>>>>>>> Joel, I interpret that you suggests that distinguish the 
>>>>>>> exchange information data plane carried between service 
>>>>>>> functions and the exchange information data plane carried from a 
>>>>>>> service function to a service node. Is this right understanding? 
>>>>>>> Lucy
>>>>>>> 
>>>>>>> 1:19 PM
>>>>>>> between dataplane carried information intended for use by 
>>>>>>> service funcitons (whatever the origin), and dataplane carried 
>>>>>>>> lead to a particular solution. I am fine with this definition 
>>>>>>>> in the problem statement w/ minor tweak (suggested on mailing list).
>>>>>>>> 
>>>>>>>> been using the term metadata more narrowly.  We can use 
>>>>>>>> whatever definition we want. But we do need to agree on the definition.
>>>>>>>> For the purposes of the WG, it seems much more useful to use 
>>>>>>>> the term metadata for the narrower description.
>>>>>>>> 
>>>>>>>> Yours, Joel
>>>>>>>> 
>>>>>>>>> metadata carried on packet for next service node to use. In 
>>>>>>>>> the context of SFC, we have term for SFC header and the 
>>>>>>>>> metadata that was carried between service functions, or 
>>>>>>>>> between service functions and classifiers/service nodes, which 
>>>>>>>>> is what the draft focus.
>>>>>>>>> 
>>>>>>>>> Thanks, Lucy
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> chaining information in the base service chain header, which 
>>>>>>>>> is for use by the service chain support mechanisms.
>>>>>>>>> 
>>>>>>>>> Yours, Joel
>>>>>>>>> 
>>>>>>>>>> to next service node, SFC header itself can be seen as a metadata.
>>>>>>>>>> 
>>>>>>>>>> Lucy
>>>>>>>>>> 
>>>>>>>>>>> would agree that if we can accept these issues, then sending 
>>>>>>>>>>> identical reconstruction of the associated metadata. In some 
>>>>>>>>>>> cases, we might thus even need non-congruent out-of-band 
>>>>>>>>>>> reliable metadata transport.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> band marking. - Metadata with can be passed out of band, 
>>>>>>>>>>>> for example congruent out of band signaling defined in the 
>>>>>>>>>>>> draft
>>>>>>>>>>>> 
>>>>>>>>>>>> the majority of cases. Remember, the goal of being able to 
>>>>>>>>>>>> pass metadata through the network is to enhance service 
>>>>>>>>>>>> delivery, not pass the entire works of Shakespeare ;-)
>>>>>>>>>>>> 
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 13 Mar 2014 18:37:37 +0000

Hi Lucy,
Please see my previous email and work with Joel to come up with
consolidated text that can be inserted into the problem statement.

On 3/13/14, 2:34 PM, "Lucy yong" <[email-masked]> wrote:

>Opaque to what? Current definition does not imply that at all. It
>basically allows a metadata to be exchanged by any element in the chain.
>
>Lucy
>
>Cc: Lucy yong; Surendra Kumar (smkumar); Guichard Jim; Nicolas BOUTHORS;
>sfc; Jamal Hadi Salim; Ron Parker; [email-masked]; Joel M. Halpern

---

From: "Louis.Fourie" <[email-masked]>
Date: Fri, 14 Mar 2014 22:12:12 +0000

Cathy,
    Another advantage of a more flexible service chain header is
that vendor-specific metadata can be transported as is currently
done using vendor-specific attribute-value pairs (AVPs) in Diameter.
 
- Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Wednesday, March 12, 2014 11:17 AM
To: Ron Parker; Jim Guichard (jguichar); Cathy Zhang
Cc: Nicolas BOUTHORS; [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Thanks,
Cathy 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, March 11, 2014 1:00 PM
To: Jim Guichard (jguichar)
Cc: Nicolas BOUTHORS; [email-masked]; sfc; Jamal Hadi Salim
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Jim,

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2014 3:52 PM
To: Ron Parker
Cc: Nicolas BOUTHORS; Jamal Hadi Salim; [email-masked]; [email-masked]; sfc
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Sent from my iPhone