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

From: "Jmh.direct" <[email-masked]>
Date: Thu, 13 Mar 2014 12:12:08 -0400

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]> 
To: Lucy yong <[email-masked]>,"Surendra Kumar (smkumar)" <[email-masked]>,"Jim Guichard (jguichar)" <[email-masked]> 
CC: Nicolas BOUTHORS <[email-masked]>,sfc <[email-masked]>,Jamal Hadi Salim <[email-masked]>,Ron Parker <[email-masked]>,"[email-masked]" <[email-masked]>,"Joel M. Halpern" <[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]> 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

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 13 Mar 2014 19:06:53 +0000

There is a purposeful separation of the chain data from the metadata in the proposal.

We all agreed that chain classification and thus the associated service chain header (path, index, etc) had to be done at least once … you have to identify traffic and from that action, select the chain … we imbed that data not only for steering, debugging, etc but because it's potentially useful to every function (to avoid reclassification if the function is in any way shared between multiple flows and takes action based on classification).

Metadata wasn't defined, isn't defined.   It is carried in a channel that is created as part of the header that applications can use to talk between themselves – as they might in a co-joined deployment in which they might use IPC to transfer similar "clues" about pre and post processing information.   Similarly a service MAY use that channel as an end-to-end collector/distributor of service-related data IF the data conforms to the property of the channel - temporally immediate, carrying mutable and ultimately  impermanent data.  Further, if you want to architecturally separate the network forwarder from the application and you believe they need to pass information … you can use the same amorphous channel ….

I see no need to call one "application to application metadata" and another "network to application metadata" and yet another "service to application metadata" (and or the reverse).  These are all derivative (IMO) definitions that fit within the original definition of metadata.

Finally, whether the application or overall service uses metadata or not, just like whether it uses the chain data, is optional.  However, unlike the chain data, no metadata HAS to be created in order to identify the chain, select it's path etc.

From: "Jmh.direct" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 13, 2014 11:12 AM
To: Ken Gray <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Surendra Kumar (smkumar)" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Yours,
Joel

-------- 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]>>

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

>>[email-masked]<mailto:[email-masked]>; sfc; Jamal Hadi Salim
>>On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>>
>>>Hi Jim,
>>>
>>>> On Mar 12, 2014, at 4:16 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>> Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>; sfc; Jamal Hadi
>>>> Salim
>>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>; sfc;
>>>>>> (jguichar); [email-masked]<mailto:[email-masked]>; sfc; Jamal Hadi Salim Subject:
>>>>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>;
>>>>>>>> Guichard (jguichar); [email-masked]<mailto:[email-masked]>; sfc; Jamal Hadi Salim
>>>>>>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>;
>>>>>>>>>> Parker [[email-masked]<mailto:[email-masked]>] Sent: Wednesday,
>>>>>>>>>> March 12, 2014
>>>>>>>>>> [email-masked]<mailto:[email-masked]>; sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Jim Guichard (jguichar) [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>>>>>>> Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>; sfc; Jamal Hadi Salim
>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Nicolas,
>>>>>>>>>>>>
>>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Jim
>>>>>>>>>>>>>
>>>>>>>>>>>>> (jguichar) [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>>>>>>>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Cc:
>>>>>>>>>>>>> sfc Subject: Re: [sfc]
>>>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> mailing list [email-masked]<mailto:[email-masked]>
>>>>>>>>>>>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>>>
>>>>>>>>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>>
>>>>>>>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>>
>>>>>>>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>>>>
>>>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>>>>
>>
>>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 17:00:44 +0000

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

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Mar 2014 13:26:50 -0400

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
>
> 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.
>
> 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]>>
>
>  >>[email-masked] <mailto:[email-masked]>; sfc; Jamal Hadi Salim
>  >>>> Cc: Jim Guichard (jguichar); [email-masked]
> <mailto:[email-masked]>; sfc; Jamal Hadi
>  >>>> Salim
>  >>>>>> (jguichar); [email-masked] <mailto:[email-masked]>;
> sfc; Jamal Hadi Salim Subject:
>  >>>>>>>> Guichard (jguichar); [email-masked]
> <mailto:[email-masked]>; sfc; Jamal Hadi Salim
>  >>>>>>>>>> [email-masked] <mailto:[email-masked]>; sfc;
>  >>>>>>>>>>> <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >>>>>>>>>>>
>  >>>>>>>>>>> Nicolas BOUTHORS; [email-masked]
> <mailto:[email-masked]>; sfc; Jamal Hadi Salim
>  >>>>>>>>>>>> <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >>>>>>>>>>>>
>  >>>>>>>>>>>> Nicolas,
>  >>>>>>>>>>>>
>  >>>>>>>>>>>>> <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >>>>>>>>>>>>>
>  >>>>>>>>>>>>> Hello Jim
>  >>>>>>>>>>>>>
>  >>>>>>>>>>>>> [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]> Cc:
>  >>>>>>>>>>>>> sfc Subject: Re: [sfc]
>  >>>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>  >>>>>>>>>>>>>>
>  >>>>>>>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>  >>>>>>>>>>>>> list [email-masked] <mailto:[email-masked]>
>  >>>>>>>>>> list [email-masked] <mailto:[email-masked]>
>  >>>>>>>>> list [email-masked] <mailto:[email-masked]>
>  >>>>>>>>> list [email-masked] <mailto:[email-masked]>
>  >>>>> [email-masked] <mailto:[email-masked]>
>  >>[email-masked] <mailto:[email-masked]>
>  >[email-masked] <mailto:[email-masked]>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 14 Mar 2014 17:46:10 +0000

[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:

>>1:19
>>  >>>>>>>>>>> Subject: Re: [sfc]

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 17:55:47 +0000

Why do you mention VLANs stitching? As an example? 
I was not referring to VLAN stitching at all. 

Maria

> From: Surendra Kumar (smkumar) [mailto:[email-masked]]
> Sent: Friday, March 14, 2014 1:46 PM
> To: Joel M. Halpern; NAPIERALA, MARIA H
> Cc: [email-masked]
> >> that, by definition, is ambiguous.  I'd like my bartender to
> understand
> >>me
> >>  >should not spend a lot of times on that debates and judge which
> usage
> >>is
> >>  >narrow down a bit. Joel makes explicitly two cases, which is
> helpful
> >>to
> >>  >>[email-masked] <mailto:[email-masked]>; sfc; Jamal
> Hadi
> >>Salim
> >>  >>>term here beside SFC header and metadata. I see that you don't
> want
> >>to
> >>  >>>> Great. Then we may consider two special metadata definitions
> in
> >>the
> >>  >>>>problem statement so we can all use the same definitions. Here
> is
> >>my
> Sent:
> >>  >>>>> classifier or from other service functions. [Lucy] this is
> the
> >>one
> >>  >>>>> cases may be provided by service functions.  (I keep wanting
> to
> >>get
> >>  >>>>> the second case using metadata in your view (but you don't
> like
> >>it).
> >>  >>>>>
> >>  >>>>>> exchange information data plane carried from a service
> function
> >>to
> >>  >>>>>>> information put in the SFC header. This may be too narrow
> or
> >>lead
> >>  >>>>>>> Ron Parker Cc: Jim Guichard (jguichar);
> [email-masked]
> >> <mailto:[email-masked]>;
> >>  >>>>>>> For the purposes of the WG, it seems much more useful to
> use
> >>the
> >>  >>>>>>>>context of SFC, we have term for SFC header and the
> metadata
> >>that
> >>  >>>>>>>> chaining information in the base service chain header,
> which
> >>is
> >>  >>>>>>>>> node inserts SFC header on a (encapsulated) packet and
> send
> >>to
> >>  >>>>>>>>> Ron Parker Cc: Jim Guichard (jguichar);
> [email-masked]
> >> <mailto:[email-masked]>;
> >>  >>>>>>>>> t1, t2, t3, and t4" is simply too specific for even 80%
> of
> >>the
> >>  >>>>>>>>>needs.
> >>  >>>>>>>>>
> >>  >>>>>>>>> Yours, Joel
> >>  >>>>>>>>>
> >>  >>>>>>>>>> fragmentation, and some switches expecting as well to
> look
> >>at
> >>  >>>>>>>>>>complexity due to the potential race condition of
> receiving
> >>the
> >>  >>>>>>>>>>> band marking. - Metadata with can be passed out of
> band,
> >>for
> >>  >>>>>>>>>>> The former calls for a limited space in the header,
> true,
> >>The
> >>  >>>>>>>>>>> size header used to route those signaling messages
> along
> >>the
> >>  >>>>>>>>>>> information can fit within a fixed number of contexts
> in
> >>the
> >>  >>>>>>>>>>>> metadata and vendor or other organizational OUIs can
> be
> >>used
> >>  >>>>>>>>>>>>> enrichment (aimed at some Web Content providers
> partners
> >>of
> >>  >>>>>>>>>>>>> the Mobile Operator).
> >>  >>>>>>>>>>>>> In an sfc based Gi LAN, this entity should receive
> from
> >>the
> >>  >>>>>>>>>>>>> Classifier
> >>  >>>>>>>>>>>>>
> >>  >>>>>>>>>>>>> subscriber - Two subscriber policy fields (not tied
> to
> >>PCRF
> >>  >>>>>>>>>>>>> become a trusted application (interogate the
> subscriber
> >>DB,
> >>  >>>>>>>>>>>>> etc..)
> >>  >>>>>>>>>>>>>
> >>  >>>>>>>>>>>>>
> >>  >>>>>>>>>>>>> Nicolas
> >>  >>>>>>>>>>>>>
> >>  >>>>>>>>>>>>>
> >>  >>>>>>>>>>>>> understand the requirements before passing judgement.
> If
> >>we
> >>  >>>>>>>>>>>>> desire is not the same as need) - I am not saying
> there
> >>is
> >>  >>>>>>>>>>>>>> (at least for http/app you  seem to indicate the
> desire
> >>for
> >>  >>>>>>>>>>>>>>it).

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 14 Mar 2014 13:58:01 -0400

While I could live with eliminating the chain ID entirely, that does not 
seem to match the WG agreement.  Making it optional seems to complicate 
the configuration required to achieve interoperability.
Yours,
Joel

On 3/14/14, 1:52 PM, NAPIERALA, MARIA H wrote:
> My view is that unique and explicit chain identification will be
> difficult to manage and it is not needed to achieve service chaining.
> I would rather deal with implicit service chain identification.
> Hence, I believe it should be made optional whether it is carried it
> in the sfc header.
>
> Maria
>
>> [mailto:[email-masked]] Sent: Friday, March 14, 2014 1:27 PM
>> To: NAPIERALA, MARIA H; [email-masked]; [email-masked];
>> [email-masked]; [email-masked] Cc:
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked] Subject: Re:
>> [sfc] draft-rijsman-sfc-metadata-considerations
>>
>> 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.
>>
>>> Explicit chain identification should be made optional. I believe
>>> it
>> was
>>> *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]
>>> 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
>>> -------- Original message -------- Subject: Re: [sfc]
>>> draft-rijsman-sfc-metadata-considerations From: "Ken Gray
>>> (kegray)" <[email-masked]
>> <mailto:[email-masked]>>
>>> <[email-masked] <mailto:[email-masked]>> CC: Nicolas
>>> BOUTHORS <[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
>> understand me
>>>> 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
>>>> -- 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
>> usage is
>>>> valuable or not. Thus, for the SFC work, it will be helpful if
>>>> we
>> can
>> helpful to
>>>> 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]
>>>>> 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
>>>>>> 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
>>>>>> elements (a vrf-ID is an example). [Lucy] Do you call the
>>>>>> context as metadata or not? Do we have
>> another
>> 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
>> 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
>>>>>>>
>>>>>>>
>>>>>>> [mailto:[email-masked]] Sent: Wednesday, March 12,
>>>>>>> 2014 2:35 PM To: Lucy yong; Nicolas BOUTHORS; Ron Parker
>>>>>>> Salim Subject: Re: [sfc]
>>>>>>> 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.
>>>>>>>> Wednesday, March 12, 2014 2:02 PM To: Lucy yong;
>>>>>>>> Nicolas
>> BOUTHORS;
>>> <mailto:[email-masked]>; sfc;
>>>>>>>> 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
>>>>>>>> will generally come from the ingress classifier, but
>>>>>>>> in
>> special
>> to get
>>>>>>>> rid of those special cases, but so far there seem to be
>>>>>>>> just
>> enough
>>>>>>>> significant support for it in the working group.)
>>>>>>>> [Lucy] This
>> is
>> 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
>> function to
>>>>>>>>> PM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc:
>>>>>>>>> Jim Guichard (jguichar); [email-masked]
>>>>>>>>> between dataplane carried information intended for
>>>>>>>>> use by
>> service
>>>>>>>>> funcitons (whatever the origin), and dataplane
>>>>>>>>> carried
>> information
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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;
>>>>>>>>>> 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
>>>>>>>>>> For the purposes of the WG, it seems much more
>>>>>>>>>> useful to use
>> the
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [mailto:[email-masked]] Sent: Wednesday,
>>>>>>>>>>> March 12,
>> 2014
>>>>>>>>>>> 11:18 AM To: Lucy yong; Nicolas BOUTHORS; Ron
>>>>>>>>>>> Parker Cc:
>> Jim
>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>> 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;
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>> Sending out of band congruent metadata may
>>>>>>>>>>>>> not be the
>> answer
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 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;
>>>>>>>>>>>>> I understand the concept for out of band
>>>>>>>>>>>>> signaling of metadata, but I am concerned
>>>>>>>>>>>>> that it introduces
>> significant
>> 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
>>>>>>>>>>>>> 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]
>>>>>>>>>>>>>> - 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
>>>>>>>>>>>>>>
>> 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
>>>>>>>>>>>>>> ________________________________________
>>>>>>>>>>>>>> From: Jim Guichard (jguichar)
>>>>>>>>>>>>>> [[email-masked]] Sent: Tuesday, March
>>>>>>>>>>>>>> 11, 2014 6:48 PM To: Ron Parker Cc: Nicolas
>>>>>>>>>>>>>> BOUTHORS; [email-masked]
>>>>>>>>>>>>>> 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,
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> Simultaneously, I would also like to
>>>>>>>>>>>>>>> consider
>> mechanisms
>>>>>>>>>>>>>>> that are optimized for long lived flows
>>>>>>>>>>>>>>> so as to limit
>> the
>>>>>>>>>>>>>>>> On Mar 7, 2014, at 8:34 AM, "Nicolas
>>>>>>>>>>>>>>>> BOUTHORS" <[email-masked]
>>>>>>>>>>>>>>>> I have seen cases in Gi LAN, where
>>>>>>>>>>>>>>>> subscriber related information is
>>>>>>>>>>>>>>>> passed to a Web Proxy for HTTP header
>> partners of
>>>>>>>>>>>>>>>> the Mobile Operator). Information was
>>>>>>>>>>>>>>>> an coded (persistent) subscriber id
>> derived
>>>>>>>>>>>>>>>> from the MSISDN, and couple of f
>>>>>>>>>>>>>>>> customer profile
>> related
>>>>>>>>>>>>>>>> fields.
>>>>>>>>>>>>>>>>
>> from the
>>>>>>>>>>>>>>>> - 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
>>>>>>>>>>>>>>>> Thursday, March 06, 2014 2:02 PM To:
>>>>>>>>>>>>>>>> Jamal Hadi Salim; [email-masked]
>>>>>>>>>>>>>>>> <mailto:[email-masked]>;
>>>>>>>>>>>>>>>> You said "It seems there's clear need
>>>>>>>>>>>>>>>> for variable
>> sized
>>>>>>>>>>>>>>>> metadata".. I am not so convinced and
>>>>>>>>>>>>>>>> would like to
>> better
>> 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
>> there is
>>>>>>>>>>>>>>>> no requirement but rather that we
>>>>>>>>>>>>>>>> should not jump to
>> the
>>>>>>>>>>>>>>>>> On 3/3/14, 6:35 AM, "Jamal Hadi
>>>>>>>>>>>>>>>>> Salim" <[email-masked]
>>>>>>>>>>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems there's clear need for
>>>>>>>>>>>>>>>>> variable sized
>> metadata
>> 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]>
>>>>>>>>>>>>>>>> sfc
>> mailing
>>>>>>>>>>>>> sfc
>>>>>>>>>>>> sfc
>>>>>>>>>>>> sfc
>>>>>>>> mailing

---

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

Maria,

I was simply offering one example of not requiring a chain identification
to achieve service chaining which has been done for ages.

Surendra.

On 3/14/14 10:55 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>> provides
>> frankly, I
>> discussing
>> ability to

---

From: Ron Parker <[email-masked]>
Date: Fri, 14 Mar 2014 18:28:21 +0000

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

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:

>> Explicit chain identification should be made optional. I believe it 
>> was discussed few months ago on this mailing list.
>>
>> Maria
>>
>> 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.
>>
>> 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".
>>
>>Hadi Salim
>>  >>>>>> (jguichar); [email-masked] 
>><mailto:[email-masked]>;  sfc; Jamal Hadi Salim Subject:
>>[email-masked]  <mailto:[email-masked]>;

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Mar 2014 14:35:30 -0400

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

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 18:39:01 +0000

Well, we can do service chaining today without such explicit ID (and not based on VLAN stitching). So, it is possible.

Maria

> From: Ron Parker [mailto:[email-masked]]
> Sent: Friday, March 14, 2014 2:28 PM
> To: Surendra Kumar (smkumar); Joel M. Halpern; NAPIERALA, MARIA H
> Cc: [email-masked]
> Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations
> 
> 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
> 
> 
> 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.
> 
> 
> 
> ability
> >>  >>>>>>>>>> reconstruction of the associated metadata. In some
> cases,
> >>we
> >>  >>>>>>>>>>> - Metadata which should be part of the header defined
> as
> >>in

---

From: Lucy yong <[email-masked]>
Date: Fri, 14 Mar 2014 18:58:59 +0000

Hi Maria,

We understand that SP can do service chaining today. One clarification: can you do it with constraints on where SFs to be place, i.e. MUST be on traffic path, or do it without such constraint today?

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Friday, March 14, 2014 1:39 PM
To: Ron Parker; Surendra Kumar (smkumar); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Maria

> 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 
> >the sfc/nsh header.  Still do service chaining, just no extra header.
> >
> >><[email-masked] <mailto:[email-masked]>> wrote:
> >>  >>>>
> >>definition you

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Mar 2014 19:02:48 +0000

Yes, if all you want is to steer traffic to 1 or more SF's you could use TE tunnels and patch it all together with PBR or import/export tricks. 

Sent from my iPhone

> On Mar 14, 2014, at 2:59 PM, "Lucy yong" <[email-masked]> wrote:
> 
> Hi Maria,
>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Mar 2014 15:05:51 -0400

1. I completely agree.
2. How did the metadata thread devolve into a discussion of if the chain ID should or should not be mandatory?

From: [email-masked]<[email-masked]>
To: Surendra Kumar (smkumar)<[email-masked]>,Joel M. Halpern<[email-masked]>,NAPIERALA, MARIA H<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

   Ron

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

From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)Sent: Friday, March 14, 2014 1:46 PMTo: Joel M. Halpern; NAPIERALA, MARIA HCc: [email-masked]: 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 [email-masked]://www.ietf.org/mailman/listinfo/sfc_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Mar 2014 15:12:31 -0400

Maria,

Sure, but then why not just do that, then?  I assume that the method of service chaining to which you are referring has some limitations that you are expecting to overcome with SFC.  IMO, one of the benefits of SFC over other methods of implementing service chaining is having a mandatory chain ID field.  Sure, the chain ID could be carried in some other field of the IP packet, but I think that draft-boucadair-sfc-design-analysis (sect 6) does an excellent job of demonstrating why the SFC header is the better option.

Is there a better thread for discussing the merits of a Chain ID?

-MikeB

From: [email-masked]<[email-masked]>
To: Ron Parker<[email-masked]>,Surendra Kumar (smkumar)<[email-masked]>,Joel M. Halpern<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Maria

> -----Original Message-----
From: Ron Parker [mailto:[email-masked]]> Sent: Friday, March 14, 2014 2:28 PM> To: Surendra Kumar (smkumar); Joel M. Halpern; NAPIERALA, MARIA H> Cc: [email-masked]> Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations> > 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 [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Mar 2014 19:18:02 +0000

Hi Mike,
You make a very good observation; I would ask all members of the WG to *please* change the subject line of a thread if you wish to start a discussion on something other than the original subject of the thread.

Sent from my iPhone

On Mar 14, 2014, at 3:06 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

1. I completely agree.

________________________________
From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: Surendra Kumar (smkumar)<[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>,NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>
cc: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

  Ron

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

Cc: [email-masked]<mailto:[email-masked]>

Completely agree here.

Surendra.

On 3/14/14 10:26 AM, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>> wrote:

>> *To:* [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>[email-masked]<mailto:[email-masked]>
>> *Cc:* [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>[email-masked]<mailto:[email-masked]>
>> From: "Ken Gray (kegray)" <[email-masked]<mailto:[email-masked]>
>> To: Lucy yong <[email-masked]<mailto:[email-masked]>
>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,"Jim Guichard (jguichar)"
>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>> CC: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]>>,sfc <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]>>,Jamal Hadi Salim <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]>>,Ron Parker
>> <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]>>,"Joel M. Halpern" <[email-masked]<mailto:[email-masked]>
>> On 3/13/14 7:49 AM, "Lucy yong" <[email-masked]<mailto:[email-masked]>
>> >>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; sfc; Jamal
>>Hadi Salim
>> >>On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>
>> >>>> On Mar 12, 2014, at 4:16 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>
>> >>>> Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>> >>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>> >>>>>> (jguichar); [email-masked]<mailto:[email-masked]>
>> >>>>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>> >>>>>>>> Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>> >>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; sfc;
>> >>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>> >>>>>>>>>>> Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>
>> >>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>> >>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>> >>>>>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> Cc:
>> >>>>>>>>>>>>> sfc Subject: Re: [sfc]
>> >>>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> mailing list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >>>>>>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >>>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>list
>> >>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 14 Mar 2014 17:42:26 +0000

Complete agree here.

Surendra.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 17:52:35 +0000

My view is that unique and explicit chain identification will be difficult to manage and it is not needed to achieve service chaining.  I would rather deal with implicit service chain identification. Hence, I believe it should be made optional whether it is carried it in the sfc header.

Maria

> Sent: Friday, March 14, 2014 1:27 PM
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 14 Mar 2014 18:33:33 +0000

Wouldn't the id have to be an index into the current location ( Service Function ) that is processing the packet in the linked list that represents the service chain? This would allow for indexing into the chain based upon a required change based upon the type of flow.. 

Jim Uttaro

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Friday, March 14, 2014 2:28 PM
To: Surendra Kumar (smkumar); Joel M. Halpern; NAPIERALA, MARIA H
Cc: [email-masked]
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

   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

Completely agree here.

Surendra.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Mar 2014 19:22:00 +0000

Hi Jim,

Yes, and that is the stance taken by draft-quinn-sfc-nsh where the service
path ID + service index are used to determine which chain and where in the
chain the packet currently resides.

On 3/14/14, 2:33 PM, "UTTARO, JAMES" <[email-masked]> wrote:

>Wouldn't the id have to be an index into the current location ( Service
>Function ) that is processing the packet in the linked list that
>represents the service chain? This would allow for indexing into the
>chain based upon a required change based upon the type of flow..
>
>Jim Uttaro
>
>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
>
>

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 14 Mar 2014 19:22:00 +0000

Lucy,

Typically deployment is inline, if that is your question. 
However an intelligent traffic steering device can steer/stitch services that doesn't need to be inline. ADC devices has been doing that for years.
________________________________________
From: sfc [[email-masked]] on behalf of Lucy yong [[email-masked]]
Sent: Friday, March 14, 2014 11:58 AM
To: NAPIERALA, MARIA H
Cc: [email-masked]
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Hi Maria,

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Friday, March 14, 2014 1:39 PM
To: Ron Parker; Surendra Kumar (smkumar); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Maria

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 19:22:40 +0000

Joel,

> global chain ID is redundant.  

Yep.
>
>I can live with carrying it anyway
> either

I am OK with it as long as the chain ID can be set to "no-op" (i.e., NULL).

>   After all, some folks seem to want to use that for the forwarding

Yes, unfortunately..

> chain
> >>>   >>>function path. This context information may be consumed by a
> SF
> >>> (an
> >>>   >>>>> significant support for it in the working group.) [Lucy]
> This
> >>> is
> >>>   >>>>>> information data plane carried between service functions
> and
> >>> the
> >>>   >>>>>>> I agree that we need using the same definition for a
> term,
> >>> but
> >>>   >>>>>>> to a particular solution. I am fine with this definition
> in
> >>> the
> >>>   >>>>>>> functions, between service functions, and service
> functions
> >>> and
> >>>   >>>>>>> the
> >>>   >>>>>>> [mailto:[email-masked]] Sent: Wednesday,
> March
> >>> 12,
> >>>   >>>>>>>>metadata carried on packet for next service node to use.
> In
> >>> the
> >>>   >>>>>>>>functions and classifiers/service nodes, which is what
> the
> >>> draft
> >>>   >>>>>>>>focus.
> >>>   >>>>>>>>
> >>>   >>>>>>>> Thanks, Lucy
> >>>   >>>>>>>>
> >>>   >>>>>>>>
> >>>   >>>>>>>>
> >>>   >>>>>>>>
> >>>   >>>>>>>>
> >>>   >>>>>>>>> There are many cases where out-of-band metadata is
> useful
> >>> and
> >>>   >>>>>>>>>> the reaction time need not be immediate, few ms may
> not
> >>> matter.
> >>>   >>>>>>>>>>
> >>>   >>>>>>>>>> Finally we can still send some limited metadata within
> a
> >>> header.
> >>>   >>>>>>>>>> The alternative option, allowing variable sized
> metadata
> >>> in
> >>>   >>>>>>>>>> out-of-band metadata transport is not reliable. A
> packet
> >>> loss
> >>>   >>>>>>>>>> Can we guarantee that the metadata and real packet
> will
> >>> follow
> >>>   >>>>>>>>>>> example congruent out of band signaling defined in
> the
> >>> draft
> >>>   >>>>>>>>>>>
> >>>   >>>>>>>>>>> latter however does not incur any space limitation
> and
> >>> is
> >>>   >>>>>>>>>>> still fairly efficient and it remains compatible with
> a
> >>> fixed
> >>>   >>>>>>>>>>> majority of cases. Remember, the goal of being able
> to
> >>> pass
> >>>   >>>>>>>>>>>> I see similar requirements from the 3gpp EPC side.
> I
> >>> would
> >>>   >>>>>>>>>>>> that are optimized for long lived flows so as to
> limit
> >>> the
> >>>   >>>>>>>>>>>>> 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
> >>>   >>>>>>>>>>>>> no requirement but rather that we should not jump
> to
> >>> the
> >>>   >>>>>>>>>>>>>> For a datapath per-packet metadata, i feel the
> need
> >>> is

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 19:29:45 +0000

Mike,

It was discussed before, some months ago.
My point is that chain ID can be implicit (e.g., represented by an MPLS label).  We should have at least a no-op or NULL option for explicit chain ID.

Maria

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 14, 2014 3:13 PM
To: NAPIERALA, MARIA H; [email-masked]
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Maria,

-MikeB

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Ron Parker<[email-masked]<mailto:[email-masked]>>,Surendra Kumar (smkumar)<[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>
cc: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations

Maria

> >> From: "Ken Gray (kegray)" <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>
> >> To: Lucy yong <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>,"Surendra Kumar (smkumar)"
> >> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>,"Jim Guichard
> (jguichar)"
> >> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>,sfc <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>,Jamal Hadi Salim <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>,Ron Parker
> >> <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>,"[email-masked]
> >> <mailto:[email-masked]><mailto:[email-masked]%0b%3e%20%3e%3e%20%3cmailto:[email-masked]%3e>" <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>,"Joel M. Halpern"
> <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>>
> >> On 3/13/14 7:49 AM, "Lucy yong" <[email-masked]
<mailto:[email-masked]%0b>> >> <mailto:[email-masked]>> wrote:
> >> >>On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked]
<mailto:[email-masked]%0b>> >><mailto:[email-masked]>> wrote:
> >> >>>> On Mar 12, 2014, at 4:16 PM, "Lucy yong" <[email-masked]
<mailto:[email-masked]%0b>> >><mailto:[email-masked]>> wrote:
> >> >>>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
> wrote:
> >> >>>>>>>>>>>>>>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 19:42:12 +0000

Lucy, 

> We understand that SP can do service chaining today. One clarification:
> can you do it with constraints on where SFs to be place, i.e. MUST be
> on traffic path, or do it without such constraint today?
> 

Without being in-line.

Maria

> Well, we can do service chaining today without such explicit ID (and
> not based on VLAN stitching). So, it is possible.
> 
> 
> Maria
> 
> > >> Unless you would like to consider the chain identification as
> being
> > >> optional?
> > >>
> > >> Yours,
> > >>
> > >> Joel
> > >>
> > >>
> > >>
> > >>This is
> > >>and the
> > >>in the
> > >>In the
> > >>useful and
> > >>a header.
> > >>metadata in
> > >>packet loss
> > >>a fixed
> > >>limit the

---

From: Lucy yong <[email-masked]>
Date: Fri, 14 Mar 2014 19:45:07 +0000

Maria, What is the value you see in the SFC work in IETF?
Lucy

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Friday, March 14, 2014 2:42 PM
To: Lucy yong
Cc: [email-masked]
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Lucy, 

Without being in-line.

Maria

> > 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.
> >
> >
> >
> > >>*Jmh.direct
> > >>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.
> > >>
> > >>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
> > >>may
> > >>problem
> > >>is the
> > >>definitions
> > >>to a
> > >>cases when
> > >>service chains.
> > >>carrying some
> > >>metadata but
> > >>  >>>>>>>>>> This could be used for load balancers in particular 
> > >>if
> > we
> > >>  >>>>>>>>>>indicate that out of band metadata is expected, how 
> > >>can
> > we
> > >>  >>>>>>>>>>>>> The objective being to avoid having  the HTTP 
> > >> Proxy
> > to
> > >>  >>>>>>>>>>>>> [email-masked] 
> > >><mailto:[email-masked]>; [email-masked] <mailto:[email-masked]> Cc:
> > >>  >>>>>>>>>>>>> sfc Subject: Re: [sfc]
> > >>sfc mailing

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 14 Mar 2014 19:52:40 +0000

Lucy,

The value is the definition of the header that precedes the payload carrying metadata that a service appliance can use (such as subscriber-id, application-id).

Maria

> From: Lucy yong [mailto:[email-masked]]
> Sent: Friday, March 14, 2014 3:45 PM
> To: NAPIERALA, MARIA H
> Cc: [email-masked]
> Jamal
> > > >>  >>statement with text that adds little to no value in my
> opinion.
> > > >>Whether
> > > >>  >>>[Lucy] Do you call the context as metadata or not? Do we
> have
> > > >>another
> > > >>  >>>>chaining. In this context, there are two types of data
> plane
> > > >>metadata.
> > > >>  >>>>
> puts
> > > >>  >>>>>> between dataplane carried information intended for use
> by
> > > >>service
> > > >>  >>>>>>>> 11:18 AM To: Lucy yong; Nicolas BOUTHORS; Ron Parker
> Cc:
> > > >>Jim
> > > >>  >>>>>>>>> there are many different kinds of metatype.  Trying
> to
> > > say
> > > >>  >>>>>>>>>> Sending out of band congruent metadata may not be
> the
> > > >>answer
> > > >>  >>>>>>>>>>guarantee the order of reception? What if switching
> or
> > > >>routing
> implementation
> > > >>  >>>>>>>>>>>>> ________________________________________ From:
> Jim
> > > >>Guichard
> > > >>  >>>>>>>>>>>>> You said "It seems there's clear need for
> variable
> > > >>sized
> > > >>  >>>>>>>>>>>>>> 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: Fri, 14 Mar 2014 20:01:16 +0000

Maria,

I assume that you mean the header containing the metadata. So defining the metadata format, i.e. the header, is the value you see. The metadata can be optional for a SFC, right? How do you want their presence or not to be indicated when a service appliance receive a packet?

Thanks,
Lucy

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Friday, March 14, 2014 2:53 PM
To: Lucy yong
Cc: [email-masked]
Subject: RE: [sfc] draft-rijsman-sfc-metadata-considerations

Lucy,

Maria

> > can you do it with constraints on where SFs to be place, i.e. MUST 
> > be on traffic path, or do it without such constraint today?
> >
> 
> Without being in-line.
> 
> Maria
> 
> > > From: sfc [mailto:[email-masked]] On Behalf Of Surendra 
> > > Kumar
> > > (smkumar)
> > > >identification field is very useful, and low cost once we have 
> > > >the
> > > header.
> > > >
> > > >Yours,
> > > >Joel
> > > >
> > > >> *To:* [email-masked]; [email-masked]; 
> > > >>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.
> > > >>
> > > >>  >>>>classifier and service functions, between service 
> > > >>functions
> > to
> > > >>functions and the
> > > >>use whatever
> > > >>  >>>>>>>>states along with the packet. IMO: SFC header is a 
> > > >>kind
> > of
> > > >>transport adding
> > > >>  >>>>>>>>>>>>> sfc Subject: Re: [sfc]  >>>>>>>>>>>>>

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 14 Mar 2014 20:48:33 +0000

Maria,

>>Without being in-line.

The service may not be in-line but the steering device typically is.
Perhaps I misunderstood the context, can you provide an example?