Re: [sfc] SFC Terminology / Concepts

[<[e-mail]>]

Hi Xiaohu,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Xuxiaohu [mailto:[e-mail]]
>Envoyé : mardi 15 juillet 2014 11:50
>À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor; [e-mail];
>Ron Parker
>Objet : RE: [sfc] SFC Terminology / Concepts
>
>Hi Med,
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]
>> Sent: Tuesday, July 15, 2014 5:35 PM
>> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; [e-mail]; Ron Parker
>> Subject: RE: [sfc] SFC Terminology / Concepts
>>
>> Hi Xiaohu,
>>
>> Why a classifier will need specify a path a la ERO? Why it needs to have
>the full
>
>In this way, the path selection process (i.e., selecting the appropriate
>SFF for the next SF based on certain constraints) on the SFF is greatly
>simplified.

[Med] This does not answer to my question why the "classifier" has specifically to take care of this? How multiple classifiers present in a given SFC-enabled domain behave in order to distribute traffic among available Service Function Nodes? How a classifier can distribute traffic without any conflict with other LBs that may be present in the forwarding path?

>
>> knowledge  of the involved SF instances? Wouldn't this require the
>classifier to
>> be fed with additional information to drive its selection process? Is
>this
>
>The classifier could request the PCE to do the SFP computation (see
>http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is no
>need for the classifier to be fed with additional information.

[Med] Functionally, the classifier will need a path computation component. Whether these two are co-located or separated is implementation-specific. My concern is to require that path computation component as a mandatory component for the architecture. I think this is not justified.

>
>> complexity justified for all deployments?
>
>As I have said, the architecture should allow the classifier to just impose
>the SFC information on the selected packet as well. In this way, each SFF
>needs to resolve the appropriate next SFF for the next SF to be executed.

[Med] Yes, I understood that from you initial list. My question is how to package all this together without imposing complexity to deployments that do not require it.

>
>Best regards,
>Xiaohu
>
>> Cheers,
>> Med
>>
>> >-----Message d'origine-----
>> >De : Xuxiaohu [mailto:[e-mail]] Envoyé : mardi 15 juillet
>> >2014 10:49 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor;
>> >[e-mail]; Ron Parker Objet : RE: [sfc] SFC Terminology / Concepts
>> >
>> >Hi Med,
>> >
>> >IMHO, the architecture should allow the classifier to specify
>> >
>> >1) a partial SFP (i.e., some SFFs along that partial SFP need to
>> >locally determine the appropriate SFF for the next SF);
>> >2) a complete SFP (i.e., the SFF for each SF in the SFC has been
>> >determined by the centralized node);
>> >3) an SFC (i.e., each SFF along the final SFP needs to locally
>> >determine the appropriate SFF for the next SF).
>> >
>> >In fact, case 3) could be looked as an extreme of case 1).
>> >
>> >Best regards,
>> >Xiaohu
>> >
>> >> -----Original Message-----
>> >> From: sfc [mailto:[e-mail]] On Behalf Of
>> >> [e-mail]
>> >> Sent: Tuesday, July 15, 2014 3:22 PM
>> >> To: Joel M. Halpern; Tom Taylor; [e-mail]; Ron Parker
>> >> Subject: Re: [sfc] SFC Terminology / Concepts
>> >>
>> >> Hi Joel,
>> >>
>> >> As mentioned in several messages, I'm personally for the use of the
>> >> chain
>> >itself is
>> >> the main information to be conveyed in packets to drive forwarding
>> >actions.
>> >>
>> >> I can understand that an identifier can be assigned to a path that is
>> >known in
>> >> advance, but if that path is not known I'm not sure how an identifier
>> >> can
>> >be
>> >> assigned to it!
>> >>
>> >> Joel, the use of "path" is really inappropriate to refer to
>> >> distributed
>> >instance
>> >> selection process for packets bound to a given SFC.
>> >>
>> >> Cheers,
>> >> Med
>> >>
>> >> >-----Message d'origine-----
>> >> >De : sfc [mailto:[e-mail]] De la part de Joel M. Halpern
>> >> >Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor; [e-mail];
>> >> >Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts
>> >> >
>> >> >The most likely realization of the architecture would be that the
>> >> >SFP assignment is recorded in an identifier which travels with the
>packet.
>> >> >
>> >> >Some folks seem to not want the architecture to mandate that.
>> >> >
>> >> >Yours,
>> >> >Joel
>> >> >
>> >> >
>> >> >On 7/14/14, 2:37 PM, Tom Taylor wrote:
>> >> >> Your text scares me because it introduces some new concepts and
>> >> >> assumptions.
>> >> >>
>> >> >> I'd rather go with Joel's formulation. Clarifying question on that:
>> >> >> am I right in seeing the implication that when control assigns an
>> >> >> SFP, the assignment is recorded by an identifier wwhich travels
>> >> >> with
>> >the
>> >> packet?
>> >> >>
>> >> >> Tom Taylor
>> >> >>
>> >> >> On 14/07/2014 2:22 PM, Ron Parker wrote:
>> >> >>> There is one missing word in my text.   Please replace my proposed
>> >text
>> >> >>> with:
>> >> >>>
>> >> >>> "The Service Function Chain (SFC) provides a fully abstract view
>> >> >>> of the service functions to be invoked and the order in which
>> >> >>> they are to be invoked for some particular flow or set of flows,
>> >> >>> without
>> >concern of
>> >> >>> actual service function instance selection.   The Constrained-SFC
>> >> >>> (C-SFC) further allows for policy constraints to be added to the
>> >> >>> SFC affecting the instance selection of one or more of the
>> >> >>> service
>> >functions
>> >> >>> in the SFC.   Any SFC may have any number of C-SFC's associated
>with
>> >> >it."
>> >> >>>
>> >> >>> Thanks.
>> >> >>>
>> >> >>>      Ron
>> >> >> ...
>> >> >>
>> >> >>
>> >> >>> *From:*sfc [mailto:[e-mail]] *On Behalf Of *David
>> >> >>> Allan I
>> >> >>> *Sent:* Monday, July 14, 2014 2:03 PM
>> >> >>> *To:* Jim Guichard (jguichar); [e-mail] <mailto:[e-mail]>
>> >> >>> *Subject:* Re: [sfc] SFC Terminology / Concepts
>> >> >>>
>> >> >>> I like that text, it strikes a good balance where an
>> >> >>> implementation has the option of making scale and resiliency a
>local
>> matter..
>> >> >>>
>> >> >>> D
>> >> >>>
>> >> >>> *From:*sfc [mailto:[e-mail]] *On Behalf Of *Jim
>> >> >>> Guichard
>> >> >>> (jguichar)
>> >> >>> *Sent:* Monday, July 14, 2014 10:48 AM
>> >> >>> *To:* [e-mail] <mailto:[e-mail]>
>> >> >>> *Subject:* [sfc] SFC Terminology / Concepts
>> >> >>>
>> >> >>> Dear WG:
>> >> >>>
>> >> >>> There has been much debate over the last few days with regards to
>> >> >>> SFC concepts. To try and form some consensus around terminology
>> >> >>> and concepts used to describe the architecture in the merged
>> >> >>> architecture draft, Joel has kindly suggested the following:
>> >> >>>
>> >> >>> "The SFP provides a level of indirection between the fully
>> >> >>> abstract notion of service path as a sequence of functions to be
>> >> >>> delivered, and the fully specified notion of exactly what
>> >> >>> instances of SFFs the packet will visit when it actually
>> >> >>> traverses the network. By allowing the control components to
>> >> >>> specify the use of this level of indirection, the deployment may
>> >> >>> choose the degree of SFF instance selection authority that is
>delegated to
>> the network."
>> >> >>>
>> >> >>> I'd like to ask the WG as a whole, if this clarification is
>> >> >>> something that we can get consensus on. If so, I'll ask Joel to
>> >> >>> provide specific text, that reflects the above, for inclusion in
>> >> >>> the merged architecture draft.
>> >> >>>
>> >> >>> Thank You,
>> >> >>>
>> >> >>> Jim
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> sfc mailing list
>> >> >>> [e-mail]
>> >> >>> https://www.ietf.org/mailman/listinfo/sfc
>> >> >>>
>> >> >>
>> >> >> _______________________________________________
>> >> >> sfc mailing list
>> >> >> [e-mail]
>> >> >> https://www.ietf.org/mailman/listinfo/sfc
>> >> >>
>> >> >
>> >> >_______________________________________________
>> >> >sfc mailing list
>> >> >[e-mail]
>> >> >https://www.ietf.org/mailman/listinfo/sfc
>> >>
>> >> _______________________________________________
>> >> sfc mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/sfc