Subject: [sfc] Metadata - the scope of it

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 14 Mar 2014 19:59:20 +0000

[Changed the subject line]

One thing there has pretty much been a consensus on is the need for
metadata!

At the risk of this discussion de-generating into "wordsmithing" - as
Adrian put it some time back, we are better served putting WG energy back
on the valid question this/original thread started out with (as well as
from others lately) :
1. Do we need variable size metadata ? Why ? Usecase ...
2. How large is too large ?
3. What are the implications of carrying large metadata on resources,
overhead, performance, MTU, even correctness, etc.

What we want to do is "aid" service delivery by providing minimally
necessary meta-data in-band with the packet in the data plane while
distributing necessary data out-of-band. This mechanism is not for
designing implementations around sharing large states between SFs. There
are IPC/data exchange mechanisms to do that.

As for the wording:
If "network" is too general, is "network element" narrow enough ? Or we
could simply include what a network element may be in general terms. While
it is a good idea to limit the scope of the problem statement, overdoing
it runs the risk of framing the problem to a specific implementation.

My 0.02
Surendra.

On 3/13/14 11:36 AM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>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:
>
>>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:
>>
>>>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.
>>>
>>>--
>>>It is a lucid definition. We are unnecessarily making the word "network"
>>>controversial, IMO.
>>>
>>>[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
>>>>
>>>>-----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:
>>>>
>>>>>
>>>>>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:
>>>>>
>>>>>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
>>>>>
>>>>>> On Mar 12, 2014, at 4:16 PM, "Lucy yong" <[email-masked]>
>>>>>>wrote:
>>>>>> 
>>>>>> 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:
>>>>>>> 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:
>>>>>>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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:
>>>>>>>>>> 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:
>>>>>>>>>>> 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.
>>>>>>>>>>>> 
>>>>>>>>>>>> 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,
>>>>>>>>>>>> 
>>>>>>>>>>>> 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:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 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 ________________________________________ 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
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Mar 7, 2014, at 3:52 AM, "Ron Parker"
>>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 3/3/14, 6:35 AM, "Jamal Hadi Salim"
>>>>>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> _______________________________________________ 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
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________ 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
>>
>