Subject: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 Apr 2014 22:27:14 +0000

Bruno and Jerome, 

I like your analysis of various methods of carrying metadata and their associated challenges. 

But some "metadata" mentioned in your draft have been traditionally considered as part of policy, as the "20Mbps/30Mbps" used in your Figure 2. 

Some metadata examples in your draft are specifically passed to service functions. In many deployment today, Diameter is used to pass those "metadata" to the service functions. 
So for those metadata, your analysis on challenges (4.1: metadata-unaware) are not quite right. 

I think that we need to have fine-grade names for metadata to make the discussion more accurate and to the point. For example: we should have

- Application Layer metadata: those are the metadata exchanged among applications

- Service Function layer metadata (or Middleware layer messaging): those are the metadata exchanged among service functions

- Metadata exchanged between Service Functions and Network nodes: those are the metadata exchanged between service functions and network nodes.  For example,  a DPI function can add a specific "marker" on the packet, so the network nodes can forward the packet with the policy defined by the "marker". 

With this fine grade metadata, the challenges and the needed network header extension can be specific and more clearly described. 

For the "metadata" strictly between applications or between service functions, like the cookies attached to HTTP, today's Proxy Based service functions can already handle them well. It is debatable if any network header extension is needed for those metadata. 

For the "metadata" exchanged between Service functions and Network Nodes, there is definitely the need for standardized network layer header to carry those extra information. 

With those fine grade "metadata", the discussion can be more focused and meaningful. 

Linda Dunbar

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, March 14, 2014 1:35 PM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

If the transport header carries enough information for identifying the sequence (VLAN tag or MPLS label can both do the job), then arguably the global chain ID is redundant.  I can live with carrying it anyway either if I have metadata to carry, or if I need the chain ID for some purpose. 
  After all, some folks seem to want to use that for the forwarding decisions.

Yours,
Joel

On 3/14/14, 2:28 PM, Ron Parker wrote:
> The chain ID is the label that defines the sequence of service functions that must be visited.   It can be thought of as a handle for a stack of must-visit network locations.   I don't see how this can be anything but mandatory.
>
>     Ron
>
>
> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar 
> (smkumar)
> Sent: Friday, March 14, 2014 1:46 PM
> To: Joel M. Halpern; NAPIERALA, MARIA H
> Cc: [email-masked]
> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>
> [Trimmed the recipient list - needs approval otherwise]
>
> Completely agree here.
>
> SFC does not prevent VLAN stitching and one can continue to do that. While at the same time SFC can include VLAN stitching to support legacy SFs in the same chain that includes SFC aware SFs. Even legacy SFs benefit from chain identification and hence can be shared across different service chains.
>
> Surendra.
>
>
>
> On 3/14/14 10:26 AM, "Joel M. Halpern" <[email-masked]> wrote:
>
>> My own inclination is to observe that if you don't need explicit 
>> chain identification and you don't need metadata, you can just omit 
>> the sfc/nsh header.  Still do service chaining, just no extra header.
>>
>> If we are going to have the header, it seems to me that the chain 
>> identification field is very useful, and low cost once we have the header.
>>
>> Yours,
>> Joel
>>
>> On 3/14/14, 1:00 PM, NAPIERALA, MARIA H wrote:
>>> Explicit chain identification should be made optional. I believe it 
>>> was discussed few months ago on this mailing list.
>>>
>>> Maria
>>>
>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jmh.direct
>>> *Sent:* Thursday, March 13, 2014 12:12 PM
>>> *To:* [email-masked]; [email-masked]; [email-masked]; 
>>> [email-masked]
>>> *Cc:* [email-masked]; [email-masked]; [email-masked]; 
>>> [email-masked]; [email-masked]; 
>>> [email-masked]
>>> *Subject:* Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>> *Importance:* Low
>>>
>>> Assuming I understand you properly Ken, I disagree.
>>>
>>> For example, by using separate terms I can easily discuss the fact 
>>> that  certain kinds of data (chain identification) only need to be 
>>> adjust by a  few apps in rare cases.  And that data is not beeded by 
>>> the applications.
>>>
>>> Unless you would like to consider the chain identification as being 
>>> optional?
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>>
>>>
>>> Sent from my Samsung smartphone on AT&T
>>>
>>>
>>>
>>>
>>> -------- Original message --------
>>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>> From: "Ken Gray (kegray)" <[email-masked] 
>>> <mailto:[email-masked]>>
>>> To: Lucy yong <[email-masked]
>>> <mailto:[email-masked]>>,"Surendra Kumar (smkumar)"
>>> <[email-masked] <mailto:[email-masked]>>,"Jim Guichard (jguichar)"
>>> <[email-masked] <mailto:[email-masked]>>
>>> CC: Nicolas BOUTHORS <[email-masked] 
>>> <mailto:[email-masked]>>,sfc <[email-masked] 
>>> <mailto:[email-masked]>>,Jamal Hadi Salim <[email-masked] 
>>> <mailto:[email-masked]>>,Ron Parker 
>>> <[email-masked] 
>>> <mailto:[email-masked]>>,"[email-masked]
>>> <mailto:[email-masked]>" <[email-masked] 
>>> <mailto:[email-masked]>>,"Joel M. Halpern" 
>>> <[email-masked] <mailto:[email-masked]>>
>>>
>>> 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] 
>>> <mailto:[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] <mailto:[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] 
>>> <mailto:[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] <mailto:[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] 
>>> <mailto:[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] 
>>> <mailto:[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] 
>>> <mailto:[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] <mailto:[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] 
>>> <mailto:[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]  <mailto:[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] <mailto:[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] 
>>> <mailto:[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] 
>>> <mailto:[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] 
>>> <mailto:[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] 
>>> <mailto:[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] <mailto:[email-masked]>; 
>>> [email-masked] <mailto:[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] <mailto:[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] <mailto:[email-masked]>
>>>   >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>   >>>>>>>>>>>>>
>>>   >>>>>>>>>>>>>
>>>   >>>>>>>>>>>>>
>>>   >>>>>>>>>>>>> _______________________________________________ sfc 
>>> mailing
>>>   >>>>>>>>>>>>> list [email-masked] <mailto:[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>   >>>>>>>>>>
>>>   >>>>>>>>>> _______________________________________________ sfc 
>>> mailing
>>>   >>>>>>>>>> list [email-masked] <mailto:[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>   >>>>>>>>>
>>>   >>>>>>>>> _______________________________________________ sfc 
>>> mailing
>>>   >>>>>>>>> list [email-masked] <mailto:[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>   >>>>>>>>>
>>>   >>>>>>>>> _______________________________________________ sfc 
>>> mailing
>>>   >>>>>>>>> list [email-masked] <mailto:[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>   >>>>>
>>>   >>>>> _______________________________________________ sfc mailing 
>>> list
>>>   >>>>> [email-masked] <mailto:[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>   >>>>>
>>>   >>
>>>   >>_______________________________________________
>>>   >>sfc mailing list
>>>   >>[email-masked] <mailto:[email-masked]>
>>>   >>https://www.ietf.org/mailman/listinfo/sfc
>>>   >
>>>   >_______________________________________________
>>>   >sfc mailing list
>>>   >[email-masked] <mailto:[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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Apr 2014 18:37:07 -0400

Your comment about metadata between service functions being handled 
today seems to be based on some set of less than obvious assumptions.  I 
do not know of any applicable mechanism today whereby a DPI service 
function can pass to a content manipulation service function the media 
type and offset to the content.  And that is only one example of many.

Even the few cases that are used today are typically done by 
manipulation of the message content in a fragile fashion.

Yours,
Joel

> But some "metadata" mentioned in your draft have been traditionally considered as part of policy, as the "20Mbps/30Mbps" used in your Figure 2.
...
> For the "metadata" exchanged between Service functions and Network Nodes, there is definitely the need for standardized network layer header to carry those extra information.
...

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Apr 2014 01:12:56 +0000

Joel, 

Today's proxy based service functions terminate TCP session and restart the TCP session to the next service function or the destination of the packet. Some of them attach data/cookies to the packet. 

All those are strictly between service functions. 

I didn't say anything about "DPI service function passing to a content manipulation service function the media type and offset to the content". 

There have been proposals (not at IETF yet) for having a fixed header field in data packets for a service function to insert some marker (or identifier) for network nodes to steer the packet without looking deeper into the packets, or vise versa. Those metadata between "service function" and "network node" should be the one that requires Metadata standardization. 

Yours, 

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2014 5:37 PM
To: Linda Dunbar; [email-masked]; [email-masked]; Ron Parker
Cc: [email-masked]
Subject: Re: Comments and suggestions to draft-rijsman-sfc-metadata-considerations

Your comment about metadata between service functions being handled today seems to be based on some set of less than obvious assumptions.  I do not know of any applicable mechanism today whereby a DPI service function can pass to a content manipulation service function the media type and offset to the content.  And that is only one example of many.

Even the few cases that are used today are typically done by manipulation of the message content in a fragile fashion.

Yours,
Joel

...
...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Apr 2014 08:17:21 -0400

Maybe I am misreading your notes.

The first part of your reply seems to say that there are existing 
techniques by which some service functions can pass data on to some 
other service functions.  That is true.  That does not mean that the 
range of needs is addressed.  You even seem to acknowledge that.

You then go on to say that we should only address the other problem 
(metadata between service functions and network nodes).

Given that a large part of the problem of carrying metadata between 
service functions is not addressed currently, I do not see why we should 
neglect addressing that major problem.

Yours,
Joel

On 4/8/14, 9:12 PM, Linda Dunbar wrote:
>
> Joel,
>
> Today's proxy based service functions terminate TCP session and
> restart the TCP session to the next service function or the
> destination of the packet. Some of them attach data/cookies to the
> packet.
>
> I didn't say anything about "DPI service function passing to a
> content manipulation service function the media type and offset to
> the content".
>
> There have been proposals (not at IETF yet) for having a fixed header
> field in data packets for a service function to insert some marker
> (or identifier) for network nodes to steer the packet without looking
> deeper into the packets, or vise versa. Those metadata between
> "service function" and "network node" should be the one that requires
> Metadata standardization.
>
> Yours,
>
> Linda
>
>
> [mailto:[email-masked]] Sent: Tuesday, April 08, 2014 5:37 PM
> To: Linda Dunbar; [email-masked]; [email-masked]; Ron
> Parker Cc: [email-masked] Subject: Re: Comments and suggestions to
> today seems to be based on some set of less than obvious assumptions.
> I do not know of any applicable mechanism today whereby a DPI service
> function can pass to a content manipulation service function the
> media type and offset to the content.  And that is only one example
> of many.
>
>> But some "metadata" mentioned in your draft have been traditionally
>> considered as part of policy, as the "20Mbps/30Mbps" used in your
>> Figure 2.
>>
> ...
>> For the "metadata" strictly between applications or between service
>> functions, like the cookies attached to HTTP, today's Proxy Based
>> service functions can already handle them well. It is debatable if
>> any network header extension is needed for those metadata.
>>
>> For the "metadata" exchanged between Service functions and Network
>> Nodes, there is definitely the need for standardized network layer
>> header to carry those extra information.
>>
> ...
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Apr 2014 14:48:18 +0000

Joel, 

Comments inserted inline below:

-----Original Message-----

The first part of your reply seems to say that there are existing techniques by which some service functions can pass data on to some other service functions.  That is true.  That does not mean that the range of needs is addressed.  You even seem to acknowledge that.

[Linda] Do you think the information exchange between service functions are relevant to routing? Shouldn't those metadata be transparent to network nodes?

You then go on to say that we should only address the other problem (metadata between service functions and network nodes).

[Linda] Because I think those metadata are relevant to network layer and routing. 

Given that a large part of the problem of carrying metadata between service functions is not addressed currently, I do not see why we should neglect addressing that major problem.

Yours,
Joel

On 4/8/14, 9:12 PM, Linda Dunbar wrote:
> I didn't say anything about "DPI service function passing to a content 
> manipulation service function the media type and offset to the 
> content".
>
> field in data packets for a service function to insert some marker (or 
> identifier) for network nodes to steer the packet without looking

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Thu, 10 Apr 2014 13:16:34 +0000

Hello

I can see the benefit, as shown by Linda, to distinguish how to convey metadata according to which function  
will benefit from its use. 

The metadata draft from Bruno shows many possibilities. At the same time, there are discussions on 
how intelligent/flexible a SFF should/could be. I think an Openflow based SFF for example could
provide added value, provided it finds in the SFC header enough information.

A fixed size header can carry a number of information allowing Service Switching Functions to take local 
decision on how to handle incoming or outgoing traffic. I share with Linda the feeling that an application Id 
field and a fine grain policy field,  will enable innovation compared to a header opaque or without any 
metadata. 

Congruent metadata messages are a good complement to send information from one SF or another one, 
There are ways to allow SF to retrieve this information, just as there are ways for SF to retreive out of band 
metadata. In both cases, the metadata messages are not constrained in size, and some standard format 
exists already to carry similar information. 

Nicolas
________________________________________
From: Joel M. Halpern [[email-masked]]
Sent: Wednesday, April 09, 2014 2:17 PM
To: Linda Dunbar; [email-masked]; [email-masked]; Ron Parker
Cc: [email-masked]
Subject: Re: [sfc] Comments and suggestions to draft-rijsman-sfc-metadata-considerations

Yours,
Joel

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 10 Apr 2014 17:05:38 +0000

A few in lines of my own ...

On 4/9/14 10:48 AM, "Linda Dunbar" <[email-masked]> wrote:

>techniques by which some service functions can pass data on to some other
>service functions.  That is true.  That does not mean that the range of
>needs is addressed.  You even seem to acknowledge that.
>
>[Linda] Do you think the information exchange between service functions
>are relevant to routing? Shouldn't those metadata be transparent to
>network nodes?

{Ken} - I don't recall any text saying the network nodes (assuming you
mean the infrastructure here) HAS to parse the metadata.

>[Linda] Because I think those metadata are relevant to network layer and

{Ken} - not only did this seem contradictory to your proposal for
separation of the two, I'm super curious how you see service function
metadata being relevant to routing (keeping in mind that the non-metadata
part of the header has a path info imbedded).