Re: [sfc] SFC Terminology / Concepts

[Xuxiaohu <[e-mail]>]

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.

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

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

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