Subject: Re: [sfc] SFC encapsulation chain ID

From: "Ken Gray (kegray)" <[email-masked]>
Date: Fri, 14 Mar 2014 21:17:46 +0000

+1 the idea is interoperability.

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

>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:
>
>>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
>
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Mar 2014 17:50:14 -0400

I would imagine that if we made the Chain ID field in the header be optional, yet still required a header and still required that some indication of the chain be carried somewhere in the packet (mpls label or vlan or whatever), that the implementation would become overly complicated.  To do so would be using SFC simply as a mechanism to carry meta data and not at all for service chaining, which sounds counter intuitive to me. 

Maria, 
So, you are saying that you want to use SFC to carry around metadata, but not for actual service chaining because you already have a way to implement service chaining outside of SFC?  Maybe I'm not following, but it seems to me that if you were to upgrade your network to support SFC that you would change from using your existing mechanism and start using SFC, which is meant to provide support for service functions that are not SFC aware.  There are a number of us who have implemented, in one way or another, some sort of service chaining, but I (I can at least speak for myself) am looking to SFC not to enhance my current implementation, but to replace it with something better while still maintaining my core (non service function) infrastructure.

From: [email-masked]<[email-masked]>
To: Ron Parker<[email-masked]>,Jim Guichard (jguichar)<[email-masked]>,Joel M. Halpern<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

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

>>>>> *To:* [email-masked]; [email-masked]; [email-masked]
;>>>>> [email-masked]
>>>>> *Cc:* [email-masked]; [email-masked]; [email-masked]
;>>>>> [email-masked]; [email-masked]
;>>>>> [email-masked]
>>>>>   >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]
>>>>>   >>
>>>>>   >>>
>>>>>   >>>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"
>>>>>   >>>>
>>>>>   >>>> 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]
>>>>>   >>>> 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]
>>>>>   >>>>>> 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]
>>>>>   >>>>>>>> Subject: Re: [sfc]
>>>>>   >>>>>>>>
>>>>>   >>>>>>>> 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]
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> 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]
>>>>>   >>>>>>>>>>> Subject: Re: [sfc]
>>>>>   >>>>>>>>>>>
>>>>>   >>>>>>>>>>> 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]
>>>>>   >>>>>>>>>>>>
>>>>>   >>>>>>>>>>>> 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]
>>>>>   >>>>>>>>>>>>>
>>>>>   >>>>>>>>>>>>> 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]>
>>>>>   >>>>>>>>>>
>>>>>   >>>>>>>>>> _______________________________________________ sfc
>>>>> mailing
>>>>>   >>>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> _______________________________________________ sfc
>>>>> mailing
>>>>>   >>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>   >>>>>>>>>
>>>>>   >>>>>>>>> _______________________________________________ sfc
>>>>> mailing
>>>>>   >>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>   >>>>>
>>>>>   >>>>> _______________________________________________ sfc mailing
>>>>> list
>>>>>   >>>>> [email-masked] <mailto:[email-masked]>
>>>>>   >>>>>
>>>>>   >>
>>>>>   >>_______________________________________________
>>>>>   >>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
>>>>>
>>>>

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 17 Mar 2014 17:03:08 +0000

This (lengthy and very lively) thread started from draft-rijsman-sfc-metadata-considerations (which I co-authored).

In section 4.8, we made a clear distinction between a service path layer (steering packets hop by hop along the chain) and a service function layer (convey metadata information of interest to SFs). Terminology aside, it seems that such layered view was agreed upon by many people on the mailing list.

Now this certainly does beg the question of solving BOTH problems with the same (packet) encapsulation mechanism. Notably when observing that many use cases could be satisfied without SF-level metadata, or by using more out-of-band ways to convey such SF metadata. And also when observing that inband marking (e.g. packet headers) comes with various pros & cons (some of the issues being identified in the draft, e.g. sections 4.1 and 4.2).

I do agree with Maria. We may want to explore other options for addressing the needs of the service path layer that do not require an explicit chain-id of sorts.

In the draft, we concluded by stating “A productive path forward could be to divide and conquer: to clearly separate the problem of Service Function Path topology from the   problem of [conveying SF] metadata”. I do believe we should explore such separation principle further.

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 14, 2014 5:50 PM
To: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Maria,
So, you are saying that you want to use SFC to carry around metadata, but not for actual service chaining because you already have a way to implement service chaining outside of SFC?  Maybe I'm not following, but it seems to me that if you were to upgrade your network to support SFC that you would change from using your existing mechanism and start using SFC, which is meant to provide support for service functions that are not SFC aware.  There are a number of us who have implemented, in one way or another, some sort of service chaining, but I (I can at least speak for myself) am looking to SFC not to enhance my current implementation, but to replace it with something better while still maintaining my core (non service function) infrastructure.
________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Ron Parker<[email-masked]<mailto:[email-masked]>>,Jim Guichard (jguichar)<[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] SFC encapsulation chain ID

On 3/14/14 12:55 PM, "Ron Parker" <[email-masked]<mailto:[email-masked]>> wrote:

>Cc: [email-masked]<mailto:[email-masked]>
>On 3/14/14, 2:35 PM, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>> Cc: [email-masked]<mailto:[email-masked]>
>>> 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]>
>>>>><mailto:[email-masked]>>,"Surendra<mailto:[email-masked]%3e%3e,%22Surendra> Kumar (smkumar)"
>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,"Jim<mailto:[email-masked]%3e%3e,%22Jim> Guichard
>>>>>(jguichar)"
>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>>>>> CC: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,sfc<mailto:[email-masked]%3e%3e,sfc> <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,Jamal<mailto:[email-masked]%3e%3e,Jamal> Hadi Salim <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,Ron<mailto:[email-masked]%3e%3e,Ron> Parker
>>>>><[email-masked]<mailto:[email-masked]>
>>>>> <mailto:[email-masked]>>,"[email-masked]<mailto:[email-masked]%3e%3e,[email-masked]>
>>>>> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
>>>>><mailto:[email-masked]>>,"Joel<mailto:[email-masked]%3e%3e,%22Joel> M. Halpern"
>>>>><[email-masked]<mailto:[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]>
>>>>><[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>   >>>>
>>>>>   >>>> Cc: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>>>>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; sfc;
>>>>>   >>>>>> (jguichar); [email-masked]<mailto:[email-masked]>
>>>>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>>>>   >>>>>>>> Guichard (jguichar); [email-masked]<mailto:[email-masked]>
>>>>>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>>>>   >>>>>>>>>> Parker [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>Wednesday,
>>>>>   >>>>>>>>>> March 12, 2014
>>>>>   >>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
>>>>>   >>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>>>>>   >>>>>>>>>>> Jim Guichard (jguichar) [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>   >>>>>>>>>>> Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>
>>>>>   >>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>>>>>   >>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>
>>>>>   >>>>>>>>>>>>> (jguichar) [[email-masked]<mailto:[email-masked]>] Sent:
>>>>>   >>>>>>>>>>>>> [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]>
>>>>>   >>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>>   >>[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>>>>>   >[email-masked]<mailto:[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]>

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

---

From: Ron Parker <[email-masked]>
Date: Mon, 17 Mar 2014 17:37:26 +0000

Jerome,

I understand the rationale for what you suggest, but I still remain firmly convinced that having a single encapsulation and a single set of procedures to operate the service function forwarder is preferable to having to describe unique approaches for multiple transport options, especially when some require “help” and others don’t.     In my mind, the cost of adopting the “any transport” approach is to specify a transport-independent means to achieve service function forwarding.    Of course the tradeoff is to pick a single suitable transport and exploit its capabilities fully, but there seems little appetite to do that at this point.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Jerome Moisand
Sent: Monday, March 17, 2014 1:03 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, March 14, 2014 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC encapsulation chain ID

Maria,

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 17 Mar 2014 19:04:41 +0000

Jerome,

On Mar 17, 2014, at 1:03 PM, Jerome Moisand <[email-masked]<mailto:[email-masked]>> wrote:

We need to further distinguish between path identification and actual carrying the packets.  I don't think anyone on this list -- and certainly not me -- is advocating that the actual transport information be contained in the SFC encap.

However, identifying a service path -- draft-quinn-nsh provides on example of such -- in the SFC encap is an important decision that has implications both on the functionality that can be supported on the chain, as well as preserving some key attributes identified in the problem statement, most notably true transport independence.

The SFC architecture distinguished the service path from the actual network path selection.  This de-coupling is important: i) it allows services to alter service path information without having to be aware of the transport information, ii) lets the network nodes perform path selection using whatever metrics and features that are locally available, iii) ensure that the services do not need to become aware of a range of transports and control plane (essentially making them routers).

We need to keep the architectural goals in mind, and ensure that exploration remains strongly pragmatic.

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, March 14, 2014 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC encapsulation chain ID

Maria,

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 18 Mar 2014 04:04:30 +0000

I like the idea of separating the Service Function Layer and the Service Path Layer, as proposed in draft-rijsman-sfc-metadata-considerations. The role of the Service Path Layer is just to steer the traffic along a particular chain of service nodes which can be implemented by existing tools for source routing, such as segment routing. As such, it’s not necessary to try to keep the Service Path Layer transport-independent and contain it in the SFC header.

Best regards,
Xiaohu

发件人: sfc [mailto:[email-masked]] 代表 Jerome Moisand
发送时间: 2014年3月18日 1:03
收件人: [email-masked]; [email-masked]
主题: Re: [sfc] SFC encapsulation chain ID

Maria,

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Tue, 18 Mar 2014 08:53:43 +0000

I think that keeping the Service Path Layer transport independent should remain an objective for SFC.  Such a separation of concerns is a sound architectural principle that help keep things simple in practice.

On the question of  Service Path, we have a discussion on whether we need some kind of explicit identifier or
could we rely on mapping on some underlay network protocol fields.

May be a PRO/CON table could help focus the group decision on that matter

  *   Visibility (tracing)
  *   Forwarding graph structure impact/limitations
  *   Reconfiguration speed
     *   LBS / scale out impact
     *   Node bypass (e.g; maintenance)
  *   underlay network/transport layers support
  *   Header space impact
  *   Multi tenant support impact
  *   SFC on flat (e.g optical L2 for Data Centers) network
  *   Underlay network administration impact

Personally I think that having an explicit chain identifier (e.g. Service Path/Service Index) is clear (management and control) and not expensive (header space). The drawback being some impact on the simplicity to add/remove elements in a chain dynamically.

Tag switching (as MPLS)  allows to manage tags per service nodes, leading to more versatile and diverse graphs

Nicolas
________________________________
From: Xuxiaohu [[email-masked]]
Sent: Tuesday, March 18, 2014 5:04 AM
To: Jerome Moisand; [email-masked]; [email-masked]
Subject: [sfc] 答复: SFC encapsulation chain ID

Best regards,
Xiaohu

Maria,

---

From: Changcheng Huang <[email-masked]>
Date: Tue, 18 Mar 2014 07:43:23 -0700

Good points. I believe explicit chain ID should be mandatory. The overhead is very little. It helps simplify processing and steering significantly. The gain is huge.

Chang

------------
Changcheng Huang

> On Mar 18, 2014, at 1:53 AM, Nicolas BOUTHORS <[email-masked]> wrote:
> 
> Visibility (tracing)
> Forwarding graph structure impact/limitations
> Reconfiguration speed 
> LBS / scale out impact
> Node bypass (e.g; maintenance)
> underlay network/transport layers support
> Header space impact
> Multi tenant support impact
> SFC on flat (e.g optical L2 for Data Centers) network 
> Underlay network administration impact
>

---

From: David Allan I <[email-masked]>
Date: Tue, 18 Mar 2014 16:14:48 +0000

Well the question de jour is “does a chain ID define a class or an instance”…. If it defines an class we also need instance information, if it is currently overloaded to define class and instance IMO we have a problem….

Dave

From: sfc [mailto:[email-masked]] On Behalf Of Changcheng Huang
Sent: Tuesday, March 18, 2014 7:43 AM
To: Nicolas BOUTHORS
Cc: Xuxiaohu; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

Chang

------------
Changcheng Huang

On Mar 18, 2014, at 1:53 AM, Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>> wrote:
I think that keeping the Service Path Layer transport independent should remain an objective for SFC.  Such a separation of concerns is a sound architectural principle that help keep things simple in practice.

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas
________________________________
From: Xuxiaohu [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 18, 2014 5:04 AM
To: Jerome Moisand; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [sfc] 答复: SFC encapsulation chain ID
I like the idea of separating the Service Function Layer and the Service Path Layer, as proposed in draft-rijsman-sfc-metadata-considerations. The role of the Service Path Layer is just to steer the traffic along a particular chain of service nodes which can be implemented by existing tools for source routing, such as segment routing. As such, it’s not necessary to try to keep the Service Path Layer transport-independent and contain it in the SFC header.

Best regards,
Xiaohu

发件人: sfc [mailto:[email-masked]] 代表 Jerome Moisand
发送时间: 2014年3月18日 1:03
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [sfc] SFC encapsulation chain ID

Maria,

---

From: "Changcheng Huang" <[email-masked]>
Date: Tue, 18 Mar 2014 09:27:35 -0700

I think it should identify an instance.

Chang

From: David Allan I [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2014 9:15 AM
To: Changcheng Huang; Nicolas BOUTHORS
Cc: Xuxiaohu; [email-masked]; [email-masked]
Subject: RE: [sfc] 答复: SFC encapsulation chain ID

Dave

Chang

------------

Changcheng Huang

 

*	Visibility (tracing)

*	LBS / scale out impact

 

Nicolas

  _____  

Best regards,

Xiaohu

 

Maria, 

  _____  

From: [email-masked] <mailto:[email-masked][email-masked]> <[email-masked]>
To: Ron Parker<[email-masked]>,Jim Guichard (jguichar)<[email-masked]>,Joel M. Halpern<[email-masked]>
cc: [email-masked] <mailto:[email-masked][email-masked]> <[email-masked]>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

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

>>>>><mailto:[email-masked] <mailto:[email-masked]%3e%3e,%22Surendra> >>,"Surendra Kumar (smkumar)"
>>>>> <[email-masked] <mailto:[email-masked] <mailto:[email-masked]%3e%3e,%22Jim> >>,"Jim Guichard
>>>>>(jguichar)"
>>>>><mailto:[email-masked] <mailto:[email-masked]%3e%3e,sfc> >>,sfc <[email-masked]
>>>>><mailto:[email-masked] <mailto:[email-masked]%3e%3e,Jamal> >>,Jamal Hadi Salim <[email-masked]
>>>>><mailto:[email-masked] <mailto:[email-masked]%3e%3e,Ron> >>,Ron Parker
>>>>> <mailto:[email-masked] <mailto:[email-masked]%3e%3e,[email-masked]> >>,"[email-masked]
>>>>><mailto:[email-masked] <mailto:[email-masked]%3e%3e,%22Joel> >>,"Joel M. Halpern"

---

From: Ron Parker <[email-masked]>
Date: Tue, 18 Mar 2014 17:23:16 +0000

I agree.   The chain id in the packet should represent a fully specified set of located service function instances.    It could be thought of as representing a stack of network locators (typically MAC or IP addresses).

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of Changcheng Huang
Sent: Tuesday, March 18, 2014 12:28 PM
To: 'David Allan I'; 'Nicolas BOUTHORS'
Cc: 'Xuxiaohu'; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

Chang

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

Dave

From: sfc [mailto:[email-masked]] On Behalf Of Changcheng Huang
Sent: Tuesday, March 18, 2014 7:43 AM
To: Nicolas BOUTHORS
Cc: Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 18 Mar 2014 17:26:05 +0000

Hi Dave,

Chain ID should really be path ID since there can be many paths for a given chain.  Using that definition, we avoid the overload and reap the gain alluded to below.

Paul

On Mar 18, 2014, at 12:14 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:

Dave

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Changcheng Huang
Sent: Tuesday, March 18, 2014 7:43 AM
To: Nicolas BOUTHORS
Cc: Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "He, Peng" <[email-masked]>
Date: Tue, 18 Mar 2014 13:28:01 -0400

So there is no class info in the chain ID?

Regards,
Peng

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, March 18, 2014 1:26 PM
To: David Allan I
Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked]; [email-masked]; Changcheng Huang
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

 *   Visibility (tracing)

    *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 18 Mar 2014 17:36:40 +0000

Hi Peng,

What do you mean by class in this context?

Thanks!
Paul

On Mar 18, 2014, at 1:28 PM, "He, Peng" <[email-masked]<mailto:[email-masked]>>
 wrote:

Regards,
Peng

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, March 18, 2014 1:26 PM
To: David Allan I
Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Changcheng Huang
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Tue, 18 Mar 2014 17:40:49 +0000

What is the benefit of having many path per chain ?

Nicolas
________________________________
From: Paul Quinn (paulq) [[email-masked]]
Sent: Tuesday, March 18, 2014 6:26 PM
To: David Allan I
Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked]; [email-masked]; Changcheng Huang
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "He, Peng" <[email-masked]>
Date: Tue, 18 Mar 2014 13:41:02 -0400

Hi Paul,

For path id,  an instance will take just one path (one path ID) or possible multiple paths simultaneously?

Regards,
Peng

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

 *   Visibility (tracing)

    *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: David Allan I <[email-masked]>
Date: Tue, 18 Mar 2014 17:52:04 +0000

First blush is that we would then have pinned state per path ID at every hop in a chain? And chain-ID is simply a CP abstraction? And we need ingress based protection switching to deal with failures promptly….

I’m hoping I’m missing something!
Dave

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Tuesday, March 18, 2014 10:26 AM
To: David Allan I
Cc: Changcheng Huang; Nicolas BOUTHORS; Xuxiaohu; [email-masked]; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "Louis.Fourie" <[email-masked]>
Date: Tue, 18 Mar 2014 17:55:40 +0000

Paul,
   Can you clarify the difference between service chain and service path. Given that a service chain is composed
of several service functions SF1, SF2, .. SFn how would a service path differ from that service chain?

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Cathy Zhang <[email-masked]>
Date: Tue, 18 Mar 2014 18:00:01 +0000

I agree too. A chain ID should represent an ordered set of service function instances. Each service function instance is an instantiation of a service function on a specific service function node.
Multiple flows can share the same chain ID if those flows require the same sequence of service functions and are allocated the same set of service function instances to serve them.

Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, March 18, 2014 10:23 AM
To: Changcheng Huang; 'David Allan I'; 'Nicolas BOUTHORS'
Cc: Xuxiaohu; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

    Ron

Chang

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 18 Mar 2014 18:02:50 +0000

A Service Chain just defines which type of service and their order.

A service path defines the actual service instance, say, firewall1.home, nat2, dpi-sic, etc.

From: "Louis.Fourie" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 18, 2014 at 10:55 AM
To: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, David Allan I <[email-masked]<mailto:[email-masked]>>
Cc: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Changcheng Huang <[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] SFC encapsulation chain ID

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Changcheng Huang <[email-masked]>
Date: Tue, 18 Mar 2014 11:08:25 -0700

Each service chain should have a linear path. However a service provider 
may provide different service chains for different customers. The union 
of these service chain paths may form a tree topology. A service chain 
ID for each service chain help steer a packet to traverse the service 
chain it is intended for.

Chang

On 03/18/2014 10:55 AM, Louis.Fourie wrote:
> -Louis
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Paul Quinn (paulq)
> *Sent:* Tuesday, March 18, 2014 10:26 AM
> *To:* David Allan I
> *Cc:* Nicolas BOUTHORS; Xuxiaohu; [email-masked]; [email-masked]; 
> Changcheng Huang
> *Subject:* Re: [sfc] SFC encapsulation chain ID
>
> Hi Dave,
>
> Chain ID should really be path ID since there can be many paths for a 
> given chain.  Using that definition, we avoid the overload and reap 
> the gain alluded to below.
>
> Paul
>
> On Mar 18, 2014, at 12:14 PM, David Allan I 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
> Well the question de jour is “does a chain ID define a class or an 
> instance”…. If it defines an class we also need instance information, 
> if it is currently overloaded to define class and instance IMO we have 
> a problem….
>
> Dave
>
> *From:*sfc [mailto:[email-masked] <mailto:[email-masked]>]*On 
> Behalf Of*Changcheng Huang
> *Sent:*Tuesday, March 18, 2014 7:43 AM
> *To:*Nicolas BOUTHORS
> *Cc:*Xuxiaohu;[email-masked] <mailto:[email-masked]>;[email-masked] 
> <mailto:[email-masked]>
> *Subject:*Re: [sfc]答复: SFC encapsulation chain ID
>
> Good points. I believe explicit chain ID should be mandatory. The 
> overhead is very little. It helps simplify processing and steering 
> significantly. The gain is huge.
>
> Chang
>
> ------------
>
> Changcheng Huang
>
>
> On Mar 18, 2014, at 1:53 AM, Nicolas BOUTHORS 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I think that keeping the Service Path Layer transport independent
>     should remain an objective for SFC.  Such a separation of concerns
>     is a sound architectural principle that help keep things simple in
>     practice.
>
>     On the question of  Service Path, we have a discussion on whether
>     we need some kind of explicit identifier or
>
>           o LBS / scale out impact
>           o Node bypass (e.g; maintenance)
>
>     Personally I think that having an explicit chain identifier (e.g.
>     Service Path/Service Index) is clear (management and control) and
>     not expensive (header space). The drawback being some impact on
>     the simplicity to add/remove elements in a chain dynamically.
>
>     Tag switching (as MPLS)  allows to manage tags per service nodes,
>     leading to more versatile and diverse graphs
>
>     Nicolas
>
>     ------------------------------------------------------------------------
>
>     *From:*Xuxiaohu [[email-masked] <mailto:[email-masked]>]
>     *Sent:*Tuesday, March 18, 2014 5:04 AM
>     *To:*Jerome Moisand;[email-masked]
>     <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
>     *Subject:*[sfc]答复: SFC encapsulation chain ID
>
>     I like the idea of separating the Service Function Layer and the
>     Service Path Layer, as proposed in
>     draft-rijsman-sfc-metadata-considerations. The role of the Service
>     Path Layer is just to steer the traffic along a particular chain
>     of service nodes which can be implemented by existing tools for
>     source routing, such as segment routing. As such, it’s not
>     necessary to try to keep the Service Path Layer
>     transport-independent and contain it in the SFC header.
>
>     Best regards,
>
>     Xiaohu
>
>     *发 件人:*sfc [mailto:[email-masked]]*代 表*Jerome Moisand
>     *发送时间:*2014 年3月18日 1:03
>     *收件人:[email-masked] <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>
>     *主题:*Re: [sfc] SFC encapsulation chain ID
>
>     This (lengthy and very lively) thread started from
>     draft-rijsman-sfc-metadata-considerations (which I co-authored).
>
>     In section 4.8, we made a clear distinction between a service path
>     layer (steering packets hop by hop along the chain) and a service
>     function layer (convey metadata information of interest to SFs).
>     Terminology aside, it seems that such layered view was agreed upon
>     by many people on the mailing list.
>
>     Now this certainly does beg the question of solving BOTH problems
>     with the same (packet) encapsulation mechanism. Notably when
>     observing that many use cases could be satisfied without SF-level
>     metadata, or by using more out-of-band ways to convey such SF
>     metadata. And also when observing that inband marking (e.g. packet
>     headers) comes with various pros & cons (some of the issues being
>     identified in the draft, e.g. sections 4.1 and 4.2).
>
>     I do agree with Maria. We may want to explore other options for
>     addressing the needs of the service path layer that do not require
>     an explicit chain-id of sorts.
>
>     In the draft, we concluded by stating “A productive path forward
>     could be to divide and conquer: to clearly separate the problem of
>     Service Function Path topology from the   problem of [conveying
>     SF] metadata”. I do believe we should explore such separation
>     principle further.
>
>     *From:*sfc [mailto:[email-masked]]*On Behalf
>     [email-masked] <mailto:[email-masked]>
>     *Sent:*Friday, March 14, 2014 5:50 PM
>     *To:[email-masked] <mailto:[email-masked]>
>     *Subject:*Re: [sfc] SFC encapsulation chain ID
>
>     I would imagine that if we made the Chain ID field in the header
>     be optional, yet still required a header and still required that
>     some indication of the chain be carried somewhere in the packet
>     (mpls label or vlan or whatever), that the implementation would
>     become overly complicated.  To do so would be using SFC simply as
>     a mechanism to carry meta data and not at all for service
>     chaining, which sounds counter intuitive to me.
>
>     Maria,
>     So, you are saying that you want to use SFC to carry around
>     metadata, but not for actual service chaining because you already
>     have a way to implement service chaining outside of SFC?  Maybe
>     I'm not following, but it seems to me that if you were to upgrade
>     your network to support SFC that you would change from using your
>     existing mechanism and start using SFC, which is meant to provide
>     support for service functions that are not SFC aware.  There are a
>     number of us who have implemented, in one way or another, some
>     sort of service chaining, but I (I can at least speak for myself)
>     am looking to SFC not to enhance my current implementation, but to
>     replace it with something better while still maintaining my core
>     (non service function) infrastructure.
>
>     ------------------------------------------------------------------------
>
>     *From:[email-masked]<[email-masked]
>     <mailto:[email-masked][email-masked]>>
>     *To:*Ron Parker<[email-masked]
>     <mailto:[email-masked]>>,Jim Guichard
>     (jguichar)<[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] SFC encapsulation chain ID
>
>     On 3/14/14 12:55 PM, "Ron Parker" <[email-masked]
>     >Cc:[email-masked] <mailto:[email-masked]>
>     >>> Cc:[email-masked] <mailto:[email-masked]>
>     >>>>> *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]>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     >>>>><mailto:[email-masked]>>,"Surendra
>     <mailto:[email-masked]%3e%3e,%22Surendra>Kumar (smkumar)"
>     >>>>> <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>>,"Jim
>     <mailto:[email-masked]%3e%3e,%22Jim>Guichard
>     >>>>>(jguichar)"
>     >>>>> <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     >>>>><mailto:[email-masked]>>,sfc
>     <mailto:[email-masked]%3e%3e,sfc><[email-masked]
>     <mailto:[email-masked]>
>     >>>>><mailto:[email-masked]>>,Jamal
>     <mailto:[email-masked]%3e%3e,Jamal>Hadi Salim <[email-masked]
>     <mailto:[email-masked]>
>     >>>>><mailto:[email-masked]>>,Ron
>     <mailto:[email-masked]%3e%3e,Ron>Parker
>     <mailto:[email-masked]>
>     >>>>>
>     <mailto:[email-masked]%3e%3e,[email-masked]>
>     <mailto:[email-masked]>
>     >>>>><mailto:[email-masked]>>,"Joel
>     <mailto:[email-masked]%3e%3e,%22Joel>M. Halpern"
>     >>>>><[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>>
>     >>>>>
>     <mailto:[email-masked]>
>     >>>>>   >>[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>; sfc; Jamal
>     >>>>>Hadi Salim
>     <mailto:[email-masked]>
>     >>>>><[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>     >>>>>   >>>>
>     ability
>     >>>>>   >>>> Cc: Jim Guichard (jguichar);[email-masked]
>     <mailto:[email-masked]>
>     >>>>>[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>; sfc;
>     >>>>> >>>>>> (jguichar);[email-masked]
>     <mailto:[email-masked]>
>     >>>>>[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>;
>     >>>>> >>>>>>>> Guichard (jguichar);[email-masked]
>     <mailto:[email-masked]>
>     >>>>>[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>;
>     >>>>> >>>>>>>>>> Parker [[email-masked]
>     <mailto:[email-masked]>] Sent:
>     >>>>>Wednesday,
>     >>>>> >>>>>>>>>> March 12, 2014
>     >>>>> >>>>>>>>>>[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>;
>     <mailto:[email-masked]>
>     >>>>> >>>>>>>>>>> Nicolas BOUTHORS;[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[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 [email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>
>     >>>>> >>>>>>>>>>>>> [email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>
>     >>>>> >>>>>>>>>> [email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>
>     >>>>> >>>>>>>>> [email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>
>     >>>>> >>>>>>>>> [email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]>
>     >>>>>   >>>>>[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: Cathy Zhang <[email-masked]>
Date: Tue, 18 Mar 2014 18:13:26 +0000

Hi Reinaldo,

So the chain ID is actually the path ID which represents an ordered set of service function instances.
I think we should add an explicit definition of “service instance”. What do you think?

Thanks,
Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Tuesday, March 18, 2014 11:03 AM
To: Louis.Fourie; Paul Quinn (paulq); David Allan I
Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked]; [email-masked]; Changcheng Huang
Subject: Re: [sfc] SFC encapsulation chain ID

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Mar 2014 01:05:27 +0000

If so, why not leverage the source routing mechanism to do this work (i.e., service path layer)?

Best regards,
Xiaohu

发件人: Ron Parker [mailto:[email-masked]]
发送时间: 2014年3月19日 1:23
收件人: Changcheng Huang; 'David Allan I'; 'Nicolas BOUTHORS'
抄送: Xuxiaohu; [email-masked]; [email-masked]
主题: RE: [sfc] 答复: SFC encapsulation chain ID

    Ron

Cc: 'Xuxiaohu'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Chang

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Wed, 19 Mar 2014 07:07:06 +0000

Why source routing?

It's a consensus that source routing is a bad idea due to the security implications. I recon this might not be the case here because we have a controlled packet forwarding infrastructure underneath. However, source routing would impose new requirements to it and make it harder to implement and more complex to manage,

Best,/PA

Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:[email-masked]
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

De: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Fecha: miércoles 19 de marzo de 2014 02:05
Para: Ron Parker <[email-masked]<mailto:[email-masked]>>, Changcheng Huang <[email-masked]<mailto:[email-masked]>>, 'David Allan I' <[email-masked]<mailto:[email-masked]>>, 'Nicolas BOUTHORS' <[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]>>
Asunto: [sfc] 答复: 答复: SFC encapsulation chain ID

Best regards,
Xiaohu

发件人: Ron Parker [mailto:[email-masked]]
发送时间: 2014年3月19日 1:23
收件人: Changcheng Huang; 'David Allan I'; 'Nicolas BOUTHORS'
抄送: Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: RE: [sfc] 答复: SFC encapsulation chain ID

    Ron

Chang

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 19 Mar 2014 07:40:21 +0000

<<Trimmed the TO list to avoid the msg being held again>>

I see two ways to carry the path information.

  1.  Explicit ordered list, something like FW-A :: TCP-OPT :: LB :: VideoOPT :: CGNAT.   There are two issues with this approach, first the length of graph is variable.  Also it implies bidirectional symmetry. It is often required but should not be mandatory.  Secondly changing this path/graph in at SF can be cumbersome.
  2.  Let the Control plane distribute the chainID <—> graph mapping. In this case each SF would have mapping of given a chainID what is my next hop. The chainID itself could be fixed size element. A SF can select a different path by changing the chaiID parameter.

Regards
Sumandra

From: Cathy Zhang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 18, 2014 at 10:13 AM
To: "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, "Louis.Fourie" <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, David Allan I <[email-masked]<mailto:[email-masked]>>
Cc: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Changcheng Huang <[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] SFC encapsulation chain ID

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Mar 2014 08:43:33 +0000

Let me try to give an example of leveraging segment routing (a mechanism for source routing) for service chain as follows:

SN1 and SN2 are two SR nodes providing service S1 and S2 respectively and they have each allocated segment IDs (e.g., SID(S1) and SID(S2)) for indicating service S1 and S2 respectively. In the MPLS-SR case, these service segment IDs could be local MPLS labels. In IPv6-SR case, these service segment IDs could be link-local IPv6 addresses. In the IPv4-SR case (assume it’s required in the future), these service segment IDs could be particular private addresses. In addition, the node segment IDs for SN1 and SN2 are SID(SN1) and SID(SN2). Take the MPLS-SR as an example, assume a packet is required to go through a service chain {S1, S2} before reaching its destination D. The service Classifier would attach a segment list {SID(SN1), SID(S1), SID(SN2), SID(S2)} to the packet. Of course, the service Classifier could additionally attach a metadata to the packet. When the encapsulated packet arrives at SN1, SN1 could know which service should be executed according to the SID (S1) before forwarding that packet towards SN2. Meanwhile, SN1 could also consume the metadata if carried in that packet.

If the above SR nodes (i.e., SN1 and SN2) are just SF proxy, rather than real SF nodes, the advertised service segment IDs could be used to indicate the interfaces connected to the corresponding service nodes.

Best regards,
Xiaohu

发件人: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[email-masked]]
发送时间: 2014年3月19日 15:07
收件人: Xuxiaohu; Ron Parker; Changcheng Huang; 'David Allan I'; 'Nicolas BOUTHORS'
抄送: [email-masked]; [email-masked]
主题: Re: [sfc] 答复: 答复: SFC encapsulation chain ID

Why source routing?

Best,/PA

Technology Exploration -

mailto:[email-masked]

Best regards,
Xiaohu

    Ron

Chang

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 19 Mar 2014 07:03:19 +0000

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Ron Parker <[email-masked]>
Date: Wed, 19 Mar 2014 11:33:09 +0000

Sumandra,

I've been thinking that your approach 2 would be the way to go.

   Ron

On Mar 19, 2014, at 3:40 AM, "Sumandra Majee" <[email-masked]<mailto:[email-masked]>> wrote:

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 19 Mar 2014 08:19:11 -0400

You should allow for both schemes.

cheers,
jamal

On Wed, Mar 19, 2014 at 7:33 AM, Ron Parker
<[email-masked]> wrote:
> On Mar 19, 2014, at 3:40 AM, "Sumandra Majee" <[email-masked]> wrote:
>
> Explicit ordered list, something like FW-A :: TCP-OPT :: LB :: VideoOPT ::
> CGNAT.   There are two issues with this approach, first the length of graph
> is variable.  Also it implies bidirectional symmetry. It is often required
> but should not be mandatory.  Secondly changing this path/graph in at SF can
> be cumbersome.
> Let the Control plane distribute the chainID <—> graph mapping. In this case
> each SF would have mapping of given a chainID what is my next hop. The
> chainID itself could be fixed size element. A SF can select a different path
> by changing the chaiID parameter.
>
>
> Regards
> Sumandra
>
>
> From: Cathy Zhang <[email-masked]>
> To: "Reinaldo Penno (repenno)" <[email-masked]>, "Louis.Fourie"
> <[email-masked]>, "Paul Quinn (paulq)" <[email-masked]>, David
> Allan I <[email-masked]>
> Cc: Nicolas BOUTHORS <[email-masked]>, Xuxiaohu
> <[email-masked]>, Changcheng Huang <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> From: "Louis.Fourie" <[email-masked]>
> To: "Paul Quinn (paulq)" <[email-masked]>, David Allan I
> <[email-masked]>
> Cc: Nicolas BOUTHORS <[email-masked]>, Xuxiaohu
> <[email-masked]>, Changcheng Huang <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Chain ID should really be path ID since there can be many paths for a given
> chain.  Using that definition, we avoid the overload and reap the gain
> alluded to below.
>
>
>
> Paul
>
>
>
> On Mar 18, 2014, at 12:14 PM, David Allan I <[email-masked]>
> wrote:
>
>
>
>
> instance”…. If it defines an class we also need instance information, if it
> is currently overloaded to define class and instance IMO we have a problem….
>
>
>
> Dave
>
>
>
> Good points. I believe explicit chain ID should be mandatory. The overhead
> is very little. It helps simplify processing and steering significantly. The
> gain is huge.
>
>
>
> Chang
>
> ------------
>
> Changcheng Huang
>
>
> I think that keeping the Service Path Layer transport independent should
> remain an objective for SFC.  Such a separation of concerns is a sound
> architectural principle that help keep things simple in practice.
>
>
>
> Personally I think that having an explicit chain identifier (e.g. Service
> Path/Service Index) is clear (management and control) and not expensive
> (header space). The drawback being some impact on the simplicity to
> add/remove elements in a chain dynamically.
>
>
>
> I like the idea of separating the Service Function Layer and the Service
> Path Layer, as proposed in draft-rijsman-sfc-metadata-considerations. The
> role of the Service Path Layer is just to steer the traffic along a
> particular chain of service nodes which can be implemented by existing tools
> for source routing, such as segment routing. As such, it’s not necessary to
> try to keep the Service Path Layer transport-independent and contain it in
> the SFC header.
>
>
>
> Best regards,
>
> Xiaohu
>
>
>
> In section 4.8, we made a clear distinction between a service path layer
> (steering packets hop by hop along the chain) and a service function layer
> (convey metadata information of interest to SFs). Terminology aside, it
> seems that such layered view was agreed upon by many people on the mailing
> list.
>
>
>
> Now this certainly does beg the question of solving BOTH problems with the
> same (packet) encapsulation mechanism. Notably when observing that many use
> cases could be satisfied without SF-level metadata, or by using more
> out-of-band ways to convey such SF metadata. And also when observing that
> inband marking (e.g. packet headers) comes with various pros & cons (some of
> the issues being identified in the draft, e.g. sections 4.1 and 4.2).
>
>
>
> I do agree with Maria. We may want to explore other options for addressing
> the needs of the service path layer that do not require an explicit chain-id
> of sorts.
>
>
>
> In the draft, we concluded by stating “A productive path forward could be to
> divide and conquer: to clearly separate the problem of Service Function Path
> topology from the   problem of [conveying SF] metadata”. I do believe we
> should explore such separation principle further.
>
>
>
>
>
> I would imagine that if we made the Chain ID field in the header be
> optional, yet still required a header and still required that some
> indication of the chain be carried somewhere in the packet (mpls label or
> vlan or whatever), that the implementation would become overly complicated.
> To do so would be using SFC simply as a mechanism to carry meta data and not
> at all for service chaining, which sounds counter intuitive to me.
>
> Maria,
> So, you are saying that you want to use SFC to carry around metadata, but
> not for actual service chaining because you already have a way to implement
> service chaining outside of SFC?  Maybe I'm not following, but it seems to
> me that if you were to upgrade your network to support SFC that you would
> change from using your existing mechanism and start using SFC, which is
> meant to provide support for service functions that are not SFC aware.
> There are a number of us who have implemented, in one way or another, some
> sort of service chaining, but I (I can at least speak for myself) am looking
> to SFC not to enhance my current implementation, but to replace it with
> something better while still maintaining my core (non service function)
> infrastructure.
>
> To: Ron Parker<[email-masked]>,Jim Guichard
> (jguichar)<[email-masked]>,Joel M. Halpern<[email-masked]>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 19 Mar 2014 12:38:04 +0000

I agree with Ron. Option 2 is the kind of approach I see simpler to implement in any scenario I can think of, and easier for integrating non-SFC-aware gear.

Be goode,

On 19 Mar 2014, at 13:33 , Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:

Sumandra,

   Ron

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 19 Mar 2014 12:44:58 +0000

Hi Sumandra,

I lean towards #2: essentially encoding the information into a simple ID, rather than trying to create a variable length stack.  The encoding method is much simpler for SFs to process, and as you point out update and modify.

Paul

On Mar 19, 2014, at 3:40 AM, Sumandra Majee <[email-masked]<mailto:[email-masked]>> wrote:

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

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

+1

Sent from my iPhone

On 19 Mar 2014, at 13:45, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sumandra,

Paul

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 19 Mar 2014 13:00:53 +0000

+1

Sent from my iPhone

On Mar 19, 2014, at 8:45 AM, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sumandra,

Paul

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Changcheng Huang <[email-masked]>
Date: Wed, 19 Mar 2014 07:22:34 -0700

Definite #2. Carrying path list in header is a heavy overhead which should be avoided. 

Chang

------------
Changcheng Huang

> On Mar 19, 2014, at 5:44 AM, "Paul Quinn (paulq)" <[email-masked]> wrote:
> 
> Hi Sumandra,
> 
>> On Mar 19, 2014, at 3:40 AM, Sumandra Majee <[email-masked]> wrote:
>> 
>> Explicit ordered list, something like FW-A :: TCP-OPT :: LB :: VideoOPT :: CGNAT.   There are two issues with this approach, first the length of graph is variable.  Also it implies bidirectional symmetry. It is often required but should not be mandatory.  Secondly changing this path/graph in at SF can be cumbersome. 
>> Let the Control plane distribute the chainID <—> graph mapping. In this case each SF would have mapping of given a chainID what is my next hop. The chainID itself could be fixed size element. A SF can select a different path by changing the chaiID parameter.
>> 
>> Regards
>> Sumandra
>> 
>> 
>> To: "Reinaldo Penno (repenno)" <[email-masked]>, "Louis.Fourie" <[email-masked]>, "Paul Quinn (paulq)" <[email-masked]>, David Allan I <[email-masked]>
>> Cc: Nicolas BOUTHORS <[email-masked]>, Xuxiaohu <[email-masked]>, Changcheng Huang <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> To: "Paul Quinn (paulq)" <[email-masked]>, David Allan I <[email-masked]>
>> Cc: Nicolas BOUTHORS <[email-masked]>, Xuxiaohu <[email-masked]>, Changcheng Huang <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> On Mar 18, 2014, at 12:14 PM, David Allan I <[email-masked]> wrote:
>> 
>> 
>>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 19 Mar 2014 13:11:07 +0000

+1

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, March 19, 2014 9:01 AM
To: Paul Quinn (paulq)
Cc: David Allan I; Cathy Zhang; Sumandra Majee; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

+1

Sent from my iPhone

Paul

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 19 Mar 2014 12:45:33 -0400

+1 as well for #2.    

It is much easier to set up flows if a SF knows that IF path ID = x, then next-hop in path is y, without having to find itself in the packet, etc.
But, should this field represent the chainID or the pathID?  If the pathID, then that means that each SF instance is chosen at classification time and each SF instance simply forwards based on knowing the pre-designated next SF instance.  However, if the field represents a chain ID, then each SF would choose the instance of the predesignated next-SF before sending it on.  This might be useful if that next-hop instance goes away after classification.

From: [email-masked]<[email-masked]>
To: Sumandra Majee<[email-masked]>
cc: Cathy Zhang<[email-masked]>,[email-masked]<[email-masked]>,David Allan I<[email-masked]>
Sent: Wednesday, March 19, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Sumandra,

Paul

Explicit ordered list, something like FW-A :: TCP-OPT :: LB :: VideoOPT :: CGNAT.   There are two issues with this approach, first the length of graph is variable.  Also it implies bidirectional symmetry. It is often required but should not be mandatory.
  Secondly changing this path/graph in at SF can be cumbersome. Let the Control plane distribute the chainID <—> graph mapping. In this case each SF would have mapping of given a chainID what is my next hop. The chainID itself could be fixed size element. A SF can select a different path by changing the chaiID parameter.

Regards

Sumandra

To: "Reinaldo Penno (repenno)" <[email-masked]>, "Louis.Fourie" <[email-masked]>, "Paul Quinn (paulq)" <[email-masked]>,
 David Allan I <[email-masked]>

Cc: Nicolas BOUTHORS <[email-masked]>, Xuxiaohu <[email-masked]>, Changcheng Huang <[email-masked]>,
 "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Hi Reinaldo,

 
Thanks,
Cathy

From: sfc [mailto:[email-masked]]
On Behalf Of Reinaldo Penno (repenno)

Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked];
[email-masked]; Changcheng Huang

 

 

 

From:
"Louis.Fourie" <[email-masked]>

Cc: Nicolas BOUTHORS <[email-masked]>, Xuxiaohu <[email-masked]>, Changcheng Huang <[email-masked]>,
 "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

 

Paul,

-         
Louis

From: sfc [mailto:[email-masked]]
On Behalf Of Paul Quinn (paulq)

To: David Allan I

Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked];
[email-masked]; Changcheng Huang

 
Hi Dave, 

 

Paul

Well the question de jour is “does a chain ID define a class or an instance”…. If it defines an class we also need instance information, if it is
 currently overloaded to define class and instance IMO we have a problem….

Dave

From: sfc
 [mailto:[email-masked]] On Behalf Of Changcheng Huang

To: Nicolas BOUTHORS

Subject: Re: [sfc] 答复:
 SFC encapsulation chain ID

 

Chang

------------

Changcheng Huang

I think that keeping the Service Path Layer transport independent should remain an objective for SFC.  Such a separation of concerns is a sound architectural principle that
 help keep things simple in practice.

 

 

Visibility (tracing)Forwarding graph structure impact/limitationsReconfiguration speed 

LBS / scale out impactNode bypass (e.g; maintenance)

underlay network/transport layers supportHeader space impactMulti tenant support impactSFC on flat (e.g optical L2 for Data Centers) network Underlay network administration impact

Personally I think that having an explicit chain identifier (e.g. Service Path/Service Index) is clear (management and control) and not expensive (header space). The drawback
 being some impact on the simplicity to add/remove elements in a chain dynamically.

 

Nicolas

From: Xuxiaohu
 [[email-masked]]

Subject: [sfc] 答复:
 SFC encapsulation chain ID

I like the idea of separating the Service Function Layer and the Service Path Layer, as proposed in draft-rijsman-sfc-metadata-considerations. The
 role of the Service Path Layer is just to steer the traffic along a particular chain of service nodes which can be implemented by existing tools for source routing, such as segment routing. As such, it’s not necessary to try to keep the Service Path Layer
 transport-independent and contain it in the SFC header.

Best regards,

Xiaohu

发件人: sfc
 [mailto:[email-masked]] 代表 Jerome Moisand

发送时间: 2014年3月18日 1:03

 

 

In section 4.8, we made a clear distinction between a service path layer (steering packets hop by hop along the chain) and a service function layer
 (convey metadata information of interest to SFs). Terminology aside, it seems that such layered view was agreed upon by many people on the mailing list.

Now this certainly does beg the question of solving BOTH problems with the same (packet) encapsulation mechanism. Notably when observing that many
 use cases could be satisfied without SF-level metadata, or by using more out-of-band ways to convey such SF metadata. And also when observing that inband marking (e.g. packet headers) comes with various pros & cons (some of the issues being identified in the
 draft, e.g. sections 4.1 and 4.2).

I do agree with Maria. We may want to explore other options for addressing the needs of the service path layer that do not require an explicit chain-id
 of sorts.

In the draft, we concluded by stating “A productive path forward could be to divide and conquer: to clearly separate the problem of Service Function
 Path topology from the   problem of [conveying SF] metadata”. I do believe we should explore such separation principle further.

 

From: sfc
 [mailto:[email-masked]] On Behalf Of [email-masked]

To: [email-masked]

 

I would imagine that if we made the Chain ID field in the header be optional, yet still required a header and still required that some indication
 of the chain be carried somewhere in the packet (mpls label or vlan or whatever), that the implementation would become overly complicated.  To do so would be using SFC simply as a mechanism to carry meta data and not at all for service chaining, which sounds
 counter intuitive to me. 

Maria, 

So, you are saying that you want to use SFC to carry around metadata, but not for actual service chaining because you already have a way to implement service chaining outside of SFC?  Maybe I'm not following, but it seems to me that if you were to upgrade your
 network to support SFC that you would change from using your existing mechanism and start using SFC, which is meant to provide support for service functions that are not SFC aware.  There are a number of us who have implemented, in one way or another, some
 sort of service chaining, but I (I can at least speak for myself) am looking to SFC not to enhance my current implementation, but to replace it with something better while still maintaining my core (non service function) infrastructure.

To: Ron Parker<[email-masked]>,Jim Guichard (jguichar)<[email-masked]>,Joel
 M. Halpern<[email-masked]>

>>>>> *To:* [email-masked]; [email-masked]; [email-masked]
;

>>>>> *Cc:* [email-masked]; [email-masked]; [email-masked]
;

>>>>>   >>[email-masked] <mailto:[email-masked]>;
 sfc; Jamal

>>>>>BOUTHORS
;
>>>>>[email-masked] <mailto:[email-masked]>;
 sfc
;

>>>>>BOUTHORS
;

>>>>>BOUTHORS
;

>>>>>(jguichar)
;

>>>>>Salim
;

sfc mailing list

[email-masked]

sfc mailing list

[email-masked]

sfc mailing list

[email-masked]

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Wed, 19 Mar 2014 16:49:00 +0000

I agree that simple id is more preferred.

I would stick with a chain is name. The id can map to a static path or may (with further app in a chain processing) result in dynamic chain.

Andrew

On Mar 19, 2014, at 3:36 PM, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>> wrote:

+1

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, March 19, 2014 9:01 AM
To: Paul Quinn (paulq)
Cc: David Allan I; Cathy Zhang; Sumandra Majee; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC encapsulation chain ID

+1

Sent from my iPhone

Paul

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Jiafeng Zhu <[email-masked]>
Date: Wed, 19 Mar 2014 17:14:17 +0000

Hi Sumandra,

       The second approach is better. The Control plane can dispatch chainID, it’s short and clean.

Best,
Jiafeng

From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, March 19, 2014 12:40 AM
To: Cathy Zhang; Paul Quinn (paulq); David Allan I
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 19 Mar 2014 17:25:00 +0000

+1 for #2.

Mike brings up a good point that we should make it clear about the chainID.
Although we say that the chain ID is the path ID that represents an ordered set of  service instances, the instances can be pre-chosen (eg. by a centralized control plane) or can be dynamically chosen/modified by local SF or can be a combination of both (different design/implementation options are allowed). For example in some implementation,
a centralized controller can choose the sequence of service instances based on  a global view of the “service capability and status map” and program each node properly for forwarding,
but some SF node along the path can dynamically change the next hop SF based on its processing result.
The path does not mean a static fixed path.
Thanks,
Cathy

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 19, 2014 9:46 AM
To: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

+1 as well for #2.

Hi Sumandra,

Paul

Regards
Sumandra

Hi Reinaldo,

Louis

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Maria,
So, you are saying that you want to use SFC to carry around metadata, but not for actual service chaining because you already have a way to implement service chaining outside of SFC? Maybe I'm not following, but it seems to me that if you were to upgrade your network to support SFC that you would change from using your existing mechanism and start using SFC, which is meant to provide support for service functions that are not SFC aware. There are a number of us who have implemented, in one way or another, some sort of service chaining, but I (I can at least speak for myself) am looking to SFC not to enhance my current implementation, but to replace it with something better while still maintaining my core (non service function) infrastructure.
________________________________
From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: Ron Parker<[email-masked]<mailto:[email-masked]>>,Jim Guichard (jguichar)<[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>
cc: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 14, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

---

From: "He, Peng" <[email-masked]>
Date: Wed, 19 Mar 2014 13:25:23 -0400

Support #2 as well.

Regards,
Peng

From: sfc [mailto:[email-masked]] On Behalf Of Jiafeng Zhu
Sent: Wednesday, March 19, 2014 1:14 PM
To: Sumandra Majee; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Sumandra,

Best,
Jiafeng

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

 *   Visibility (tracing)

    *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: "He, Peng" <[email-masked]>
Date: Wed, 19 Mar 2014 13:33:25 -0400

Do we have a document somewhere (maybe I missed it) to explicitly define the terms like Chain ID, Path ID, service instance, SF instances, service chain, service path?

Regards,
Peng

From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Wednesday, March 19, 2014 1:25 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

+1 for #2.

Thanks,
Cathy

+1 as well for #2.

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Sumandra Majee<[email-masked]<mailto:[email-masked]>>
cc: Cathy Zhang<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,David Allan I<[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 19, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

Hi Sumandra,

Paul

Regards
Sumandra

Hi Reinaldo,

Louis

------------
Changcheng Huang

 *   Visibility (tracing)

    *   LBS / scale out impact

Maria,

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 19 Mar 2014 17:59:32 +0000

The following links have terminology definitions. Some other SFC specs also have definitions.

http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework/
http://datatracker.ietf.org/doc/draft-quinn-sfc-arch/?include_text=1

From: He, Peng [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 10:33 AM
To: Cathy Zhang; [email-masked]; [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Regards,
Peng

+1 for #2.

Thanks,
Cathy

+1 as well for #2.

Hi Sumandra,

Paul

Regards
Sumandra

Hi Reinaldo,

Louis

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Maria,

---

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

Hi Sumandra,

I am fine with option 2 approach.

But your description indicates that SF is aware of chainID and is responsible to forward packet to the next hop SF and select a different paths by changing the chained parameter. This means that we will only have single component, SF, in SFC architecture? (maybe two, classifier and SF).  I disagree this SFC architecture. We need to distinguish SF and forwarding component in SFC architecture, two has different roles.

Another point, in option 2 approach, do we need mandate that the forwarding has to use the chainID?  Many SP people has expressed that they may want to use different ways to establish the SFC path, not rely on the info carried on packets. Should SFC solution allow that option?

Again, I am fine with option 2 approach.

Thanks,
Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, March 19, 2014 2:03 AM
To: Cathy Zhang; Reinaldo Penno (repenno); Louis.Fourie; Paul Quinn (paulq); David Allan I
Cc: Nicolas BOUTHORS; Xuxiaohu; [email-masked]; [email-masked]; Changcheng Huang
Subject: Re: [sfc] SFC encapsulation chain ID

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Dave Dolson <[email-masked]>
Date: Wed, 19 Mar 2014 18:28:12 +0000

[trim list]
I’m unclear about the intent of the word “chain” vs “path” in option #2.
In earlier discussions, “chain” was considered an abstract concept (a traversal of a list of types of services), whereas “path” was a traversal of specific node instances.

I think that the ID carried in the packet needs to indicate a specific set of nodes, and I hope that is what you mean.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, March 19, 2014 3:40 AM
To: Cathy Zhang; Paul Quinn (paulq); David Allan I
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Ron Parker <[email-masked]>
Date: Wed, 19 Mar 2014 20:00:56 +0000

Yes.   Perhaps in the header we should call out a service path id rather than a service chain id.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Wednesday, March 19, 2014 2:28 PM
To: Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

[trim list]

-Dave

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Changcheng Huang <[email-masked]>
Date: Wed, 19 Mar 2014 14:18:18 -0700

Consider the case that multiple services are collocated in one node, if 
the ID only identifies a node, it will be not helpful to decide the 
order of the services within the node. It is possible to use the ID to 
identify both path of nodes and the order of collocated services within 
one node.

Chang

On 03/19/2014 01:00 PM, Ron Parker wrote:
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Dave Dolson
> *Sent:* Wednesday, March 19, 2014 2:28 PM
> *To:* Sumandra Majee
> *Cc:* [email-masked]
> I'm unclear about the intent of the word "chain" vs "path" in option #2.
>
> In earlier discussions, "chain" was considered an abstract concept (a 
> traversal of a list of types of services), whereas "path" was a 
> traversal of specific node instances.
>
> I think that the ID carried in the packet needs to indicate a specific 
> set of nodes, and I hope that is what you mean.
>
> -Dave
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Sumandra Majee
> *Sent:* Wednesday, March 19, 2014 3:40 AM
> *To:* Cathy Zhang; Paul Quinn (paulq); David Allan I
> *Cc:* [email-masked] <mailto:[email-masked]>
>  1. Explicit ordered list, something like FW-A :: TCP-OPT :: LB ::
>     VideoOPT :: CGNAT.   There are two issues with this approach,
>     first the length of graph is variable.  Also it implies
>     bidirectional symmetry. It is often required but should not be
>     mandatory.  Secondly changing this path/graph in at SF can be
>     cumbersome.
>  2. Let the Control plane distribute the chainID <---> graph mapping.
>     In this case each SF would have mapping of given a chainID what is
>     my next hop. The chainID itself could be fixed size element. A SF
>     can select a different path by changing the chaiID parameter.
>
> Regards
>
> Sumandra
>
> *From: *Cathy Zhang <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Tuesday, March 18, 2014 at 10:13 AM
> *To: *"Reinaldo Penno (repenno)" <[email-masked] 
> <mailto:[email-masked]>>, "Louis.Fourie" <[email-masked] 
> <mailto:[email-masked]>>, "Paul Quinn (paulq)" 
> <[email-masked] <mailto:[email-masked]>>, David Allan I 
> <[email-masked] <mailto:[email-masked]>>
> *Cc: *Nicolas BOUTHORS <[email-masked] 
> <mailto:[email-masked]>>, Xuxiaohu <[email-masked] 
> <mailto:[email-masked]>>, Changcheng Huang <[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] SFC encapsulation chain ID
>
> Hi Reinaldo,
>
> I think we should add an explicit definition of "service instance". 
> What do you think?
>
> Thanks,
>
> Cathy
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Reinaldo Penno 
> (repenno)
> *Sent:* Tuesday, March 18, 2014 11:03 AM
> *To:* Louis.Fourie; Paul Quinn (paulq); David Allan I
> *Cc:* Nicolas BOUTHORS; Xuxiaohu; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> Changcheng Huang
> *From: *"Louis.Fourie" <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Tuesday, March 18, 2014 at 10:55 AM
> *To: *"Paul Quinn (paulq)" <[email-masked] <mailto:[email-masked]>>, 
> David Allan I <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *Nicolas BOUTHORS <[email-masked] 
> <mailto:[email-masked]>>, Xuxiaohu <[email-masked] 
> <mailto:[email-masked]>>, Changcheng Huang <[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] SFC encapsulation chain ID
>
> Paul,
>
> *Cc:* Nicolas BOUTHORS; Xuxiaohu; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> Changcheng Huang
> Well the question de jour is "does a chain ID define a class or an 
> instance".... If it defines an class we also need instance 
> information, if it is currently overloaded to define class and 
> instance IMO we have a problem....
>
> Dave
>
> *Subject:*Re: [sfc]??: SFC encapsulation chain ID
>
>     *Subject:*[sfc]??: SFC encapsulation chain ID
>
>     source routing, such as segment routing. As such, it's not
>     *???**:*sfc [mailto:[email-masked]]*??***Jerome Moisand
>     *????**:*2014?3?18?1:03
>     *???**:[email-masked] <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>
>     *??**:*Re: [sfc] SFC encapsulation chain ID
>
>     In the draft, we concluded by stating "A productive path forward
>     SF] metadata". I do believe we should explore such separation
>     principle further.
>

---

From: "Louis.Fourie" <[email-masked]>
Date: Wed, 19 Mar 2014 21:21:32 +0000

Ron,
   I  agree, a service path Id should be used in the service chain header.

-          Louis

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, March 19, 2014 1:01 PM
To: Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

   Ron

[trim list]

-Dave

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Dave Dolson <[email-masked]>
Date: Wed, 19 Mar 2014 21:22:30 +0000

When I used “node”, I meant an instance of a service function; there could be multiple per machine. So a “path” traverses SF instances.

I use “instance” to emphasize one particular, real instance of service function, rather than an abstract class of service functions.

From: Changcheng Huang [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 5:18 PM
To: Ron Parker; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Consider the case that multiple services are collocated in one node, if the ID only identifies a node, it will be not helpful to decide the order of the services within the node. It is possible to use the ID to identify both path of nodes and the order of collocated services within one node.

Chang

   Ron

[trim list]

-Dave

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

sfc mailing list

---

From: Changcheng Huang <[email-masked]>
Date: Wed, 19 Mar 2014 14:26:25 -0700

I see. Then the ID should identify the path of service function instances.

Chang

On 03/19/2014 02:22 PM, Dave Dolson wrote:
>
> When I used "node", I meant an instance of a service function; there 
> could be multiple per machine. So a "path" traverses SF instances.
>
> I use "instance" to emphasize one particular, real instance of service 
> function, rather than an abstract class of service functions.
>
> *From:*Changcheng Huang [mailto:[email-masked]]
> *Sent:* Wednesday, March 19, 2014 5:18 PM
> *To:* Ron Parker; Dave Dolson; Sumandra Majee
> *Cc:* [email-masked]
> Consider the case that multiple services are collocated in one node, 
> if the ID only identifies a node, it will be not helpful to decide the 
> identify both path of nodes and the order of collocated services 
> within one node.
>
> Chang
>
>     In earlier discussions, "chain" was considered an abstract concept
>     (a traversal of a list of types of services), whereas "path" was a
>     I think that the ID carried in the packet needs to indicate a
>     specific set of nodes, and I hope that is what you mean.
>
>     -Dave
>
>      2. Let the Control plane distribute the chainID <---> graph
>         mapping. In this case each SF would have mapping of given a
>         chainID what is my next hop. The chainID itself could be fixed
>         size element. A SF can select a different path by changing the
>         chaiID parameter.
>
>     Regards
>
>     Sumandra
>
>     <mailto:[email-masked]>>, "Louis.Fourie"
>     <[email-masked] <mailto:[email-masked]>>, "Paul
>     Quinn (paulq)" <[email-masked] <mailto:[email-masked]>>, David
>     Allan I <[email-masked]
>     <mailto:[email-masked]>>, Xuxiaohu
>     <[email-masked] <mailto:[email-masked]>>, Changcheng
>     Huang <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     So the chain ID is actually the path ID which represents an
>     ordered set of service function instances.
>
>     I think we should add an explicit definition of "service
>     instance". What do you think?
>
>     Thanks,
>
>     Cathy
>
>     *From:*sfc [mailto:[email-masked]] *On Behalf Of *Reinaldo
>     Penno (repenno)
>     *To: *"Paul Quinn (paulq)" <[email-masked]
>     <mailto:[email-masked]>>, David Allan I
>     <mailto:[email-masked]>>, Xuxiaohu
>     <[email-masked] <mailto:[email-masked]>>, Changcheng
>     Huang <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     Can you clarify the difference between service chain and service
>     path. Given that a service chain is composed
>
>     Chain ID should really be path ID since there can be many paths
>     for a given chain.  Using that definition, we avoid the overload
>     and reap the gain alluded to below.
>
>     Paul
>
>     *From:*sfc [mailto:[email-masked]
>     <mailto:[email-masked]>]*On Behalf Of*Changcheng Huang
>         I think that keeping the Service Path Layer transport
>         independent should remain an objective for SFC.  Such a
>         separation of concerns is a sound architectural principle that
>         On the question of  Service Path, we have a discussion on
>         whether we need some kind of explicit identifier or
>
>         Personally I think that having an explicit chain identifier
>         (e.g. Service Path/Service Index) is clear (management and
>         control) and not expensive (header space). The drawback being
>         some impact on the simplicity to add/remove elements in a
>         chain dynamically.
>
>         Tag switching (as MPLS)  allows to manage tags per service
>         nodes, leading to more versatile and diverse graphs
>
>         Nicolas
>
>         I like the idea of separating the Service Function Layer and
>         the Service Path Layer, as proposed in
>         draft-rijsman-sfc-metadata-considerations. The role of the
>         Service Path Layer is just to steer the traffic along a
>         particular chain of service nodes which can be implemented by
>         existing tools for source routing, such as segment routing. As
>         such, it's not necessary to try to keep the Service Path Layer
>         *???**:[email-masked]
>         In section 4.8, we made a clear distinction between a service
>         path layer (steering packets hop by hop along the chain) and a
>         service function layer (convey metadata information of
>         interest to SFs). Terminology aside, it seems that such
>         layered view was agreed upon by many people on the mailing list.
>
>         Now this certainly does beg the question of solving BOTH
>         problems with the same (packet) encapsulation mechanism.
>         Notably when observing that many use cases could be satisfied
>         without SF-level metadata, or by using more out-of-band ways
>         to convey such SF metadata. And also when observing that
>         inband marking (e.g. packet headers) comes with various pros &
>         cons (some of the issues being identified in the draft, e.g.
>         sections 4.1 and 4.2).
>
>         I do agree with Maria. We may want to explore other options
>         for addressing the needs of the service path layer that do not
>         require an explicit chain-id of sorts.
>
>         In the draft, we concluded by stating "A productive path
>         forward could be to divide and conquer: to clearly separate
>         the problem of Service Function Path topology from the  
>         problem of [conveying SF] metadata". I do believe we should
>         explore such separation principle further.
>
>         I would imagine that if we made the Chain ID field in the
>         header be optional, yet still required a header and still
>         required that some indication of the chain be carried
>         somewhere in the packet (mpls label or vlan or whatever), that
>         the implementation would become overly complicated.  To do so
>         would be using SFC simply as a mechanism to carry meta data
>         and not at all for service chaining, which sounds counter
>         intuitive to me.
>
>         Maria,
>         metadata, but not for actual service chaining because you
>         already have a way to implement service chaining outside of
>         SFC?  Maybe I'm not following, but it seems to me that if you
>         were to upgrade your network to support SFC that you would
>         change from using your existing mechanism and start using SFC,
>         which is meant to provide support for service functions that
>         are not SFC aware.  There are a number of us who have
>         implemented, in one way or another, some sort of service
>         chaining, but I (I can at least speak for myself) am looking
>         to SFC not to enhance my current implementation, but to
>         replace it with something better while still maintaining my
>         core (non service function) infrastructure.
>
>         >>> On 3/14/14 10:26 AM, "Joel M. Halpern"
>         <[email-masked] <mailto:[email-masked]>> wrote:
>         >>>
>         >>>>> *Subject:* Re: [sfc]
>         <mailto:[email-masked]>>,"[email-masked] <mailto:[email-masked]%3e%3e,[email-masked]>
>         >>>>>   >>On 3/12/14, 5:13 PM, "Lucy yong"
>         <[email-masked] <mailto:[email-masked]>
>         ________________________________________ From:
>         >>>>> Ron
>         ________________________________________ From:
>         sfc mailing

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 19 Mar 2014 17:29:17 -0400

Does the use of path ID imply that the ingress classifier does all of the
instance load balancing for every service in the chain, rather than having
service instance load balancing occur at the point in the chain when each
given service function has been reached?

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, March 19, 2014 4:01 PM
To: Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

   Ron

[trim list]

-Dave

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

 *   Visibility (tracing)

    *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Ron Parker <[email-masked]>
Date: Wed, 19 Mar 2014 22:27:30 +0000

I think both approaches could be used.    The classifier could be aware of the multiple instances of service functions and make a local decision as to which one(s) to select and thereby back into which fully-specified path shall be followed.   But in another approach, the classifier could know about only a single load balancer which front ends some number of the service function instances.   Any combination of the two approaches could be utilized, even within the same service function path (i.e. path X = SF-A-1, SF-B-LB, SF-C-3, where SF-B-LB front ends some quantity of the actual SF-B instances).

   Ron

From: Kevin J Ma [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 5:29 PM
To: Ron Parker; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

   Ron

[trim list]

-Dave

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 19 Mar 2014 22:31:03 +0000

Yes, I don’t think a pathID implies any approach. The load balancing can be done at the ingress classifier or by a centralized management/control entity or at local SF or a combination of them.

Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, March 19, 2014 3:28 PM
To: Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

   Ron

   Ron

[trim list]

-Dave

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 19 Mar 2014 22:39:32 +0000

Lucy,

    >> I disagree this SFC architecture. We need to distinguish SF and
    >> forwarding component in SFC architecture, two has different roles.
    That is a good point.Personally to me SFC architecture deals with
    selection of path and then delivering flows, transactions or messages (whatever
     the unit of work is) along the graph. I was thinking of SF forwarding mechanism
     not the SERVICE in this context. The service could be anything, it
    could transform,inspect or drop pkts, flows, msgs and what not. However it
    does imply that service MUST return a chainID (the same one or a different one).
    Otherwise the  forwarding plane cannot always correlate the return traffic i.e.
      input  ....> SF_A ----> return
    with the original input traffic. If it is flow based yeah may be (that is what
     vlan based chaining do ).

    It might be good idea to allocate some fixed reserved numbers for chainID.
    If a SF wants to simply route to network (that is ditch the chain and go
   for the network) then it could use some reserved number to
    indicate that. It is bit premature to discuss this though. Just wanted to
    propose the idea to the group.

    >>Many SP people has expressed that they may want to use different ways to
    >>establish the SFC path, not rely on the info carried on packets. Should
    >>SFC solution allow that option?

    I would tend to say no. It does remind me of cartoon where Mr X decides to
    unify all 15 proposals to one and then they had to deal with 16 proposals.
    I think a standard should satisfy a large number of use case otherwise we
    have failed. It doesn't mean that this has to be the way as long as the
    alternative can address most of the use cases.

    Regards.

    Sumandra

________________________________
From: Lucy yong [[email-masked]]
Sent: Wednesday, March 19, 2014 11:12 AM
To: Sumandra Majee; [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Hi Sumandra,

Thanks,
Lucy

  1.  Explicit ordered list, something like FW-A :: TCP-OPT :: LB :: VideoOPT :: CGNAT.   There are two issues with this approach, first the length of graph is variable.  Also it implies bidirectional symmetry. It is often required but should not be mandatory.  Secondly changing this path/graph in at SF can be cumbersome.
  2.  Let the Control plane distribute the chainID <―> graph mapping. In this case each SF would have mapping of given a chainID what is my next hop. The chainID itself could be fixed size element. A SF can select a different path by changing the chaiID parameter.

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

On 3/14/14 12:55 PM, "Ron Parker" <[email-masked]<mailto:[email-masked]>> wrote:

>>>>>   >>information between SF^1s and between the network & SF^1s.
>>>>>   >>
>>>>>   >>

---

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

I want to be a little careful.  THere are two ideas tied together in 
approach 2 as Sumandra described them.  One of those two ideas seems to 
me to be a good idea, the other not.

2.1) Having the meaning of the path-ID set by the control.  That seems 
very sensible to me.

2.2) Having that mpaiing installed in the service functions.  The 
service functions are applications.  They have application state. 
Having them also hold the chain forwarding state (as was explicitly 
described in some earlier proposals) seem to me a very bad architecture. 
  Segregating this is why the proposed architecture draft separates the 
SF from the SFF.  If Some folks want to implement them together, that's 
fine.  But the structure and architecture should not assume that.

Yours,
Joel

On 3/19/14, 2:12 PM, Lucy yong wrote:
> But your description indicates that SF is aware of chainID and is
> responsible to forward packet to the next hop SF and select a different
> paths by changing the chained parameter. This means that we will only
> have single component, SF, in SFC architecture? (maybe two, classifier
> and SF).  I disagree this SFC architecture. We need to distinguish SF
> and forwarding component in SFC architecture, two has different roles.
>
> Another point, in option 2 approach, do we need mandate that the
> forwarding has to use the chainID?  Many SP people has expressed that
> they may want to use different ways to establish the SFC path, not rely
> on the info carried on packets. Should SFC solution allow that option?
>
> *Sent:* Wednesday, March 19, 2014 2:03 AM
> *To:* Cathy Zhang; Reinaldo Penno (repenno); Louis.Fourie; Paul Quinn
> (paulq); David Allan I
>     VideoOPT :: CGNAT.   There are two issues with this approach, first
>     the length of graph is variable.  Also it implies bidirectional
>     symmetry. It is often required but should not be mandatory.
>       Secondly changing this path/graph in at SF can be cumbersome.
>  2. Let the Control plane distribute the chainID <—> graph mapping. In
>     this case each SF would have mapping of given a chainID what is my
>     next hop. The chainID itself could be fixed size element. A SF can
>     select a different path by changing the chaiID parameter.
>
> Regards
>
> Sumandra
>
> <mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]
> <mailto:[email-masked]>>, David Allan I <[email-masked]
> given chain.  Using that definition, we avoid the overload and reap the
> gain alluded to below.
>
> Paul
>
> On Mar 18, 2014, at 12:14 PM, David Allan I <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>
>
> instance”…. If it defines an class we also need instance information, if
> it is currently overloaded to define class and instance IMO we have a
> problem….
>
> Dave
>
>     not expensive (header space). The drawback being some impact on the
>     simplicity to add/remove elements in a chain dynamically.
>
>     Path Layer is just to steer the traffic along a particular chain of
>     service nodes which can be implemented by existing tools for source
>     routing, such as segment routing. As such, it’s not necessary to try
>     to keep the Service Path Layer transport-independent and contain it
>     in the SFC header.
>
>     Best regards,
>
>     Xiaohu
>
>     *发件人**:*sfc [mailto:[email-masked]]*代表*Jerome Moisand
>     *发送时间:*2014年3月18日 1:03
>     Service Function Path topology from the   problem of [conveying SF]
>     metadata”. I do believe we should explore such separation principle
>     further.
>
>     indication of the chain be carried somewhere in the packet (mpls
>     label or vlan or whatever), that the implementation would become
>     overly complicated.  To do so would be using SFC simply as a
>     mechanism to carry meta data and not at all for service chaining,
>     which sounds counter intuitive to me.
>
>     Maria,
>     have a way to implement service chaining outside of SFC?  Maybe I'm
>     not following, but it seems to me that if you were to upgrade your
>     network to support SFC that you would change from using your
>     number of us who have implemented, in one way or another, some sort
>     of service chaining, but I (I can at least speak for myself) am
>     looking to SFC not to enhance my current implementation, but to
>     >On 3/14/14, 2:35 PM, "Joel M. Halpern" <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >>> On 3/14/14 10:26 AM, "Joel M. Halpern" <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>
>     >>>>> *To:[email-masked] <mailto:[email-masked]>;[email-masked]
>     >>>>> From: "Ken Gray (kegray)" <[email-masked] <mailto:[email-masked]>
>     >>>>> To: Lucy yong <[email-masked] <mailto:[email-masked]>
>     >>>>> CC: Nicolas BOUTHORS <[email-masked] <mailto:[email-masked]>
>     >>>>><mailto:[email-masked]>>,Jamal <mailto:[email-masked]%3e%3e,Jamal>Hadi
>     Salim <[email-masked] <mailto:[email-masked]>
>     >>>>><[email-masked] <mailto:[email-masked]>
>     >>>>> On 3/13/14 7:49 AM, "Lucy yong" <[email-masked] <mailto:[email-masked]>
>     >>>>>   >>On 3/12/14, 5:13 PM, "Lucy yong" <[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>> Cc: Jim Guichard (jguichar);[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>>>> (jguichar);[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>>>>>> Guichard (jguichar);[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>>>>>>>>> <[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>>>>>>>>> Jim Guichard (jguichar) [[email-masked] <mailto:[email-masked]>] Sent:
>     >>>>>   >>>>>>>>>>> Nicolas BOUTHORS;[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>
>     >>>>>   >>>>>>>>>>>>> (jguichar) [[email-masked] <mailto:[email-masked]>] Sent:
>     >>>>>   >>>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked]>>
>     >>>>>wrote:
>     >>>>>   >>>>>>>>>>>>>>
>     >>>>>   >>>>>>>>>>>>>> mailing [email-masked] <mailto:[email-masked]><mailto:[email-masked]>
>     >>>>>   >>>>>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]>
>     >>>>>   >>>>>>>>>> [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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 Mar 2014 19:26:15 -0400

I agree, with a small caveat.
The service chain identification should identify an instance as seen by 
the service chain forwarding mechanisms.  As has been discussed, there 
may be a load balancer and multiple pieces of software running on 
multiple VMs hidden behind what appears to be one instance from the SFC 
perspective.  As long as it interfaces properly, that should be fine.

(Put differently, even if we claim it is one real instances, people will 
build solutions that do all sorts of things outside our purview.  We 
should recognize and accept that.)

Yours,
Joel

On 3/18/14, 1:23 PM, Ron Parker wrote:
> I agree.   The chain id in the packet should represent a fully specified
> set of located service function instances.    It could be thought of as
> representing a stack of network locators (typically MAC or IP addresses).
>
>      Ron
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Changcheng Huang
> *Sent:* Tuesday, March 18, 2014 12:28 PM
> *To:* 'David Allan I'; 'Nicolas BOUTHORS'
> *Cc:* 'Xuxiaohu'; [email-masked]; [email-masked]
> *Subject:* Re: [sfc] 答复: SFC encapsulation chain ID
>
> *From:*David Allan I [mailto:[email-masked]]
> *Sent:* Tuesday, March 18, 2014 9:15 AM
> *To:* Changcheng Huang; Nicolas BOUTHORS
> *Cc:* Xuxiaohu; [email-masked] <mailto:[email-masked]>; [email-masked]
> *Subject:* RE: [sfc] 答复: SFC encapsulation chain ID
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Changcheng Huang
> *Sent:* Tuesday, March 18, 2014 7:43 AM
> *To:* Nicolas BOUTHORS
> *Cc:* Xuxiaohu; [email-masked] <mailto:[email-masked]>; [email-masked]
> *Subject:* Re: [sfc] 答复: SFC encapsulation chain ID
>
>     *Sent:* Tuesday, March 18, 2014 5:04 AM
>     *To:* Jerome Moisand; [email-masked] <mailto:[email-masked]>;
>     *Subject:* [sfc] 答复: SFC encapsulation chain ID
>
>     *发件人**:*sfc [mailto:[email-masked]] *代表 *Jerome Moisand
>     *发送时间**:*2014年3月18日1:03
>     *收件人**:[email-masked] <mailto:[email-masked]>;
>     *主题**:*Re: [sfc] SFC encapsulation chain ID
>
>     *From:*sfc [mailto:[email-masked]] *On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>     *Sent:* Friday, March 14, 2014 5:50 PM
>     *To:* [email-masked] <mailto:[email-masked]>
>     *From: [email-masked]<[email-masked]
>     *To: *Ron Parker<[email-masked]
>     *cc: [email-masked]<[email-masked] <mailto:[email-masked][email-masked]>>
>     *Sent: *Friday, March 14, 2014
>     >>>>> *To:[email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     >>>>> *Cc:[email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>;
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]%3e%3e,%22Surendra> Kumar (smkumar)"
>     >>>>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>,"Jim
>     <mailto:[email-masked]%3e%3e,%22Jim> Guichard
>     >>>>>(jguichar)"
>     >>>>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]%3e%3e,sfc> <[email-masked]
>     <mailto:[email-masked]>
>     >>>>><mailto:[email-masked]>>,Jamal <mailto:[email-masked]%3e%3e,Jamal> Hadi
>     >>>>><mailto:[email-masked]>>,Ron <mailto:[email-masked]%3e%3e,Ron>
>     Parker
>     <mailto:[email-masked]%3e%3e,%22Joel> M. Halpern"
>     >>>>><[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>
>     >>>>>
>     >>>>>   >>[email-masked] <mailto:[email-masked]>
>     >>>>>[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>; sfc;
>     >>>>>[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 [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     >>>>>   >>>>>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     >>>>>   >>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     >>>>>   >>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     >>>>>   >>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     >>>>>   >>>>>[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: Kevin Glavin <[email-masked]>
Date: Wed, 19 Mar 2014 23:34:43 +0000

+1 for option 2

#2

Kevin

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 20 Mar 2014 03:33:57 +0000

发件人: sfc [mailto:[email-masked]] 代表 Sumandra Majee
发送时间: 2014年3月19日 15:40
收件人: Cathy Zhang; Paul Quinn (paulq); David Allan I
抄送: [email-masked]
主题: Re: [sfc] SFC encapsulation chain ID

  1.  Explicit ordered list, something like FW-A :: TCP-OPT :: LB :: VideoOPT :: CGNAT.   There are two issues with this approach, first the length of graph is variable.  Also it implies bidirectional symmetry. It is often required but should not be mandatory.  Secondly changing this path/graph in at SF can be cumbersome.
[Xiaohu] The advantage of this option is that there is no need for each SF node to hold the mappings of  chain_ID(path_ID may be a better term)->an explicit ordered list of service nodes. Whether option 1 or option 2 should be preferred also depends on the total number of the explicit ordered list of service nodes available in a given network, IMHO. Such tradeoff seems similar with that in the explicit route case: if the total number of explicit routes available in a given number is small, the RSVP-TE LSP is a better choice. Otherwise, source routing (e.g., segment routing) seem more attractive since it doesn’t require intermediate nodes to maintain a lot of states.
Best regards,
Xiaohu

  1.  Let the Control plane distribute the chainID <—> graph mapping. In this case each SF would have mapping of given a chainID what is my next hop. The chainID itself could be fixed size element. A SF can select a different path by changing the chaiID parameter.

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 20 Mar 2014 04:01:27 +0000

发件人: sfc [mailto:[email-masked]] 代表 Changcheng Huang
发送时间: 2014年3月19日 22:23
收件人: Paul Quinn (paulq)
抄送: David Allan I; Sumandra Majee; [email-masked]
主题: Re: [sfc] SFC encapsulation chain ID

[Xiaohu] Whether the overhead of carrying explicit path information (i.e., an ordered list of nodes) is heavy or not,  supporters for the SR mechanism, especially those for IPv6-SR mechanism (http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-cases-00) may have different opinions☺

Best regards,
Xiaohu

Chang

------------
Changcheng Huang

On Mar 19, 2014, at 5:44 AM, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sumandra,

Paul

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: Ian Smith <[email-masked]>
Date: Thu, 20 Mar 2014 04:27:00 +0000

While I think you are correct that a path through a service chain has a lot in common with source routing, and I strongly believe we should seek to understand what makes source routing undesirable not just for SFC but for networking in general and apply those lessons, I don't think that this statement about each node having to hold the entire sequence of nodes is _necessarily_ a requirement for option one.

All that is required for either option is that a particular instance of a function be able to determine the next hop for that instance of the chain.  There are a number of ways to do this, and one of them is to have the complete path as a sequenced list of addresses, but there are others and I don't think that it really matters, at an architectural level, _how_ a service function instance arrives at the decision for the next hop as long as the _outcome_ is correct.

It seems to me a short amount of brainstorming will yield four or five mature variations of making a table lookup or reading a list that could easily be used to pick a next hop, and none of them are _necessarily_ better than the others when you don't actually have an implementation in front of you.  What matters is that the particular method being used is able to glean the necessary information (for this pathID, from this service function, what is the next hop?) from any combination of the network, the control plane, a discovery service, or the configuration.  Or it could just hand it back to the physical host / service function forwarder / ADC and let that function deal with it, which is how I imagine that legacy "stuff" will have to be managed.

What seems important at this point, is that we are able to articulate the decision that the service function instance is expected to make when it is done doing what ever it does and is ready to pass the packet/message along, what information required to make that decision, and which vectors MAY be used to provide that information to the service function instance, and what happens when some or all of that information is missing, invalid, or wrong.  That articulation must be general enough to cover the campus, data center, broadband, and mobile use cases, so there is room for variations, but we also have to make it simple enough that interoperability is not sacrificed for flexibility or through loose vendor interpretation.

I encourage people to look at the very nice presentation that Ross Callon made in London and focus on option 5, which seems to be the only method capable of satisfying all four major use cases.  http://www.ietf.org/proceedings/89/slides/slides-89-sfc-8.pptx   In some cases (like a campus LAN) the control plane will be weak and the forwarding plane will have to carry more information, it other cases (like a mobile network or a virtualized data center) a strong control plane will let the forwarding plane carry little or no information; we must be able to use both - this isn't either/or.

________________________________
From: sfc [[email-masked]] on behalf of Xuxiaohu [[email-masked]]
Sent: Wednesday, March 19, 2014 11:33 PM
To: Sumandra Majee; Cathy Zhang; Paul Quinn (paulq); David Allan I
Cc: [email-masked]
Subject: [sfc] 答复: SFC encapsulation chain ID

  1.  Let the Control plane distribute the chainID <―> graph mapping. In this case each SF would have mapping of given a chainID what is my next hop. The chainID itself could be fixed size element. A SF can select a different path by changing the chaiID parameter.

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

-          Louis

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Thu, 20 Mar 2014 07:40:21 +0000

+1

Technology Exploration -

mailto:[email-masked]

De: "Diego R. Lopez" <[email-masked]<mailto:[email-masked]>>
Fecha: miércoles 19 de marzo de 2014 13:38
Para: Ron Parker <[email-masked]<mailto:[email-masked]>>
CC: David Allan I <[email-masked]<mailto:[email-masked]>>, Cathy Zhang <[email-masked]<mailto:[email-masked]>>, "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, Sumandra Majee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [sfc] SFC encapsulation chain ID

Be goode,

Sumandra,

   Ron

Regards
Sumandra

Hi Reinaldo,

Thanks,
Cathy

Paul,

Hi Dave,

Paul

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 20 Mar 2014 11:13:46 +0100

Hi,

>     select a different path by changing the chaiID parameter.

I'm also for option 2: it's probably not necessary to have such a
high flexibility/dynamics to change the graph between SF hops.
The 2nd approach nevertheless allows to use subgraphs or change
graphs if this is necessary, by changing the chainID.

Regards,
 Roland

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 20 Mar 2014 23:50:11 +0000

Good point. Segment routing should work equally for services that are at the edge and for services that are in the middle.

Maria

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Tuesday, March 18, 2014 9:05 PM
To: Ron Parker; Changcheng Huang; 'David Allan I'; 'Nicolas BOUTHORS'
Cc: [email-masked]; [email-masked]
Subject: [sfc] 答复: 答复: SFC encapsulation chain ID

Best regards,
Xiaohu

    Ron

Chang

Dave

Chang

------------
Changcheng Huang

  *   Visibility (tracing)

     *   LBS / scale out impact

Nicolas

Best regards,
Xiaohu

Maria,

---

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

Mike,

Maria,
So, you are saying that you want to use SFC to carry around metadata, but not for actual service chaining because you already have a way to implement service chaining outside of SFC?
Yes.
Maybe I'm not following, but it seems to me that if you were to upgrade your network to support SFC that you would change from using your existing mechanism and start using SFC, which is meant to provide support for service functions that are not SFC aware.
There should be a way to use the NSH only as a way to convey metadata such as subscriber-id, application-id, etc., while keeping the service chaining forwarding information at, e.g., the MPLS VPN level.
There are a number of us who have implemented, in one way or another, some sort of service chaining, but I (I can at least speak for myself) am looking to SFC not to enhance my current implementation, but to replace it with something better while still maintaining my core (non service function) infrastructure.
"service-chaining" is nothing new, it has been done for the many years using VLANs. The issue has been always how to bring the traffic from a routed network into a set of appliances, i.e., how to integrate with routing. By using the same mechanism in the intermediate hops the complexity is significantly reduced.

IMO, the signaling of metadata should be independent from signaling of service path. There can be many ways to signal the path so why tie the two together.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 24 Mar 2014 01:21:19 +0000

+1

Xiaohu

发件人: sfc [mailto:[email-masked]] 代表 NAPIERALA, MARIA H
发送时间: 2014年3月22日 6:38
收件人: [email-masked]; [email-masked]
主题: Re: [sfc] SFC encapsulation chain ID

Mike,

Maria,

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 24 Mar 2014 16:37:25 +0000

+1.

We could generalize the existing VLAN-based approach to more flexible tunnel/overlay thinking and a set of distributed constrained routes using a control logic of sorts. No need for an explicit service chain (or path) id, then. While staying transport-independent (that’s the whole point of overlays).

Love this quote from Maria, this is putting it very clearly and very concisely.

<< the signaling of metadata should be independent from signaling of service path. There can be many ways to signal the path so why tie the two together.>>

I would just add that there are probably even more ways to signal metadata than to signal the (service) path…

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Sunday, March 23, 2014 9:21 PM
To: NAPIERALA, MARIA H; [email-masked]; [email-masked]
Subject: [sfc] 答复: SFC encapsulation chain ID

+1

Xiaohu

Mike,

Maria,

---

From: Ron Parker <[email-masked]>
Date: Mon, 24 Mar 2014 16:48:32 +0000

Clearly, an SFC encapsulation can be used “off label” to support an inband metadata transport mechanism outside of the SFC steering paradigm.  And, I’m in no way trying to dissuade such a usage.    But, since the steering part of the header is likely to be simple, compact, and of fixed length, why not just ignore it in such a case – send 0’s, ignore received fields.   Wouldn’t this keep things simpler than trying to add yet more flexibility into a unified header?    Additionally, might we run into charter issues if the header can explicitly convey “non-SFC-compliant” (e.g., the charter is quite explicit that we are solving a steering problem)?

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Jerome Moisand
Sent: Monday, March 24, 2014 12:37 PM
To: Xuxiaohu; NAPIERALA, MARIA H; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

+1.

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Sunday, March 23, 2014 9:21 PM
To: NAPIERALA, MARIA H; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [sfc] 答复: SFC encapsulation chain ID

+1

Xiaohu

Mike,

Maria,

---

From: Cathy Zhang <[email-masked]>
Date: Mon, 24 Mar 2014 17:26:50 +0000

To add on what Ron said, while one can choose to generalize VLAN based approach, an explicit service chain header with a compact fixed length chain(path) ID field that is not tied to VLAN,
and could be transferred inband over any transport (including tunnel/overlay) will be more generic and will simplify the operation on many SFC entities.

Cathy

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, March 24, 2014 9:49 AM
To: Jerome Moisand; Xuxiaohu; NAPIERALA, MARIA H; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

   Ron

+1.

+1

Xiaohu

Mike,

Maria,

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 24 Mar 2014 19:15:32 +0000

Interesting idea. Could indeed be the best of both worlds. Then we probably should allow a header-less behavior as well as null-header though, semantically equivalent (signaled). While keeping the explicit header behavior.

A bit of a ‘do it all’ compromise, but I can see the value of it…

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, March 24, 2014 12:49 PM
To: Jerome Moisand; Xuxiaohu; NAPIERALA, MARIA H; [email-masked]; [email-masked]
Subject: RE: [sfc] 答复: SFC encapsulation chain ID

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Jerome Moisand
Sent: Monday, March 24, 2014 12:37 PM
To: Xuxiaohu; NAPIERALA, MARIA H; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

+1.

+1

Xiaohu

Mike,

Maria,

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Mar 2014 12:20:22 -0700

> given service function has been reached?

Kevin et al,

I get the impression that different participants might be using terms 
like "node" and "instance" to mean slightly different things as it comes 
to load balancing, and your email is a reasonable place to interject 
that observation.

Let me give to examples to illustrate the possibly different interpretation.
In both cases on ingress to SFC the classification directs the the 
packet to a service path. These examples use "tenant" as the 
distinguishing characteristics, but it could also be e.g., "subscriber" 
or "class-of-service", or any combination of those.

In the first example the packets for tentantA are associated with a 
service path containing FW-A etc. In this case FW-A is the instance of 
the FW service; that instance has tenantA's specific firewall 
configuration. That is distinct from the FW class, which is a firewall 
without any instantiation with any firewall policy. (And "FW" might 
actually be more specific - having a distinct set of firewalling 
capabilities and features, but still devoid of the tenant config.)

 From a service graph perspective FW-A is on a node - but that graph 
node doesn't necessarily map to a single physical node.
The implementation of the FW-A could  be done using multiple FW virtual 
machines - on the same or different physical nodes. We can call them 
FW-A-1 and FW-A-2 etc. Such load balancing could be a local matter to 
the implementation of FW, or it could perhaps leverage SFC.

In the second example the instance is one level down. FW-A-1 and FW-A-2 
would be different instances, with different service paths to reach 
them. Thus the SFC ingress classifier would pick a path for some traffic 
which using one of those instances. Thus SFC would have more visibility 
and control in how traffic is load balanced (for the firewall in this 
case). However, that also means SFC needs to handle failures to FW-A-1 
by knowing the rules for which FW-A-* instance to re-route the packets 
to, which implies some coupling between SF specific state and SFC.

Some of the concerns on the list seem to assume that "instance" means 
the second approach, which brings in more possibilities but also more 
complexity.

It might make sense to start with the first approach. But in any case, 
making it more clear (perhaps by using concrete examples like the above) 
what is an instance and a node would help the discussion.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Mar 2014 12:23:32 -0700

On 3/19/14 4:26 PM, Joel M. Halpern wrote:
> The service chain identification should identify an instance as seen 
> by the service chain forwarding mechanisms.  As has been discussed, 
> there may be a load balancer and multiple pieces of software running 
> on multiple VMs hidden behind what appears to be one instance from the 
> SFC perspective.  As long as it interfaces properly, that should be fine.
>
> (Put differently, even if we claim it is one real instances, people 
> will build solutions that do all sorts of things outside our purview.  
> We should recognize and accept that.)
Joel,
I agree with your approach and observation.

Key is determining what the interface would be. Today load balancers 
"hide" behind a single virtual IP address (and associated MAC address) 
and that can continue to be the case for service functions that want 
their internal load balancing to be invisible to SFC. Question is 
whether there should also be an interface by which service functions can 
expose their internal load balancing to SFC.

Regards,
     Erik

>> *Jmh.direct
>> <mailto:[email-masked]>;
>> <mailto:[email-masked]%3e%3e,Jamal> Hadi
>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>     >>>>>wrote:
>>     >>>>> >>>>>>>>>>>>>>
>> <mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 24 Mar 2014 17:24:19 -0400

First, I think it is important to keep in mind that we are likely not 
going to be able to mandate the granularity at which folks build things.

As far as I can tell, the fact that the chain goes to a firewall may 
mean that is a generic firewall which uses header information or 
metadata to select the policy or it may be a firewall that is specific 
to the rules used by tenant A.

Similarly, the actual instantiation in the chain may be a single VM, or 
it may be a cluster with internal load balancing that interacts with the 
service chain as a single thing.
And further, there may be several such clusters, each used in different 
service chains.

 From an architecture perspective, we have to allow these.
I do however think we should be wary of taking the single-instance 
detail-policy approach too far.  If there are several service functions, 
each with several policies or instances which are chosen to be used 
sparately by the chaining, then the number of service paths grows 
exponentially.

In a different note Eric asked about addressing the individual 
instances.  For the purposes of service chaining, it is not obvious that 
there is any need to ddress the internal instances if they are deployed 
as an internal cluster.  The question of what addressing they need for 
configuration or other control protocols would seem to be outside of SFC 
scope.  And for data path addressing, they are identified by whatever 
the transport needs, which may be an IP address an Ethernet Address, an 
MPLS label, or who knows what.

Yours,
Joel

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Mon, 24 Mar 2014 21:55:16 +0000

Future SFC aware applications would benefit from reading data from the SFC header if any.

So the question is not only to be able to infer a chain id in a header-less configuration,  but also to be able to retrieve contextual information.
I don't see how we could achieve this if we are to carry say a policy identifier or an app id and a subscriber identifier in such a case.

In the end the options (fix header, header-less,..) are not equivalent in terms of features.

Shouldn't the focus of the work we provide be on the richer model, and consider other cases as valid options provided some identified limitations.

________________________________
From: Jerome Moisand [[email-masked]]
Sent: Monday, March 24, 2014 8:15 PM
To: [email-masked]
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

   Ron

+1.

+1

Xiaohu

Mike,

Maria,

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 25 Mar 2014 00:48:24 +0000

Erik,

I generally agree with your observation. To me a service a blob and the
blob may have built on many instances of the service. Service path graph
should not be in the business of picking up a specific instances of the
service. Lets look at an example,

   ‹‹ FW  ‹‹ LB  ‹---------- FW
            Video opt
            Servers

The desired service chain is : Security <‹> Video Opt  <‹> FW and the
actual chain is,
  Security <‹> LB VIP for video opt <‹> FW

This sort of makes LB a critical component of SFC.

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 25 Mar 2014 00:59:38 +0000

Agree.

I personally look at a chainID as yet another indirection that enables programatic control over the path. Most VLAN based stitching is pretty static and debugging is not an easy task.

>>I would just add that there are probably even more ways to signal metadata than to signal the (service) path…
Yes. However the in band part of the signaling should be standardized.

From: Ron Parker <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 24, 2014 at 9:48 AM
To: Jerome Moisand <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "NAPIERALA, MARIA H" <[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] 答复: SFC encapsulation chain ID

   Ron

+1.

+1

Xiaohu

发件人: sfc [mailto:[email-masked]] 代表NAPIERALA, MARIA H
发送时间: 2014年3月22日 6:38
收件人:[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [sfc] SFC encapsulation chain ID

Mike,

Maria,

---

From: "He, Peng" <[email-masked]>
Date: Mon, 24 Mar 2014 21:16:47 -0400

Thanks Erik .. Does that mean the first approach basically excludes or hides LB from service path graph? i.e., treating it as a local matter?

Regards,
Peng

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Monday, March 24, 2014 3:20 PM
To: Kevin J Ma; Ron Parker; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Kevin et al,

I get the impression that different participants might be using terms like "node" and "instance" to mean slightly different things as it comes to load balancing, and your email is a reasonable place to interject that observation.

Let me give to examples to illustrate the possibly different interpretation.
In both cases on ingress to SFC the classification directs the the packet to a service path. These examples use "tenant" as the distinguishing characteristics, but it could also be e.g., "subscriber" 
or "class-of-service", or any combination of those.

In the first example the packets for tentantA are associated with a service path containing FW-A etc. In this case FW-A is the instance of the FW service; that instance has tenantA's specific firewall configuration. That is distinct from the FW class, which is a firewall without any instantiation with any firewall policy. (And "FW" might actually be more specific - having a distinct set of firewalling capabilities and features, but still devoid of the tenant config.)

 From a service graph perspective FW-A is on a node - but that graph node doesn't necessarily map to a single physical node.
The implementation of the FW-A could  be done using multiple FW virtual machines - on the same or different physical nodes. We can call them
FW-A-1 and FW-A-2 etc. Such load balancing could be a local matter to the implementation of FW, or it could perhaps leverage SFC.

In the second example the instance is one level down. FW-A-1 and FW-A-2 would be different instances, with different service paths to reach them. Thus the SFC ingress classifier would pick a path for some traffic which using one of those instances. Thus SFC would have more visibility and control in how traffic is load balanced (for the firewall in this case). However, that also means SFC needs to handle failures to FW-A-1 by knowing the rules for which FW-A-* instance to re-route the packets to, which implies some coupling between SF specific state and SFC.

Some of the concerns on the list seem to assume that "instance" means the second approach, which brings in more possibilities but also more complexity.

It might make sense to start with the first approach. But in any case, making it more clear (perhaps by using concrete examples like the above) what is an instance and a node would help the discussion.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Mar 2014 23:51:38 -0700

> Thanks Erik .. Does that mean the first approach basically excludes or hides LB from service path graph? i.e., treating it as a local matter?
Peng,
Given that LBs can be "hidden" inside a service instance, then a fair 
amount of the load balancing need can be taken care of using that local 
approach.

But there might be benefits to supporting a more "global" load balancing 
as well which would be visible in the service path graph. But it means 
that the motivation for such a "global" load balancing must be different 
than a simple "we need load balancing".

Perhaps there are parallels with the web server load balancing that 
developed as the web developed? In that world there was (and still is 
AFAIK) a local load balancing function within one datacenter, but also a 
global load balancing function which serves a different purpose. One can 
envision a SFC global/visible "load balancer" which might run at the 
mobile edge and
  - handles failures of different datacenters (i.e., disasters), and
  - picks a datacenter based on the location of the client (and not on 
the load of the service)

Regards,
    Erik

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 25 Mar 2014 14:54:28 +0000

Hi Erik,

On Mar 24, 2014, at 3:20 PM, Erik Nordmark <[email-masked]> wrote:

> In both cases on ingress to SFC the classification directs the the packet to a service path. These examples use "tenant" as the distinguishing characteristics, but it could also be e.g., "subscriber" or "class-of-service", or any combination of those.
> 
> The implementation of the FW-A could  be done using multiple FW virtual machines - on the same or different physical nodes. We can call them FW-A-1 and FW-A-2 etc. Such load balancing could be a local matter to the implementation of FW, or it could perhaps leverage SFC.
> 

If the service function handles load balancing between like elements (e.g. clustered FWs), then to SFC, that can look like one SF with varying capacity.  The handling of the instances within the cluster is outside the scope of SFC, and if the cluster (for lack of a better term) presents a single locator to SFC, SFC can, and should treat the cluster as a SF.

> In the second example the instance is one level down. FW-A-1 and FW-A-2 would be different instances, with different service paths to reach them. Thus the SFC ingress classifier would pick a path f…

This is closer to my definition of instance: an instance presents, to SFC, in the simplest case, a network locator.  That locator is then used to construct the service path.   There is no limitation on presenting several locators for like services for load distribution, and redundancy.  So, a path need no be mapped to a single set of locators, rather a list of locators maybe used to select (locally or centrally) the correct instance along the path.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 25 Mar 2014 14:59:09 +0000

Hi,

>  Security <‹> LB VIP for video opt <‹> FW

Indeed, however, I suggest that to be truly accurate, the chain, at the policy layer, would in this case specify LB as part of the chain since LB is a distinct SF.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Tue, 25 Mar 2014 15:10:57 +0000

Programmatic control does not necessarily imply an existence of an explicit unique path or chain ID carried in a packet.  Lack of an explicit unique path ID in a packet does not imply VLAN stitching.

Maria

From: Sumandra Majee [mailto:[email-masked]]
Sent: Monday, March 24, 2014 9:00 PM
To: Ron Parker; Jerome Moisand; Xuxiaohu; NAPIERALA, MARIA H; [email-masked]; [email-masked]
Subject: Re: [sfc] 答复: SFC encapsulation chain ID

Agree.

   Ron

+1.

+1

Xiaohu

Mike,

Maria,

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Mar 2014 11:24:52 -0700

> If the service function handles load balancing between like elements (e.g. clustered FWs), then to SFC, that can look like one SF with varying capacity.  The handling of the instances within the cl…

Paul,
Yes, just like when e-commerce websites were developed, the load 
balancer+web servers can be hidden bind a single locator.
SFC wouldn't care - and wouldn't see such hidden load balancing.

> This is closer to my definition of instance: an instance presents, to SFC, in the simplest case, a network locator.  That locator is then used to construct the service path.   There is no limitatio…

I don't think using the existence of the network locator as that helpful 
in coming up with crisp definitions.
Even for the FW-A case above it would be identified by a network 
locator. And the CPU temperature sensor on server3 has a network locator 
as well (composed of MAC address and I2C address for instance). I 
suspect the essence of their differences has more to do with state than 
how they are addressed.

It feels like we might need different terms to describe the two cases of 
"instances":
  - an instance (such as FW-A) of the class (FW) which is specific for a 
given tenant, subscriber, etc. In the cases I can think of that instance 
has some configuration/policy which is specific to "A". Thus FW-B is 
different than FW-A in its config/policy.
  - an instance of a SFC-visible load balanced entity (such as FW-A-1). 
In the examples I can think of all of those FW-A-* would be identical 
and exist to balance and adjust to load. From a config/policy 
perspective we could consider calling these "replicas" to capture that 
they are identical.

Note that the FW-A-* are likely to contain some operational/session 
state (think of a NAT or a FW which maintains state for TCP connections).

Other suggestions for crisp terminology to describe this?

Note that the existence of operational/session state means that when 
load balancing is visible to SFC, then something in SFC needs to be able 
to ensure the appropriate stickiness (term from http load balancers; 
might be based on client IP address, or http cookie in the web world) so 
that the packet flows are not accidentally sent to the wrong replica. 
That would require some SF-specific awareness in SFC.

Regards,
    Erik

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 26 Mar 2014 07:06:17 +0000

Erik,

Your examples are essentially describing load balancing at two levels:
A) servcie-graph-node
B) servcie-path

SFC SHOULD allow them both and let implementations deal with the
complexities.

Surendra.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 13:53:34 +0000

> And further, there may be several such clusters, each used in different

Actually, we cannot assume that services will come with their own internal load balancing. Hence, any SFC solution needs to support the load balancing to a cluster.  The main problem in service chaining is how to implement a service that is conceptually one hop but scaled horizontally as 10 or 100 different VMs.
 
> sparately by the chaining, then the number of service paths grows

Yes. This will not scale.
 
Maria

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 14:00:21 +0000

Maria,

I don't see any ambiguity, here.   An SF instance can be anything we want it to be.   In the case of internal load balancing, that single SF instance would presumably have higher capacity than if it were not internally load balanced, but the SFC classifier/PDP need not know anything about that.     It could even be hierarchical.   Let's say that some service function is realized with an internally load balanced cluster of VMs or physical hosts.    And, lets further say that there are 3 such clusters available.   The SFC classifier/PDP would see that there are 3 network locators for that service function.   The policies used by the SFC classifier/PDP to select amongst those 3 is private to the classifier/PDP.   The fact that each of those instances performs internal load balancing is not relevant to the operation of the SFC classifier/PDP, except, perhaps, to flavor the way the policy used for selection is expressed (i.e., if they have dissimilar capacities).

    Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 9:54 AM
To: Joel M. Halpern; Erik Nordmark; Kevin J Ma; Ron Parker; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

> Similarly, the actual instantiation in the chain may be a single VM, 
> or it may be a cluster with internal load balancing that interacts 
> with the service chain as a single thing.
> And further, there may be several such clusters, each used in 

> detail-policy approach too far.  If there are several service 
> functions, each with several policies or instances which are chosen to 
> be used sparately by the chaining, then the number of service paths 
> grows exponentially.

Maria

> >> service instance load balancing occur at the point in the chain 
> >> when
> each
> >>
> > I get the impression that different participants might be using 
> > terms like "node" and "instance" to mean slightly different things 
> > as it
> comes
> > FW-A-1 and FW-A-2 etc. Such load balancing could be a local matter 
> > to the implementation of FW, or it could perhaps leverage SFC.
> >
> >
> > and control in how traffic is load balanced (for the firewall in 
> > this case). However, that also means SFC needs to handle failures to 
> > FW-A-
> 1
> > Some of the concerns on the list seem to assume that "instance" 
> > means the second approach, which brings in more possibilities but 
> > also more complexity.
> >

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 14:08:32 +0000

Ron,

I said that we cannot assume that within a cluster there is will be some sort of internal load balancing. Hence, an SFC solution should account/include the load balancing to specific instances within a cluster.

Maria

> Sent: Wednesday, March 26, 2014 10:00 AM
> To: NAPIERALA, MARIA H; Joel M. Halpern; Erik Nordmark; Kevin J Ma;
> Dave Dolson; Sumandra Majee
> Cc: [email-masked]
> I don't see any ambiguity, here.   An SF instance can be anything we
> want it to be.   In the case of internal load balancing, that single SF
> instance would presumably have higher capacity than if it were not
> internally load balanced, but the SFC classifier/PDP need not know
> anything about that.     It could even be hierarchical.   Let's say
> that some service function is realized with an internally load balanced
> cluster of VMs or physical hosts.    And, lets further say that there
> are 3 such clusters available.   The SFC classifier/PDP would see that
> there are 3 network locators for that service function.   The policies
> used by the SFC classifier/PDP to select amongst those 3 is private to
> the classifier/PDP.   The fact that each of those instances performs
> internal load balancing is not relevant to the operation of the SFC
> classifier/PDP, except, perhaps, to flavor the way the policy used for
> selection is expressed (i.e., if they have dissimilar capacities).
> 
>     Ron
> 
> 
> Actually, we cannot assume that services will come with their own
> internal load balancing. Hence, any SFC solution needs to support the
> load balancing to a cluster.  The main problem in service chaining is
> how to implement a service that is conceptually one hop but scaled
> horizontally as 10 or 100 different VMs.
> 
> > >> instance load balancing for every service in the chain, rather
> than
> > >> having
> > >>
> > > In the second example the instance is one level down. FW-A-1 and
> FW-
> > A-2

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 14:13:08 +0000

Maria,

That is exactly what I tried to bring out in my example where the SFC classifier/PDP is load balancing amongst 3 SF instances.

   Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 10:09 AM
To: Ron Parker; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Ron,

Maria

> > >> Does the use of path ID imply that the ingress classifier does 
> > >> all
> > of the
> > >>
> > > In the first example the packets for tentantA are associated with 
> > > a service path containing FW-A etc. In this case FW-A is the 
> > > instance
> > of
> > > without any instantiation with any firewall policy. (And "FW" 
> > > might actually be more specific - having a distinct set of 
> > > firewalling capabilities and features, but still devoid of the 
> > > tenant config.)
> > >
> > > would be different instances, with different service paths to 
> > > reach them. Thus the SFC ingress classifier would pick a path for 
> > > some
> > traffic

---

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

1) given the range of load balancing behaviors, supprting explicit load 
balancers in the service chaining (as distinct from supporting load 
balancers for end users), is significantly complicate

2) I would expect us to ensure that nothing we do prohibits internal 
load balancers

3) Given what we are currently describing, the granularity of deployment 
is up to the deployer.  We are not currently mandating the granularity, 
so the fine grained approach you have asked for is consistent with the 
problem statement, architecture proposals, and format proposals.

Yours,
Joel

On 3/26/14, 9:53 AM, NAPIERALA, MARIA H wrote:
>> functions,

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 14:56:11 +0000

> balancers for end users), is significantly complicate

I am not sure I understand this point. Could you explain what you mean by "explicit" load balancer vs. load balancer "for the end users"?
 
> 2) I would expect us to ensure that nothing we do prohibits internal

Absolutely. But we cannot assume that all SFs come with internal LB.
 
> or
> different
> terms
> this
> >>> case). However, that also means SFC needs to handle failures to FW-
> A-
> >> 1
> means

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 26 Mar 2014 11:00:55 -0400

The point of the distinction was between on the one hand load balancing 
as part of the chain for the purpose of selecting an instance of the 
actually addressed destination (i.e. the load balancer is visible to the 
tenant and is there for the purpose the tenant request; and on the other 
hand a load balancer which is known to the service chaining 
infrastructure, but whose purpose to balance across isntances of 
services whose multiplicity is not of concern to the tenant, only the 
functionality.

Put differently, it is between load balancing as an explicit service and 
load balancing to enable some service within the service chaining.

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 15:16:57 +0000

Joel, 

> load balancing to enable some service within the service chaining.

Thanks for clarification. 
My concern is about the latter, i.e., SFC solution must support load balancing to multiple service instantiations (e.g., VMs) of a single service at the intermediate service hops. In fact, we need the latter to support the former..

Maria

> > I am not sure I understand this point. Could you explain what you
> mean by "explicit" load balancer vs. load balancer "for the end users"?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Mar 2014 11:24:33 -0400

Given that we have mechanisms which allow service functions to direct 
modification of the service chain identification (preferably through 
metadata, but that is still under discussion) then it follows that the 
current proposals allow a load balancer which directs the chaining, and 
which modifies the packet if needed to affect external targeting.

While I would prefer and expect that to be rarely used, it is allowed. 
And I do not expect the documents to express a preference (for or 
against my personal preference.)

Given that you agree that we can also do internal load balancing, I 
don't understand what changes you are requesting.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 15:28:27 +0000

Maria,

So long as the architecture is properly layered, this distinction becomes a network design decision.   The SFC classifier/PDP, will, indeed, have the ability to select amongst multiple instances.    It need not know why there are multiple instances.   I'll give a few examples of how multiple instances, as seen by the classifier/PDP, would arise based on network design choices.

1.  A service function is realized by multiple VM's where each VM has its own IP address.   In this case the classifier/PDP sees each VM as a service function instance.

2. A service function, as above, but some subset of VM's is front-ended by a load balancer.   There are multiple such subsets and therefore multiple load balancers.   Each load balancer has its own IP address and hides the VM IP addresses behind it.   In this case, the classifier/PDP sees each load balancer as a service function instance.

3.  A service function is realized by a set of VM's that perform internal load balancing.   The set of VM's presents a single IP address to the outside to hide the IP addresses of the individual VMs.   The network has multiple such clusters.   The classifier/PDP sees each cluster as a service function instance.

4.  Any combination of the above.   Or any other scenario you can envision.

Thanks.

    Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 11:17 AM
To: Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Ron Parker; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Joel, 

> The point of the distinction was between on the one hand load 
> balancing as part of the chain for the purpose of selecting an 
> instance of the actually addressed destination (i.e. the load balancer 
> is visible to the tenant and is there for the purpose the tenant 
> request; and on the other hand a load balancer which is known to the 
> service chaining infrastructure, but whose purpose to balance across 
> isntances of services whose multiplicity is not of concern to the 
> tenant, only the functionality.
>
> Put differently, it is between load balancing as an explicit service 
> and load balancing to enable some service within the service chaining.
> 

Maria

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 15:39:03 +0000

> 
> 1.  A service function is realized by multiple VM's where each VM has
> its own IP address.   In this case the classifier/PDP sees each VM as a
> service function instance.
> 

I don't think this will scale. It was pointed out that the number of service paths grows exponentially. 

> 2. A service function, as above, but some subset of VM's is front-ended
> by a load balancer.   There are multiple such subsets and therefore
> multiple load balancers.   Each load balancer has its own IP address
> and hides the VM IP addresses behind it.   In this case, the
> classifier/PDP sees each load balancer as a service function instance.

No issue here.

> 3.  A service function is realized by a set of VM's that perform
> internal load balancing.   The set of VM's presents a single IP address
> to the outside to hide the IP addresses of the individual VMs.   The
> network has multiple such clusters.   The classifier/PDP sees each
> cluster as a service function instance.

> My concern is about the latter, i.e., SFC solution must support load
> balancing to multiple service instantiations (e.g., VMs) of a single
> service at the intermediate service hops. In fact, we need the latter
> to support the former..
> 
> Maria
> 
> >

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 26 Mar 2014 15:40:42 +0000

Hi Erik,

On Mar 25, 2014, at 2:24 PM, Erik Nordmark <[email-masked]>
 wrote:

> Yes, just like when e-commerce websites were developed, the load balancer+web servers can be hidden bind a single locator.

There's a difference here: if the insertion of load balancer, for example, is part of the SFC policy then it must be exposed to SFC.  The distinction I was trying to make is one of policy and chain: if the service is part of a chain, explicitly, then it is in essence it must be addressed by the SFC policy (even if the policy is simple).  If the load balancer is not explicit (i.e. it is coupled to a SF), then there's no policy needed to includes the chaining of such a service.  In that case, it isn't part of the chain.

> I don't think using the existence of the network locator as that helpful in coming up with crisp definitions.
> Even for the FW-A case above it would be identified by a network locator. And the CPU temperature sensor on server3 has a network locator as well (composed of MAC address and I2C address for instance). I suspect the essence of their differences has more to do with state than how they are addressed.

Fair enough, network locator isn't accurate.  Rather, I should have said, if the service function is granular enough to be expressed via policy (using the heavily loaded term), which include a locator and identifier.

> 
> It feels like we might need different terms to describe the two cases of "instances":
> - an instance (such as FW-A) of the class (FW) which is specific for a given tenant, subscriber, etc. In the cases I can think of that instance has some configuration/policy which is specific to "A". Thus FW-B is different than FW-A in its config/policy.

Using my broader defn above, then per policy, we'd distinguish between FW-A and FW-B.  To your point, both might share a locator (or might now), but could be distinguished via an identifier.

> - an instance of a SFC-visible load balanced entity (such as FW-A-1). In the examples I can think of all of those FW-A-* would be identical and exist to balance and adjust to load. From a config/policy perspective we could consider calling these "replicas" to capture that they are identical.
> 
> Note that the FW-A-* are likely to contain some operational/session state (think of a NAT or a FW which maintains state for TCP connections).

Building on the above, FW-A-* would be expressed as one service in policy (i.e. this chain need FW-A, perhaps with some criteria), and assuming load balancing is handled internally via FW, then one locator and one identifier would be used.  

> Note that the existence of operational/session state means that when load balancing is visible to SFC, then something in SFC needs to be able to ensure the appropriate stickiness (term from http load balancers; might be based on client IP address, or http cookie in the web world) so that the packet flows are not accidentally sent to the wrong replica. That would require some SF-specific awareness in SFC.
> 
> Regards,
>   Erik
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 15:44:03 +0000

Maria,

I agree with you that case 1. will only practically scale up to some point.    Perhaps, as a service provider, you'd choose to avoid the whole problem and only deploy service functions along the lines of case 2 or case 3.    But, that doesn't invalidate the utility of case 1 for some other network with some other requirements and constraints.

   Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 11:39 AM
To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

No issue here.

> > >> 1) given the range of load balancing behaviors, supprting 
> > >> explicit
> > load

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 15:43:41 +0000

The issue is scaling service chaining where many (potentially 100's) of instances of a single service are present and where there is no internal load balancing per service function. 
Is this being addressed in the SFC?

Maria

> Sent: Wednesday, March 26, 2014 11:25 AM
> To: NAPIERALA, MARIA H; Erik Nordmark; Kevin J Ma; Ron Parker; Dave
> Dolson; Sumandra Majee
> Cc: [email-masked]
> balancing
> >> and

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 15:47:33 +0000

Ron,

I would consider a solution which scales only with assumptions 2. and 3. (clusters with internal LB) as limited.

Maria

> Sent: Wednesday, March 26, 2014 11:44 AM
> To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; Erik
> Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
> Cc: [email-masked]
> I agree with you that case 1. will only practically scale up to some
> point.    Perhaps, as a service provider, you'd choose to avoid the
> whole problem and only deploy service functions along the lines of case
> 2 or case 3.    But, that doesn't invalidate the utility of case 1 for
> some other network with some other requirements and constraints.
> 
>    Ron
> 
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Mar 2014 15:53:25 +0000

Hi Maria,

Yes, I would expect this to be addressed as part of the architecture for
SFC.  

On 3/26/14, 11:43 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>The issue is scaling service chaining where many (potentially 100's) of
>instances of a single service are present and where there is no internal
>load balancing per service function.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 26 Mar 2014 15:58:21 +0000

Erik captured it well. The graph-nodes that form a service chain may map
to a single instance or multiple instances. The latter is primarily to
scale SF capacity. I don¹t see a reason why SFC should prevent this much.

Beyond this, the specification of load balancing in the latter case, would
be implementation territory.

Same is true when the load balancing is performed at the service chain
level, by the classifier, in choosing a specific chain for traffic at hand
- SFC should not dictate how the classifier picks the chain.

Surendra.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 16:18:51 +0000

Kumar,

I don't think that load balancing to scale SF capacity (which is crucial to service chaining in virtualized environments) can be delegated solely to implementation.

Maria

> From: Surendra Kumar (smkumar) [mailto:[email-masked]]
> Sent: Wednesday, March 26, 2014 11:58 AM
> To: NAPIERALA, MARIA H; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Ron
> Parker; Dave Dolson; Sumandra Majee
> Cc: [email-masked]
> >> >> actually addressed destination (i.e. the load balancer is visible
> to
> >> >> the
> >> >> tenant and is there for the purpose the tenant request; and on
> the
> >> >> other

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 26 Mar 2014 17:17:55 +0000

Here is an example how scalability can be achieved while keeping VM IPs "visible" to an SFC orchestrator.

An explicit load balancer could use a dedicated SFC header field to run a particular load balancing algorithm. A previous node, for example
the SFC Classifier at chain ingress point would fill this field with an appropriate value using DPI information, policy information collected etc..

The SFC Orchestrator would insert the load balancer and the various SF (the LBS pools) in the chain. Using the index, assuming there is one,
the LB can direct the traffic to the provisionned SFs as needed.

Reserving space (e.g. 32bit fields) in the SFC header for coarse grain and fine grain policy identification provides great flexibility and allows scalability 
as shown in this case.

Nicolas  
________________________________________
From: NAPIERALA, MARIA H [[email-masked]]
Sent: Wednesday, March 26, 2014 4:43 PM
To: Joel M. Halpern; Erik Nordmark; Kevin J Ma; Ron Parker; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Maria

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 26 Mar 2014 17:39:08 +0000

If case 1 poses a scalability problem (eg. there are hundreds of VMs for a service function), the scalability issue can be solved by transforming case 1 into case 2 
through placing a local LB before these VMs and only the LB is viewed in the chain. In some other deployment scenario, case 1 might not pose a scalability issue, and 
thus solution/architecture wise, we should not exclude case 1. To put it another way, case 1 is only usable in small-scale scenario. 

Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Wednesday, March 26, 2014 8:48 AM
To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Ron,

Maria

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Mar 2014 17:39:58 +0000

Paul,

Typically a LB is front ending multiple service. A virtual server
(IP/mask/port range) is typically what represents a service that this LB
is representing. The actual implementation will need something more
specific than just pointing to the LB. This is more of a detail.

On 3/25/14, 7:59 AM, "Paul Quinn (paulq)" <[email-masked]> wrote:

>Indeed, however, I suggest that to be truly accurate, the chain, at the
>policy layer, would in this case specify LB as part of the chain since LB
>is a distinct SF. 
>
>
>

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 26 Mar 2014 17:56:11 +0000

Is there great benefit to keep VM IPs "visible" to the SFC orchestrator in this case? 
I am not sure if the complication of inserting a new index in the header and letting that index control the LB algorithm 
would justify the benefit. Why not just change to the design of "front end those VMs with a local LB" if scale is large?  

Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, March 26, 2014 10:18 AM
To: NAPIERALA, MARIA H; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Ron Parker; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Nicolas  

Maria

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 17:57:18 +0000

> 
> If case 1 poses a scalability problem (eg. there are hundreds of VMs
> for a service function), the scalability issue can be solved by
> transforming case 1 into case 2
> through placing a local LB before these VMs and only the LB is viewed
> in the chain. 

Introducing additional hop is a service chain translates to delay and cost. Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop chain becomes 10-hop chain. 
In fact, if the LB is a virtual appliance it might have similar scalability issue as the original SF.

> In some other deployment scenario, case 1 might not pose
> a scalability issue, and
> thus solution/architecture wise, we should not exclude case 1. To put
> it another way, case 1 is only usable in small-scale scenario.
> 
> Cathy
> 
> I would consider a solution which scales only with assumptions 2. and
> 3. (clusters with internal LB) as limited.
> 
> Maria
> 
> > > its own IP address.   In this case the classifier/PDP sees each VM
> as
> > a
> > > To: Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J
> Ma;
> > > Ron Parker; Dave Dolson; Sumandra Majee
> > > Cc: [email-masked]

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 26 Mar 2014 18:13:17 +0000

Hops can be mitigated by running the LB in the same location as those SF VMs 
The connection from LB to those SF VMs is local, not hops. 

Cathy

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 26 Mar 2014 18:07:56 +0000

Furthermore, a traditional load-balancer is not necessarily what we need. The point is NOT to dispatch HTTP requests (or some other application protocol) with some minimal level of state (cookies) awareness to a bunch of Web servers. The point is more to dispatch a collection of L3 flows with strong affinity (the simple example being the traffic associated with a given broadband user session) between a farm of functionally-equivalent Service Functions (each possibly quite stateful), which may act at various layers of an OSI stack. And probably with a good deal of 'impedance mismatch' between the forwarding capacity of the service classifiers and the service (processing) functions. 

And I agree with Maria that this is probably more than an implementation matter.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Wednesday, March 26, 2014 1:57 PM
To: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

> transforming case 1 into case 2 through placing a local LB before 
> these VMs and only the LB is viewed in the chain.

> In some other deployment scenario, case 1 might not pose a scalability 
> issue, and thus solution/architecture wise, we should not exclude case 
> 1. To put it another way, case 1 is only usable in small-scale 
> scenario.
> 
> Cathy
> 
> > > > isntances of services whose multiplicity is not of concern to 
> > > > the tenant, only the functionality.
> > > >
> > > > >> balancers in the service chaining (as distinct from 
> > > > >> supporting
> > > load

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 18:15:55 +0000

How many restrictions do you need to make it work?

> From: Cathy Zhang [mailto:[email-masked]]
> Sent: Wednesday, March 26, 2014 2:13 PM
> To: NAPIERALA, MARIA H; Ron Parker; Joel Halpern Direct; Joel M.
> Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
> Cc: [email-masked]
> To: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik
> Introducing additional hop is a service chain translates to delay and
> cost. Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop
> chain becomes 10-hop chain.
> > > To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik
> Nordmark;
> > > I don't think this will scale. It was pointed out that the number
> of
> > > service paths grows exponentially.
> > >
> > >
> > > > 2. A service function, as above, but some subset of VM's is
> front-
> > > ended
> > > > > request; and on the other hand a load balancer which is known
> to
> > > the

---

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

In this case, using a simple LB running on VM makes more sense. 

Cathy

---

From: Jerome Moisand <[email-masked]>
Date: Wed, 26 Mar 2014 18:21:28 +0000

Remember... Can't have a load-balancer with roughly the same forwarding capacity as the farm of service functions it is load-balancing to... This is why I spoke of 'impedance mismatch'...

-----Original Message-----
From: Cathy Zhang [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 2:17 PM
To: Jerome Moisand; NAPIERALA, MARIA H; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Cathy

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 18:49:32 +0000

I'm still not seeing any restrictions at all.    In the real world everything has a scale limit.   When it is reached, we do things another way.    The SFC model shouldn't care about VM's or physical hosts, and shouldn't care about explicit load balancers or not.   The classifier/PDP sees some number of logical instances of a service  function.    Whether that logical service function is an actual embodiment of the service function or is, itself, some service-function-specific load balancer is irrelevant.    Why is it so important to arrive at some arbitrary answer to the "how many" question so long as the answer is greater than 1?    If the classifier/PDP would solve the problem better by being "smarter" about how to select the appropriate logical instance, then why can't we leave that to the design and implementation of the classifier/PDP?

   Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 2:16 PM
To: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

> Hops can be mitigated by running the LB in the same location as those 
> SF VMs The connection from LB to those SF VMs is local, not hops.
> 
> Cathy
> 
> To: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; 
> Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
> Cc: [email-masked]
> cost. Imagine a 5 hop chain, each fronted with an external LB SF. 
> 5-hop chain becomes 10-hop chain.
> > In some other deployment scenario, case 1 might not pose a 
> > scalability issue, and thus solution/architecture wise, we should 
> > not exclude case 1. To put it another way, case 1 is only usable in 
> > small-scale scenario.
> >
> > Cathy
> >
> > From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, 
> > MARIA
> H
> > I would consider a solution which scales only with assumptions 2. 
> > and 3. (clusters with internal LB) as limited.
> >
> > Maria
> >
> > > > 1.  A service function is realized by multiple VM's where each 
> > > > VM
> > has
> > > > > > I am not sure I understand this point. Could you explain 
> > > > > > what
> > you
> > > > > mean by "explicit" load balancer vs. load balancer "for the 
> > > > > end
> > > > users"?
> >

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Mar 2014 18:53:12 +0000

Joel,

I agree that the architecture should not impose any dependency between the
service function and SFF. Otherwise
SFC doesn’t have a viable chance to be successful in reality. However the
implementor part of me is bothering me.
I will again start with a pretty common service chain example in a typical
Gi LAN.
  
 Chain#10:  SF_VO  —— SF_PC   where VO= video optimizer and PC = parental
control
 Chain#20:  SF_VO — out to network or imagine another service SF_X.

Assume two flows f1 (associated with chain#10) and another f2(chain#20)
passes thru SFF_VO to VO.
When the transformed content comes back, how does SFF_VO associates this
flow/pkt back to the original chainID?

Several option,
    A) if the chain was selected based on subscriber ID, then SFF can use
sip—> what chain—> find_nextSF[what_chain]
    B) if it was based on some other criterion, time of day etc then SFF
may have to correlate the two flows, original and optimized.
       It could use full 6-tupel, vlan and what not. Depends on network
topology. 
    C) And all the other methods that I am missing here.

The SFF implementation can be quite varied and in the absence of explicit
chainID in each packet and I am NOT advocating for that.

Regards.

Sumandra

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

>><mailto:[email-masked]%3e%3e,Jamal>Hadi
>>Jamal
>>From: Jim

---

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

The general problem of how to handle applications which modify the 
packet header is one that has been discussed.  We need to separate 
between the target case when the service function supports the minimally 
required understanding of service chaining, and the transition when we 
deal with current SFs.

If the service function preserves the transport header and the serice 
chaining header, then even though the packet header has been changed, 
the transport and / or the SFC header will direct the packet onwards 
along the intended path.  Since this is needed for preserving metadata 
anyway, this is our targeted mode as I understand it.  Which simply 
works with your SF_VO case below.
Note that this upgrade is much simpler than having to maintain active 
chain information in the service function.

If the SF can not preserve even the SFC header, then some form of proxy 
is required.  If the keying fields in the header are modified in the 
process, or if those fields are not unique across flows, then this proxy 
will be quite complicated (after all, the SF many output packets in a 
different order than they arrive, and may in principle change any parts 
of the header.)

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 19:01:20 +0000

Ron,

I believe we agreed to the fact that if you leave it to the classifier the number of service paths may grow exponentially.
So, IMO, you cannot just say that the implementation will take care of it.

Maria

> Sent: Wednesday, March 26, 2014 2:50 PM
> To: [email-masked]
> I'm still not seeing any restrictions at all.    In the real world
> everything has a scale limit.   When it is reached, we do things
> another way.    The SFC model shouldn't care about VM's or physical
> hosts, and shouldn't care about explicit load balancers or not.   The
> classifier/PDP sees some number of logical instances of a service
> function.    Whether that logical service function is an actual
> embodiment of the service function or is, itself, some service-
> function-specific load balancer is irrelevant.    Why is it so
> important to arrive at some arbitrary answer to the "how many" question
> so long as the answer is greater than 1?    If the classifier/PDP would
> solve the problem better by being "smarter" about how to select the
> appropriate logical instance, then why can't we leave that to the
> design and implementation of the classifier/PDP?
> 
>    Ron
> 
> 
> > > > whole problem and only deploy service functions along the lines
> of
> > > case
> > > > 2 or case 3.    But, that doesn't invalidate the utility of case
> 1
> > > for

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 19:02:59 +0000

I agree with Joel.   Also putting my implementor's hat on -- many service functions will need to accommodate reception and transmission of the SFC header.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, March 26, 2014 2:59 PM
To: Sumandra Majee; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Yours,
Joel

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Mar 2014 19:07:03 +0000

>works with your SF_VO case below.

[SM] Yes. However I am not sure if the architecture can count on the
preservation part.
I as a network engineer at times often misjudged the application developer
restriction and requirement.
SFC in a way would need to bridge this gap (or be aware what works and
what doesn¹t). 

Regards.

Sumandra

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 19:07:40 +0000

Maria,

But how do you draw the line?   Let's say that for an abstract chain there are 4 service functions -- A, B, C, D.   Each of them has 10 logical instances (of whatever form that takes) visible to the classifier.   Ignoring the effects of traffic filtering, we would end up with 10 * 10 * 10 * 10 distinct paths.    Is 10,000 paths too many?    Too many to hold in memory?   Too many to distribute in a control plane?

   Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 3:01 PM
To: Ron Parker; [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Ron,

Maria

> > Hops can be mitigated by running the LB in the same location as 
> > those SF VMs The connection from LB to those SF VMs is local, not hops.
> >
> > Cathy
> >
> > Introducing additional hop is a service chain translates to delay 
> > and cost. Imagine a 5 hop chain, each fronted with an external LB SF.
> > > not exclude case 1. To put it another way, case 1 is only usable 
> > > in small-scale scenario.
> > >
> > > Cathy
> > >
> > > > > > The point of the distinction was between on the one hand 
> > > > > > load balancing as part of the chain for the purpose of 
> > > > > > selecting
> an
> > > > > > instance of the actually addressed destination (i.e. the 
> > > > > > load
> > > > > balancer
> > > > > > service chaining infrastructure, but whose purpose to 
> > > > > > balance
> > > > across
> > > > > My concern is about the latter, i.e., SFC solution must 
> > > > > support
> > > load

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Mar 2014 15:18:25 -0400

I think that the architecture can and should talk about a desired state, 
in which this sort of transparency is achieved.

We do need to discuss proxies and transition mechanisms for getting to 
that state.  But that is likely to require a lot of tactical 
engineering, rather than architecture, to cope with the wide range of cases.

And we may have to admit that some cases can not be handled.  Which 
provides an incentive for the vendor to fix things so they do work.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 26 Mar 2014 19:19:29 +0000

Sumandra,

This seems like whether a specific SF is SFC compatible or not ? If
compatible, how much, based on the requirement language in SFC.
That is why it is all the more important to have a simple, clean & short
service header - may have greater chance of adoption.

Surendra.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 26 Mar 2014 19:21:07 +0000

(If a separate path is triggered per every SF instance) it will be too many/too complex operationally.

> Sent: Wednesday, March 26, 2014 3:08 PM
> To: NAPIERALA, MARIA H; [email-masked]
> But how do you draw the line?   Let's say that for an abstract chain
> there are 4 service functions -- A, B, C, D.   Each of them has 10
> logical instances (of whatever form that takes) visible to the
> classifier.   Ignoring the effects of traffic filtering, we would end
> up with 10 * 10 * 10 * 10 distinct paths.    Is 10,000 paths too many?
> Too many to hold in memory?   Too many to distribute in a control
> plane?
> 
>    Ron
> 
> 
> I believe we agreed to the fact that if you leave it to the classifier
> the number of service paths may grow exponentially.
> > > > > > its own IP address.   In this case the classifier/PDP sees
> each
> > > VM
> > > > as
> > > > > a
> > > > > > internal load balancing.   The set of VM's presents a single
> IP
> > > > > address
> > > > > > to the outside to hide the IP addresses of the individual
> VMs.
> > > > The
> > > > > > To: Joel Halpern Direct; Joel M. Halpern; Erik Nordmark;
> Kevin
> > J
> > > > Ma;
> > > > > > > Put differently, it is between load balancing as an
> explicit
> > > > > service
> > > > > > > and load balancing to enable some service within the
> service
> > > > > > chaining.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > service at the intermediate service hops. In fact, we need
> the
> > > > latter
> > > > > > to support the former..
> > > > > >
> > > > > > Maria
> > > > > >
> > > > > > >

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Mar 2014 19:49:05 +0000

Please see inline below.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 1:59 PM
To: Sumandra Majee; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

[Lucy] Yes, this is my understanding. This also approves that SFC implementation will depend on the transport header in some degree. If that transport header is IP header, the packet from SFF_VO to SF_VO will contain src IP as of SFF_VO's and dst IP as of SF_VO's; the packet from SF_VO to SFF_VO will contain src IP as of SF_VO's and dst IP as of SFF_VO's, i.e. SF_VO flip the address in IP header.  

[Lucy] This is the legacy SF support issue. The proxy needs to cache the SFC header information on a packet, strip off the SFC header on the packet, and then send the packet to the legacy SF; when receiving a packet from legacy SF, the proxy needs to correlate received packet with the one it sent and puts back the SFC header, and then send back to SFF. 

Cheers,
Lucy 

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Mar 2014 19:53:43 +0000

This means that we need a stateless way for the distributions over these paths. The network already implements ECMP.

Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, March 26, 2014 2:08 PM
To: NAPIERALA, MARIA H; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Maria,

   Ron

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]]
Sent: Wednesday, March 26, 2014 3:01 PM
To: Ron Parker; [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Ron,

Maria

---

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

My 2 cents is below.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, March 26, 2014 2:18 PM
To: Sumandra Majee; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

I think that the architecture can and should talk about a desired state, in which this sort of transparency is achieved.

We do need to discuss proxies and transition mechanisms for getting to that state.  But that is likely to require a lot of tactical engineering, rather than architecture, to cope with the wide range of cases.

And we may have to admit that some cases can not be handled.  Which provides an incentive for the vendor to fix things so they do work.
[Lucy] Fully agree. Although proxy can be used to support some legacy SFs in some use case. If the proxy implementation is too complex, it is better for SP to upgrade legacy SF for that use case. Therefore, we should not aim in a complex proxy solution.

Cheers,
Lucy

Yours,
Joel

On 3/26/14, 3:07 PM, Sumandra Majee wrote:
>> along the intended path.  Since this is needed for preserving 
>> metadata anyway, this is our targeted mode as I understand it.  Which 
>> simply works with your SF_VO case below.
>
> I as a network engineer at times often misjudged the application 
> developer restriction and requirement.

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Mar 2014 20:13:23 +0000

Surendra,

At the risk of repeating myself, I say AGREE.

However me, you and rest agreeing means zilch to the application developers.  What I am saying is that the architecture should take a stand that the existing Service Function will work as is.  Currently the stand is that if the application does not work then go Fix it.  

Did we give this enough thought in a collective way?

There are existing service chain solutions that doesn't mandate any form of change in the existing service interface. Would it be nice to have as a goal?

Regards,

Sumandra
________________________________________
From: Surendra Kumar (smkumar) [[email-masked]]
Sent: Wednesday, March 26, 2014 12:19 PM
To: Sumandra Majee; Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Sumandra,

Surendra.

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Mar 2014 20:42:10 +0000

Hi Sumandra,

Not sure if I agree on your following statement. It is clear that SFC WG try to develop SFC header that requires SF to understand and support in order to support some future and advanced use cases. Since we have not yet finished that SFC header development, I assume that current SF does not support such SFC header on the packet.

IMO: the SFC architecture should not take a stand that the existing Service Function will work as is; instead the architecture should state that introducing SFC header on packets may impact some existing SFs and introduces proxy concept to support existing SFs. I am OK with this statement.

It is perfectly fine that operators may continually use existing SFs to implement some SFC use cases without using SFC header, which are not IETF SFC standard compliant implementation.  

Thanks,
Lucy

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 3:13 PM
To: Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

Surendra,

Regards,

Sumandra

Sumandra,

This seems like whether a specific SF is SFC compatible or not ? If compatible, how much, based on the requirement language in SFC.
That is why it is all the more important to have a simple, clean & short service header - may have greater chance of adoption.

Surendra.

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 20:44:50 +0000

Sumandra,

I don't think that all service functions could be or should be made to work in an SFC environment with no changes.   In a previous airing of this issue, we concluded that only service functions that satisfied certain constraints could be made to work in an SFC environment with no changes.   In fact, Joel H. and I had a disagreement whether it was proper to state that service functions that satisfied those constraints were "simple" service functions -- I withdrew my characterization of them as such.   Those constraints were a) the service function must not change the key fields of the IP header (i.e., 5-tuple) and b) must not launch separate flows (e.g., many HTTP transparent proxy implementations).   Otherwise, that service function is not a candidate to operate under SFC without change.    Sure, it can and does operate under pre-existing ways of doing things, but that isn't the point of our exercise.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, March 26, 2014 4:13 PM
To: Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Surendra,

Regards,

Sumandra

Sumandra,

Surendra.

---

From: Rajeev Manur <[email-masked]>
Date: Wed, 26 Mar 2014 20:54:50 +0000

Hi Sumandra,

>>However me, you and rest agreeing means zilch to the application developers.  What I am saying is that the architecture should take a stand that >>the existing Service Function will work as is.  Currently the stand is that if the application does not work then go Fix it.  
[Rajeev] Any existing SFs that do want to support added capabilities via SFC need to be upgraded to support SFC. I don't see anything wrong with this approach.

There are existing service chain solutions that doesn't mandate any form of change in the existing service interface. Would it be nice to have as a goal?
[Rajeev] Not sure I understand your point. Could you elaborate? Are you talking about a given SF being able to support old and new at the same time, but for different service chains?

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, March 26, 2014 1:13 PM
To: Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Surendra,

Regards,

Sumandra

Sumandra,

Surendra.

---

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

As a minor point, I can easily envision delivery approaches such that 
the SFs can interact with and preserve the SFC header, including 
fetching metadata, without being aware of the details of the actual format.

Aa an example, there are socket mechanisms by which auxiliarry points 
can be passed to applications.  This can then be used for calls to 
interact with the metadata.  And the pointer can be sent on the 
resulting write request to allow the lower layers (kernel, vSwitch, 
Hypervisor,...) to reattach the transport and SFC headers.
I am sure that htere are other ways, and that VM implementation experts 
can find better ones.  This working group probably can safely stay away 
from such details.

Yours,
Joel

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Mar 2014 21:06:56 +0000

Ron,

I am fine with constraint a) and b). Most transparent proxies already work
in that fashion. 

I am talking about the constraint where application are required to
preserve the SFC header very similar to constraint a). If there are two
classes of service SFC complaint and SFC non complacent then the legacy
proxy function is an integral part of the architecture.

I would love to see operator and application writers perspective on this
debate. 

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

>Sumandra,
>
>I don't think that all service functions could be or should be made to
>work in an SFC environment with no changes.   In a previous airing of
>this issue, we concluded that only service functions that satisfied
>certain constraints could be made to work in an SFC environment with no
>changes.   In fact, Joel H. and I had a disagreement whether it was
>proper to state that service functions that satisfied those constraints
>were "simple" service functions -- I withdrew my characterization of them
>as such.   Those constraints were a) the service function must not change
>the key fields of the IP header (i.e., 5-tuple) and b) must not launch
>separate flows (e.g., many HTTP transparent proxy implementations).
>Otherwise, that service function is not a candidate to operate under SFC
>without change.    Sure, it can and does operate under pre-existing ways
>of doing things, but that isn't the point of our exercise.
>
>   Ron
>
>
>However me, you and rest agreeing means zilch to the application
>developers.  What I am saying is that the architecture should take a
>stand that the existing Service Function will work as is.  Currently the
>stand is that if the application does not work then go Fix it.
>
>There are existing service chain solutions that doesn't mandate any form
>of change in the existing service interface. Would it be nice to have as
>a goal?
>
>Regards,
>
>Sumandra

---

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

Hi Joel,

Yes, someone can implement this way. Since you use the socket as example, do you see that socket mechanism is part of transport mechanism to provide such capability or as part of SF design?

Not sure what you suggest to the SFC architecture in your example.

Thanks,
Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 4:06 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

As a minor point, I can easily envision delivery approaches such that the SFs can interact with and preserve the SFC header, including fetching metadata, without being aware of the details of the actual format.

Aa an example, there are socket mechanisms by which auxiliarry points can be passed to applications.  This can then be used for calls to interact with the metadata.  And the pointer can be sent on the resulting write request to allow the lower layers (kernel, vSwitch,
Hypervisor,...) to reattach the transport and SFC headers.
I am sure that htere are other ways, and that VM implementation experts can find better ones.  This working group probably can safely stay away from such details.

Yours,
Joel

On 3/26/14, 4:42 PM, Lucy yong wrote:
>>> If the service function preserves the transport header and the 
>>> serice chaining header, then even though the packet header has been 
>>> changed, the transport and / or the SFC header will direct the 
>>> packet onwards along the intended path.  Since this is needed for 
>>> preserving metadata anyway, this is our targeted mode as I 
>>> understand it.  Which simply works with your SF_VO case below.
>>
>> SFC in a way would need to bridge this gap (or be aware what works 
>> and what doesn¹t).
>>
>> Regards.
>>
>> Sumandra
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 26 Mar 2014 12:30:38 -0700

That is not entirely true; depends on how the load-balancer is built and/or how big the farm behind it is...

	--Tom

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 22:03:00 +0000

Or is that the realm of the SFF?   Could one build a smarter SFF that accomplished what you describe, given that constraints a) and b) are respected?

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 5:07 PM
To: Ron Parker; Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Ron,

I am fine with constraint a) and b). Most transparent proxies already work in that fashion. 

I am talking about the constraint where application are required to preserve the SFC header very similar to constraint a). If there are two classes of service SFC complaint and SFC non complacent then the legacy proxy function is an integral part of the architecture.

I would love to see operator and application writers perspective on this debate. 

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

>stand that the existing Service Function will work as is.  Currently 
>the stand is that if the application does not work then go Fix it.
>
>There are existing service chain solutions that doesn't mandate any 
>form of change in the existing service interface. Would it be nice to 
>have as a goal?
>
>Regards,
>
>Sumandra
>That is why it is all the more important to have a simple, clean & 
>short service header - may have greater chance of adoption.
>
>Surendra.
>

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 26 Mar 2014 22:31:37 +0000

Yes, from the definition of SFF, it seems in the realm of SFF. The SFF can be aware of the encap format that is supported by each of the associated SFs  
and either pass the chain header or strip off the chain header, and then send the flow packet to the SF. Depending on the encap support capability of SF, 
the SFF may even need to strip part of the Service chain header (eg. strip off the metadata part but keep the chainID+ServiceIndex part) for interoperating with SF. 
When the SF returns the packet to the SFF, SFF will need to add back the chain header in the case that the header was stripped and there are 
multiple correlation mechanisms to do this. 

Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, March 26, 2014 3:03 PM
To: Sumandra Majee; Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 5:07 PM
To: Ron Parker; Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Ron,

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 27 Mar 2014 08:26:29 +0000

> -----邮件原件-----
> 发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
> 发送时间: 2014年3月27日 4:45
> 收件人: Sumandra Majee; Surendra Kumar (smkumar); Joel M. Halpern; Lucy
> yong; [email-masked]
> I don't think that all service functions could be or should be made to work in an
> SFC environment with no changes.   In a previous airing of this issue, we
> concluded that only service functions that satisfied certain constraints could be
> made to work in an SFC environment with no changes.   In fact, Joel H. and I
> had a disagreement whether it was proper to state that service functions that
> satisfied those constraints were "simple" service functions -- I withdrew my
> characterization of them as such.   Those constraints were a) the service
> function must not change the key fields of the IP header (i.e., 5-tuple) and b)
> must not launch separate flows (e.g., many HTTP transparent proxy
> implementations).   Otherwise, that service function is not a candidate to
> operate under SFC without change.    Sure, it can and does operate under
> pre-existing ways of doing things, but that isn't the point of our exercise.

It makes sense. It seems helpful to explicitly record the above constraints in the SFC architecture or framework drafts.

Best regards,
Xiaohu

> However me, you and rest agreeing means zilch to the application developers.
> What I am saying is that the architecture should take a stand that the existing
> Service Function will work as is.  Currently the stand is that if the application
> does not work then go Fix it.
> 
> There are existing service chain solutions that doesn't mandate any form of
> change in the existing service interface. Would it be nice to have as a goal?
> 
> Regards,
> 
> Sumandra
> This seems like whether a specific SF is SFC compatible or not ? If compatible,
> how much, based on the requirement language in SFC.
> That is why it is all the more important to have a simple, clean & short service
> header - may have greater chance of adoption.
> 
> Surendra.
>