Subject: [sfc] SFC encapsulation chain ID

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

Hi Joel,

Perhaps but I would point out that the base SFC header could have a lot
more information than just the chain ID; I would also point out that the
devil is in the details and saying “well, I can just use an MPLS label”
hides much of the complexity of actually doing that.

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

>If the transport header carries enough information for identifying the
>sequence (VLAN tag or MPLS label can both do the job), then arguably the
>global chain ID is redundant.  I can live with carrying it anyway either
>if I have metadata to carry, or if I need the chain ID for some purpose.
>  After all, some folks seem to want to use that for the forwarding
>decisions.
>
>Yours,
>Joel
>
>On 3/14/14, 2:28 PM, Ron Parker wrote:
>> The chain ID is the label that defines the sequence of service
>>functions that must be visited.   It can be thought of as a handle for a
>>stack of must-visit network locations.   I don't see how this can be
>>anything but mandatory.
>>
>>     Ron
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar
>>(smkumar)
>> Sent: Friday, March 14, 2014 1:46 PM
>> To: Joel M. Halpern; NAPIERALA, MARIA H
>> Cc: [email-masked]
>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>
>> [Trimmed the recipient list - needs approval otherwise]
>>
>> Completely agree here.
>>
>> SFC does not prevent VLAN stitching and one can continue to do that.
>>While at the same time SFC can include VLAN stitching to support legacy
>>SFs in the same chain that includes SFC aware SFs. Even legacy SFs
>>benefit from chain identification and hence can be shared across
>>different service chains.
>>
>> Surendra.
>>
>>
>>
>> On 3/14/14 10:26 AM, "Joel M. Halpern" <[email-masked]> wrote:
>>
>>> My own inclination is to observe that if you don't need explicit chain
>>> identification and you don't need metadata, you can just omit the
>>> sfc/nsh header.  Still do service chaining, just no extra header.
>>>
>>> If we are going to have the header, it seems to me that the chain
>>> identification field is very useful, and low cost once we have the
>>>header.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 3/14/14, 1:00 PM, NAPIERALA, MARIA H wrote:
>>>> Explicit chain identification should be made optional. I believe it
>>>> was discussed few months ago on this mailing list.
>>>>
>>>> Maria
>>>>
>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jmh.direct
>>>> *Sent:* Thursday, March 13, 2014 12:12 PM
>>>> *To:* [email-masked]; [email-masked]; [email-masked];
>>>> [email-masked]
>>>> *Cc:* [email-masked]; [email-masked]; [email-masked];
>>>> [email-masked]; [email-masked];
>>>> [email-masked]
>>>> *Subject:* Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>> *Importance:* Low
>>>>
>>>> Assuming I understand you properly Ken, I disagree.
>>>>
>>>> For example, by using separate terms I can easily discuss the fact
>>>> that  certain kinds of data (chain identification) only need to be
>>>> adjust by a  few apps in rare cases.  And that data is not beeded by
>>>> the applications.
>>>>
>>>> Unless you would like to consider the chain identification as being
>>>> optional?
>>>>
>>>> Yours,
>>>>
>>>> Joel
>>>>
>>>>
>>>>
>>>> Sent from my Samsung smartphone on AT&T
>>>>
>>>>
>>>>
>>>>
>>>> -------- Original message --------
>>>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>> From: "Ken Gray (kegray)" <[email-masked]
>>>> <mailto:[email-masked]>>
>>>> To: Lucy yong <[email-masked]
>>>> <mailto:[email-masked]>>,"Surendra Kumar (smkumar)"
>>>> <[email-masked] <mailto:[email-masked]>>,"Jim Guichard
>>>>(jguichar)"
>>>> <[email-masked] <mailto:[email-masked]>>
>>>> CC: Nicolas BOUTHORS <[email-masked]
>>>> <mailto:[email-masked]>>,sfc <[email-masked]
>>>> <mailto:[email-masked]>>,Jamal Hadi Salim <[email-masked]
>>>> <mailto:[email-masked]>>,Ron Parker
>>>> <[email-masked]
>>>> <mailto:[email-masked]>>,"[email-masked]
>>>> <mailto:[email-masked]>" <[email-masked]
>>>> <mailto:[email-masked]>>,"Joel M. Halpern" <[email-masked]
>>>> <mailto:[email-masked]>>
>>>>
>>>> The word "metadata" is a purposely ambiguous term "data that provides
>>>> information about other data".  It is used to avoid THIS discussion.
>>>>
>>>> For example, I propose we define "tequila metadata" because, frankly,
>>>> I  will need to order a triple-shot if we keep attempting to define
>>>> something  that, by definition, is ambiguous.  I'd like my bartender
>>>> to understand me  specifically when I say "I need a shot".
>>>>
>>>> On 3/13/14 7:49 AM, "Lucy yong" <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>   >Snip..
>>>>   >SK> Just copying from the PS:
>>>>   >--
>>>>   >Data plane metadata provides the ability to exchange information
>>>> between
>>>>   >the network and service functions, between service functions, and
>>>> service
>>>>   >functions and the network.
>>>>   >
>>>>   >--
>>>>   >It is a lucid definition. We are unnecessarily making the word
>>>> "network"
>>>>   >controversial, IMO.
>>>>   >
>>>>   >[Lucy] This is my point. "The network" is too general here, which
>>>> brings
>>>>   >metadata great power to do many things. This is why people invent
>>>> ideas
>>>>   >here, which causes a lot of debates on metadata usage potentials.
>>>> We
>>>>   >should not spend a lot of times on that debates and judge which
>>>> usage is
>>>>   >valuable or not. Thus, for the SFC work, it will be helpful if we
>>>> can
>>>>   >narrow down a bit. Joel makes explicitly two cases, which is
>>>> helpful to
>>>>   >develop use cases for each case. I would like to see that the
>>>> problem
>>>>   >statement can be more specific on metadata definition, which may be
>>>>   >helpful in less focusing on it and moving forward.
>>>>   >
>>>>   >Lucy
>>>>   >
>>>>   >Surendra.
>>>>   >
>>>>   >
>>>>   >>
>>>>   >>Thanks,
>>>>   >>Lucy
>>>>   >>
>>>>   >>-----Original Message-----
>>>>   >>From: Jim Guichard (jguichar) [mailto:[email-masked]]
>>>>   >>Sent: Wednesday, March 12, 2014 4:38 PM
>>>>   >>To: Lucy yong
>>>>   >>Cc: Joel M. Halpern; Nicolas BOUTHORS; Ron Parker;
>>>>   >>[email-masked] <mailto:[email-masked]>; sfc; Jamal
>>>> Hadi Salim
>>>>   >>Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>   >>
>>>>   >>Hi Lucy,
>>>>   >>
>>>>   >>No. I am simply saying we should not overcomplicate the problem
>>>>   >>statement with text that adds little to no value in my opinion.
>>>> Whether
>>>>   >>we call it metadata, or context, has no bearing on the fact that
>>>> the
>>>>   >>problem statement already clearly states we need to be able to
>>>> pass
>>>>   >>information between SF¹s and between the network & SF¹s.
>>>>   >>
>>>>   >>
>>>>   >>On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>   >>
>>>>   >>>
>>>>   >>>Hi Jim,
>>>>   >>>
>>>>   >>>I for one don't agree and think we are over complicating what
>>>> should
>>>>   >>>be straightforward. The SFC encapsulation should enable two
>>>>things:
>>>>   >>>
>>>>   >>>1. Steering of selected flows through a service chain; this is
>>>> the
>>>>   >>>service function path.
>>>>   >>>2. Passing of context associated with a given flow within said
>>>> service
>>>>   >>>function path. This context information may be consumed by a SF
>>>> (an
>>>>   >>>application ID is an example) or may be consumed by the
>>>> forwarding
>>>>   >>>elements (a vrf-ID is an example).
>>>>   >>>[Lucy] Do you call the context as metadata or not? Do we have
>>>> another
>>>>   >>>term here beside SFC header and metadata. I see that you don't
>>>> want to
>>>>   >>>separate what is consumed by SF and what is consumed by the
>>>> forwarding
>>>>   >>>elements.
>>>>   >>>
>>>>   >>>Lucy
>>>>   >>>
>>>>   >>>Sent from my iPhone
>>>>   >>>
>>>>   >>>> On Mar 12, 2014, at 4:16 PM, "Lucy yong" <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>   >>>>
>>>>   >>>> Great. Then we may consider two special metadata definitions in
>>>> the
>>>>   >>>>problem statement so we can all use the same definitions. Here
>>>> is my
>>>>   >>>>suggested text and like to hear you and other's input and
>>>> suggestions.
>>>>   >>>>
>>>>   >>>> Dataplane Metadata: Data plane metadata provides the ability to
>>>>   >>>>exchange information between the elements in a service function
>>>>   >>>>chaining. In this context, there are two types of data plane
>>>> metadata.
>>>>   >>>>
>>>>   >>>> Service Function Metadata: the information exchanged between
>>>>   >>>>classifier and service functions, between service functions to
>>>>   >>>>facilitate service functions on the packet treatment.
>>>>   >>>>
>>>>   >>>> Steering Metadata: the information from service functions to a
>>>>   >>>>classifier or service node for traffic forwarding purpose.
>>>>   >>>>
>>>>   >>>> -end
>>>>   >>>>
>>>>   >>>> Lucy
>>>>   >>>>
>>>>   >>>>
>>>>   >>>> -----Original Message-----
>>>>   >>>> From: Joel M. Halpern [mailto:[email-masked]]
>>>>   >>>> Sent: Wednesday, March 12, 2014 2:35 PM
>>>>   >>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker
>>>>   >>>> Cc: Jim Guichard (jguichar); [email-masked]
>>>> <mailto:[email-masked]>; sfc; Jamal Hadi
>>>>   >>>> Salim
>>>>   >>>> Subject: Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>   >>>>
>>>>   >>>> Yes, I am trying to consistently distinguish those two cases
>>>> when
>>>>   >>>>talking about the information carried with packets in service
>>>> chains.
>>>>   >>>>
>>>>   >>>> Yours,
>>>>   >>>> Joel
>>>>   >>>>
>>>>   >>>>> On 3/12/14, 3:13 PM, Lucy yong wrote:
>>>>   >>>>> Joel, See below. -----Original Message----- From: sfc
>>>>   >>>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>>>Sent:
>>>>   >>>>> Wednesday, March 12, 2014 2:02 PM To: Lucy yong; Nicolas
>>>> BOUTHORS;
>>>>   >>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]
>>>> <mailto:[email-masked]>; sfc;
>>>>   >>>>> Jamal Hadi Salim Subject: Re: [sfc]
>>>>   >>>>> draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>
>>>>   >>>>> I was trying to word it carefully not to focus on who puts the
>>>>   >>>>> information in, but only on who consumes the information.
>>>>   >>>>> Information for service functions may come from the ingress
>>>>   >>>>> classifier or from other service functions. [Lucy] this is the
>>>> one
>>>>   >>>>> case using metadata in your view. Information for the
>>>> forwarding
>>>>   >>>>> will generally come from the ingress classifier, but in
>>>> special
>>>>   >>>>> cases may be provided by service functions.  (I keep wanting
>>>> to get
>>>>   >>>>> rid of those special cases, but so far there seem to be just
>>>> enough
>>>>   >>>>> of them to warrant covering in the solution.  And more
>>>> importantly,
>>>>   >>>>> significant support for it in the working group.) [Lucy] This
>>>> is
>>>>   >>>>> the second case using metadata in your view (but you don't
>>>> like it).
>>>>   >>>>>
>>>>   >>>>> And you suggest distinguishing these two cases when discussing
>>>>   >>>>> about metadata usage. Is that right understanding?
>>>>   >>>>>
>>>>   >>>>> Lucy
>>>>   >>>>>
>>>>   >>>>> Yours, Joel
>>>>   >>>>>
>>>>   >>>>>> On 3/12/14, 2:33 PM, Lucy yong wrote:
>>>>   >>>>>> Joel, I interpret that you suggests that distinguish the
>>>> exchange
>>>>   >>>>>> information data plane carried between service functions and
>>>> the
>>>>   >>>>>> exchange information data plane carried from a service
>>>> function to
>>>>   >>>>>> a service node. Is this right understanding? Lucy
>>>>   >>>>>>
>>>>   >>>>>> -----Original Message----- From: Joel M. Halpern
>>>>   >>>>>> [mailto:[email-masked]] Sent: Wednesday, March 12, 2014
>>>> 1:19
>>>>   >>>>>> PM
>>>>   >>>>>> To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc: Jim Guichard
>>>>   >>>>>> (jguichar); [email-masked]
>>>> <mailto:[email-masked]>;  sfc; Jamal Hadi Salim Subject:
>>>>   >>>>>> Re: [sfc] draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>>
>>>>   >>>>>> My inclination would be to tune that definition to
>>>> distinguish
>>>>   >>>>>> between dataplane carried information intended for use by
>>>> service
>>>>   >>>>>> funcitons (whatever the origin), and dataplane carried
>>>> information
>>>>   >>>>>> intended for dataplane forwarding components.
>>>>   >>>>>>
>>>>   >>>>>> Yours, Joel
>>>>   >>>>>>
>>>>   >>>>>>
>>>>   >>>>>>> Hi Joel,
>>>>   >>>>>>>
>>>>   >>>>>>> I agree that we need using the same definition for a term,
>>>> but
>>>>   >>>>>>> disagree that the metadata definition here is a set of
>>>>   >>>>>>> information put in the SFC header. This may be too narrow or
>>>> lead
>>>>   >>>>>>> to a particular solution. I am fine with this definition in
>>>> the
>>>>   >>>>>>> problem statement w/ minor tweak (suggested on mailing
>>>>list).
>>>>   >>>>>>>
>>>>   >>>>>>> Dataplane Metadata: Data plane metadata provides the ability
>>>> to
>>>>   >>>>>>> exchange information between the classifiers and service
>>>>   >>>>>>> functions, between service functions, and service functions
>>>> and
>>>>   >>>>>>> the
>>>>   >>>>>>> classifiers|service nodes.
>>>>   >>>>>>>
>>>>   >>>>>>> There may be a solution that a service function passes some
>>>>
>>>>   >>>>>>> information to attached service node without using SFC
>>>>header.
>>>>   >>>>>>>
>>>>   >>>>>>> Thanks, Lucy
>>>>   >>>>>>>
>>>>   >>>>>>>
>>>>   >>>>>>> -----Original Message----- From: Joel Halpern Direct
>>>>   >>>>>>> [mailto:[email-masked]] Sent: Wednesday, March
>>>> 12,
>>>>   >>>>>>> 2014 12:25 PM To: Lucy yong; Joel M. Halpern; Nicolas
>>>> BOUTHORS;
>>>>   >>>>>>> Ron Parker Cc: Jim Guichard (jguichar); [email-masked]
>>>> <mailto:[email-masked]>;
>>>>   >>>>>>> sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>>>   >>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>>>
>>>>   >>>>>>> Lucy, you say "the metadata term means ..."  The definition
>>>> you
>>>>   >>>>>>> then provide is a definition of the set of information we
>>>> are
>>>>   >>>>>>> proposing that we put in the SFC header.  I, and others,
>>>> have
>>>>   >>>>>>> been using the term metadata more narrowly.  We can use
>>>> whatever
>>>>   >>>>>>> definition we want. But we do need to agree on the
>>>>definition.
>>>>   >>>>>>> For the purposes of the WG, it seems much more useful to use
>>>> the
>>>>   >>>>>>> term metadata for the narrower description.
>>>>   >>>>>>>
>>>>   >>>>>>> Yours, Joel
>>>>   >>>>>>>
>>>>   >>>>>>>> On 3/12/14, 1:19 PM, Lucy yong wrote:
>>>>   >>>>>>>> Hi Joel,
>>>>   >>>>>>>>
>>>>   >>>>>>>> I agree. We need to differentiate the metadata used by
>>>> service
>>>>   >>>>>>>>function and SFC header. The metadata term means carrying
>>>> some
>>>>   >>>>>>>>states along with the packet. IMO: SFC header is a kind of
>>>>   >>>>>>>>metadata carried on packet for next service node to use. In
>>>> the
>>>>   >>>>>>>>context of SFC, we have term for SFC header and the metadata
>>>> that
>>>>   >>>>>>>>was carried between service functions, or between service
>>>>   >>>>>>>>functions and classifiers/service nodes, which is what the
>>>> draft
>>>>   >>>>>>>>focus.
>>>>   >>>>>>>>
>>>>   >>>>>>>> Thanks, Lucy
>>>>   >>>>>>>>
>>>>   >>>>>>>>
>>>>   >>>>>>>>
>>>>   >>>>>>>>
>>>>   >>>>>>>>
>>>>   >>>>>>>> -----Original Message----- From: Joel M. Halpern
>>>>   >>>>>>>> [mailto:[email-masked]] Sent: Wednesday, March 12,
>>>> 2014
>>>>   >>>>>>>> 11:18 AM To: Lucy yong; Nicolas BOUTHORS; Ron Parker Cc:
>>>> Jim
>>>>   >>>>>>>> Guichard (jguichar); [email-masked]
>>>> <mailto:[email-masked]>; sfc; Jamal Hadi Salim
>>>>   >>>>>>>> Subject: Re: [sfc]
>>>> draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>>>>
>>>>   >>>>>>>> I think it is important to keep a strong distinction
>>>> between
>>>>   >>>>>>>> metadata (which is for use by applications) and the service
>>>>   >>>>>>>> chaining information in the base service chain header,
>>>> which is
>>>>   >>>>>>>> for use by the service chain support mechanisms.
>>>>   >>>>>>>>
>>>>   >>>>>>>> Yours, Joel
>>>>   >>>>>>>>
>>>>   >>>>>>>>> On 3/12/14, 10:42 AM, Lucy yong wrote:
>>>>   >>>>>>>>> Fully agree with Joe.
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> We should not require a fix length for in-band metadata
>>>> but
>>>>   >>>>>>>>> also not leave it for freely usage. In fact, when a
>>>> service
>>>>   >>>>>>>>> node inserts SFC header on a (encapsulated) packet and
>>>> send to
>>>>   >>>>>>>>> next service node, SFC header itself can be seen as a
>>>> metadata.
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> Lucy
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> -----Original Message----- From: sfc
>>>>   >>>>>>>>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>>>   >>>>>>>>> Sent: Wednesday, March 12, 2014 9:21 AM To: Nicolas
>>>> BOUTHORS;
>>>>   >>>>>>>>> Ron Parker Cc: Jim Guichard (jguichar);
>>>> [email-masked]  <mailto:[email-masked]>;
>>>>   >>>>>>>>> sfc; Jamal Hadi Salim Subject: Re: [sfc]
>>>>   >>>>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> For in-band metadata, the API for access can easily be
>>>>   >>>>>>>>> synchronous. Out of band metadata needs different
>>>>handling.
>>>>   >>>>>>>>> There are many cases where out-of-band metadata is useful
>>>> and
>>>>   >>>>>>>>> appropriate.  But they do not cover all needs by any
>>>>stretch.
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> Even if each piece of in-band metadata is of fixed length,
>>>>   >>>>>>>>> there are many different kinds of metatype.  Trying to say
>>>>   >>>>>>>>> "there will be exactly four pieces, and they will be of
>>>> types
>>>>   >>>>>>>>> t1, t2, t3, and t4" is simply too specific for even 80% of
>>>> the
>>>>   >>>>>>>>>needs.
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> Yours, Joel
>>>>   >>>>>>>>>
>>>>   >>>>>>>>>> On 3/12/14, 8:52 AM, Nicolas BOUTHORS wrote:
>>>>   >>>>>>>>>> Hello Ron,
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Sending out of band congruent metadata may not be the
>>>> answer
>>>>   >>>>>>>>>> to all needs but it is one tool that we should keep.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Not all metadata is tied to a specific packet, for
>>>> example a
>>>>   >>>>>>>>>> policy change in PCRF could lead to some metadata
>>>> signaling,
>>>>   >>>>>>>>>> the reaction time need not be immediate, few ms may not
>>>> matter.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> As you point, if a packet is tied to a metadata a
>>>> correlation
>>>>   >>>>>>>>>> info can be set in both packet to deal with it (i.e
>>>> metadata
>>>>   >>>>>>>>>> expected flag in the SFC header, plus an id)
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Finally we can still send some limited metadata within a
>>>> header.
>>>>   >>>>>>>>>> This could be used for load balancers in particular if we
>>>>   >>>>>>>>>> agree on a convention to locate "coarse grain policy"
>>>>   >>>>>>>>>> / "fine grain policy" on reserved context headers.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> This seems to open up a lot of flexibility / innovations.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> On your last point, there is a question on how to make
>>>>   >>>>>>>>>> metadata available to a Service Function. Current socket
>>>>   >>>>>>>>>> connections for example do not allow to retrieve IP
>>>> header
>>>>   >>>>>>>>>> options. So I assume that SFC aware Service Functions
>>>> will
>>>>   >>>>>>>>>> need some (asynchronous
>>>>   >>>>>>>>>> ?) API to retrieve SFC header information as well as
>>>> in-band
>>>>   >>>>>>>>>> metadata. I don't see out of band metadata transport
>>>> adding
>>>>   >>>>>>>>>> complexity,  the same API can probably apply.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> The alternative option, allowing variable sized metadata
>>>> in
>>>>   >>>>>>>>>> the SFC header has some drawbacks as well, one being
>>>>   >>>>>>>>>> fragmentation, and some switches expecting as well to
>>>> look at
>>>>   >>>>>>>>>> end user traffic headers for link load balancing.  I
>>>> would
>>>>   >>>>>>>>>> agree that if we can accept these issues, then sending
>>>>   >>>>>>>>>> off-line congruent metadata looses its interest.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> We need to take into account  that both in-band and
>>>> congruent
>>>>   >>>>>>>>>> out-of-band metadata transport is not reliable. A packet
>>>> loss
>>>>   >>>>>>>>>> triggering retransmission would not lead to the identical
>>>>   >>>>>>>>>> reconstruction of the associated metadata. In some cases,
>>>> we
>>>>   >>>>>>>>>> might thus even need non-congruent out-of-band reliable
>>>>   >>>>>>>>>> metadata transport.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Nicolas ________________________________________ From:
>>>> Ron
>>>>   >>>>>>>>>> Parker [[email-masked]] Sent: Wednesday,
>>>>   >>>>>>>>>> March 12, 2014
>>>>   >>>>>>>>>> 12:43 PM To: Nicolas BOUTHORS Cc: Jim Guichard
>>>> (jguichar);
>>>>   >>>>>>>>>> [email-masked] <mailto:[email-masked]>; sfc;
>>>> Jamal Hadi Salim Subject: Re: [sfc]
>>>>   >>>>>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Nicolas,
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> I understand the concept for out of band signaling of
>>>>   >>>>>>>>>>metadata, but I am concerned that it introduces
>>>> significant
>>>>   >>>>>>>>>>complexity due to the potential race condition of
>>>> receiving the
>>>>   >>>>>>>>>>real packet before the metadata.  While the real packet
>>>> could
>>>>   >>>>>>>>>>indicate that out of band metadata is expected, how can we
>>>>   >>>>>>>>>>guarantee the order of reception? What if switching or
>>>> routing
>>>>   >>>>>>>>>>nodes apply hash based load balancing? What if the load
>>>>   >>>>>>>>>>balancing understands SFC encaps and looks beyond it to
>>>> the
>>>>   >>>>>>>>>>original header to get better entropy?
>>>>   >>>>>>>>>> Can we guarantee that the metadata and real packet will
>>>> follow
>>>>   >>>>>>>>>>the exact same path? If we can not, then implementations
>>>> will
>>>>   >>>>>>>>>>need to add ingress queuing to cope with the scenario.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Also, do you feel that the increase in implementation
>>>>   >>>>>>>>>> complexity at the service functions is reasonable?
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Thanks.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> Ron
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>>> On Mar 12, 2014, at 4:09 AM, "Nicolas BOUTHORS"
>>>>   >>>>>>>>>>> <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> I think we must make a distinction between:
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> - Metadata which should be part of the header defined as
>>>> in
>>>>   >>>>>>>>>>> band marking. - Metadata with can be passed out of band,
>>>> for
>>>>   >>>>>>>>>>> example congruent out of band signaling defined in the
>>>> draft
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> The former calls for a limited space in the header,
>>>> true, The
>>>>   >>>>>>>>>>> latter however does not incur any space limitation and
>>>> is
>>>>   >>>>>>>>>>> still fairly efficient and it remains compatible with a
>>>> fixed
>>>>   >>>>>>>>>>> size header used to route those signaling messages along
>>>> the
>>>>   >>>>>>>>>>> chain's service functions.
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> Nicolas ________________________________________ From:
>>>>   >>>>>>>>>>> Jim Guichard (jguichar) [[email-masked]] Sent:
>>>>   >>>>>>>>>>> Tuesday, March 11, 2014 6:48 PM To: Ron Parker Cc:
>>>>   >>>>>>>>>>> Nicolas BOUTHORS; [email-masked]
>>>> <mailto:[email-masked]>; sfc; Jamal Hadi Salim
>>>>   >>>>>>>>>>> Subject: Re: [sfc]
>>>> draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> Hi Ron,
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> We can certainly have this discussion but we should
>>>> first
>>>>   >>>>>>>>>>> consider what information is necessary and if said
>>>>   >>>>>>>>>>> information can fit within a fixed number of contexts in
>>>> the
>>>>   >>>>>>>>>>> majority of cases. Remember, the goal of being able to
>>>> pass
>>>>   >>>>>>>>>>> metadata through the network is to enhance service
>>>> delivery,
>>>>   >>>>>>>>>>> not pass the entire works of Shakespeare ;-)
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> Sent from my iPhone
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>>> On Mar 7, 2014, at 3:52 AM, "Ron Parker"
>>>>   >>>>>>>>>>>> <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>   >>>>>>>>>>>>
>>>>   >>>>>>>>>>>> Nicolas,
>>>>   >>>>>>>>>>>>
>>>>   >>>>>>>>>>>> I see similar requirements from the 3gpp EPC side.  I
>>>> would
>>>>   >>>>>>>>>>>> like to propose an OUI / TLV based approach where the
>>>>   >>>>>>>>>>>> reserved OUI can be used for agreed upon types of
>>>> common
>>>>   >>>>>>>>>>>> metadata and vendor or other organizational OUIs can be
>>>> used
>>>>   >>>>>>>>>>>> to quickly innovate in the networks.
>>>>   >>>>>>>>>>>> Simultaneously, I would also like to consider
>>>> mechanisms
>>>>   >>>>>>>>>>>> that are optimized for long lived flows so as to limit
>>>> the
>>>>   >>>>>>>>>>>> negative effects of packet growth.
>>>>   >>>>>>>>>>>>
>>>>   >>>>>>>>>>>> Ron
>>>>   >>>>>>>>>>>>
>>>>   >>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> On Mar 7, 2014, at 8:34 AM, "Nicolas BOUTHORS"
>>>>   >>>>>>>>>>>>> <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> Hello Jim
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> I have seen cases in Gi LAN, where subscriber related
>>>>   >>>>>>>>>>>>> information is passed to a Web Proxy for HTTP header
>>>>   >>>>>>>>>>>>> enrichment (aimed at some Web Content providers
>>>> partners of
>>>>   >>>>>>>>>>>>> the Mobile Operator).
>>>>   >>>>>>>>>>>>> Information was an coded (persistent) subscriber id
>>>> derived
>>>>   >>>>>>>>>>>>> from the MSISDN, and couple of f customer profile
>>>> related
>>>>   >>>>>>>>>>>>> fields.
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> In an sfc based Gi LAN, this entity should receive
>>> >from the
>>>>   >>>>>>>>>>>>> Classifier
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> - A classification of the Content Provider ( Id,
>>>>   >>>>>>>>>>>>> Category) based on traffic analysis - The MSISDN of
>>>> the
>>>>   >>>>>>>>>>>>> subscriber - Two subscriber policy fields (not tied to
>>>> PCRF
>>>>   >>>>>>>>>>>>> but belonging to the Subscriber DB) (Subscriber
>>>> category,
>>>>   >>>>>>>>>>>>> sub-category) - A session id (for logging and tracking
>>>>   >>>>>>>>>>>>> purposes)
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> The objective being to avoid having  the HTTP Proxy to
>>>>   >>>>>>>>>>>>> become a trusted application (interogate the
>>>> subscriber DB,
>>>>   >>>>>>>>>>>>> etc..)
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> Nicolas
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> ________________________________________ From: Jim
>>>> Guichard
>>>>   >>>>>>>>>>>>> (jguichar) [[email-masked]] Sent:
>>>>   >>>>>>>>>>>>> Thursday, March 06, 2014 2:02 PM To: Jamal Hadi Salim;
>>>>   >>>>>>>>>>>>> [email-masked] <mailto:[email-masked]>;
>>>> [email-masked] <mailto:[email-masked]> Cc:
>>>>   >>>>>>>>>>>>> sfc Subject: Re: [sfc]
>>>>   >>>>>>>>>>>>> draft-rijsman-sfc-metadata-considerations
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> Hi Jamal,
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> You said "It seems there's clear need for variable
>>>> sized
>>>>   >>>>>>>>>>>>> metadata".. I am not so convinced and would like to
>>>> better
>>>>   >>>>>>>>>>>>> understand the requirements before passing judgement.
>>>> If we
>>>>   >>>>>>>>>>>>> look at the use cases as presented thus far into the
>>>> WG I
>>>>   >>>>>>>>>>>>> have yet to see a single example of the need (noting
>>>> that
>>>>   >>>>>>>>>>>>> desire is not the same as need) - I am not saying
>>>> there is
>>>>   >>>>>>>>>>>>> no requirement but rather that we should not jump to
>>>> the
>>>>   >>>>>>>>>>>>> conclusion and build standards around a theory.
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>> On 3/3/14, 6:35 AM, "Jamal Hadi Salim"
>>>>   >>>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>   >>>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>> I like the doc - well written.
>>>>   >>>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>> Section 4.3 on metadata encoding.
>>>>   >>>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>> It seems there's clear need for variable sized
>>>> metadata
>>>>   >>>>>>>>>>>>>> (at least for http/app you  seem to indicate the
>>>> desire for
>>>>   >>>>>>>>>>>>>>it).
>>>>   >>>>>>>>>>>>>> For a datapath per-packet metadata, i feel the need
>>>> is
>>>>   >>>>>>>>>>>>>> just as important. Are we limited by the fact that
>>>>   >>>>>>>>>>>>>> existing hardware may not be able to handle TLVs? For
>>>>   >>>>>>>>>>>>>> example, I dont have a problem handling TLVs in a
>>>> software
>>>>   >>>>>>>>>>>>>>datapath.
>>>>   >>>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>> cheers, jamal
>>>>   >>>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>> _______________________________________________ sfc
>>>>   >>>>>>>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>   >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>>
>>>>   >>>>>>>>>>>>> _______________________________________________ sfc
>>>> mailing
>>>>   >>>>>>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> _______________________________________________ sfc
>>>> mailing
>>>>   >>>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> _______________________________________________ sfc
>>>> mailing
>>>>   >>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> _______________________________________________ sfc
>>>> mailing
>>>>   >>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>   >>>>>
>>>>   >>>>> _______________________________________________ sfc mailing
>>>> list
>>>>   >>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>   >>>>>
>>>>   >>
>>>>   >>_______________________________________________
>>>>   >>sfc mailing list
>>>>   >>[email-masked] <mailto:[email-masked]>
>>>>   >>https://www.ietf.org/mailman/listinfo/sfc
>>>>   >
>>>>   >_______________________________________________
>>>>   >sfc mailing list
>>>>   >[email-masked] <mailto:[email-masked]>
>>>>   >https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sfc
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Fri, 14 Mar 2014 19:55:09 +0000

Thanks, Jim.

Remember that we have said many times that the SFC service header is transport independent.   Just because the chain id could be carried in some form or another with some particular transport doesn't mean that it could be universally conveyed.    By making and keeping the SFC service header transport independent makes it more applicable in more environments and more likely to get adopted broadly.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Friday, March 14, 2014 3:52 PM
To: Joel M. Halpern; Ron Parker
Cc: [email-masked]
Subject: SFC encapsulation chain ID

Hi Joel,

Perhaps but I would point out that the base SFC header could have a lot more information than just the chain ID; I would also point out that the devil is in the details and saying "well, I can just use an MPLS label"
hides much of the complexity of actually doing that.

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

>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.
>>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 
>>> 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.
>>>
>>>> adjust by a  few apps in rare cases.  And that data is not beeded 
>>>> by the applications.
>>>>
>>>><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".
>>>>
>>>>   >the network and service functions, between service functions, 
>>>>and  service
>>>>   >[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
>>>>   >valuable or not. Thus, for the SFC work, it will be helpful if 
>>>>we  can
>>>>   >>we call it metadata, or context, has no bearing on the fact 
>>>>that  the
>>>>   >>>function path. This context information may be consumed by a 
>>>>SF  (an
>>>>   >>>> 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
>>>>   >>>>> classifier or from other service functions. [Lucy] this is 
>>>>the  one
>>>>   >>>>> 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
>>>>   >>>>> 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
>>>>   >>>>>>> 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
>>>>   >>>>>>> functions, between service functions, and service 
>>>>functions  and
>>>>   >>>>>>> the
>>>>   >>>>>>> [mailto:[email-masked]] Sent: Wednesday, 
>>>>March  12,
>>>>   >>>>>>> Lucy, you say "the metadata term means ..."  The 
>>>>definition  you
>>>>   >>>>>>> For the purposes of the WG, it seems much more useful to 
>>>>use  the
>>>>   >>>>>>>>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
>>>>   >>>>>>>>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
>>>>   >>>>>>>>> t1, t2, t3, and t4" is simply too specific for even 80% 
>>>>of  the
>>>>   >>>>>>>>>needs.
>>>>   >>>>>>>>>
>>>>   >>>>>>>>> Yours, Joel
>>>>   >>>>>>>>>
>>>>   >>>>>>>>>> the reaction time need not be immediate, few ms may 
>>>>not  matter.
>>>>   >>>>>>>>>>
>>>>   >>>>>>>>>> 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
>>>>   >>>>>>>>>> reconstruction of the associated metadata. In some 
>>>>cases,  we
>>>>   >>>>>>>>>> Can we guarantee that the metadata and real packet 
>>>>will  follow
>>>>   >>>>>>>>>>the exact same path? If we can not, then 
>>>>implementations  will
>>>>   >>>>>>>>>>> - Metadata which should be part of the header defined 
>>>>as  in
>>>>   >>>>>>>>>>> band marking. - Metadata with can be passed out of 
>>>>band,  for
>>>>   >>>>>>>>>>> example congruent out of band signaling defined in 
>>>>the  draft
>>>>   >>>>>>>>>>>
>>>>   >>>>>>>>>>> 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
>>>>   >>>>>>>>>>> information can fit within a fixed number of contexts 
>>>>in  the
>>>>   >>>>>>>>>>> majority of cases. Remember, the goal of being able 
>>>>to  pass
>>>>   >>>>>>>>>>>> I see similar requirements from the 3gpp EPC side.  
>>>>I  would
>>>>   >>>>>>>>>>>> metadata and vendor or other organizational OUIs can 
>>>>be  used
>>>>   >>>>>>>>>>>> that are optimized for long lived flows so as to 
>>>>limit  the
>>>>   >>>>>>>>>>>>> subscriber - Two subscriber policy fields (not tied 
>>>> to PCRF
>>>>   >>>>>>>>>>>>> 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: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Mar 2014 21:11:46 +0000

Yes that is certainly my opinion.

Sent from my iPhone

> On Mar 14, 2014, at 3:55 PM, "Ron Parker" <[email-masked]> wrote:
> 
> Thanks, Jim.
>