Re: [sfc] SFC Terminology / Concepts

[Xuxiaohu <[e-mail]>]

Hi Med,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Wednesday, July 16, 2014 4:54 PM
> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; [e-mail]; Ron Parker
> Subject: RE: [sfc] SFC Terminology / Concepts
> 
> 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.

If the SFP computation is performed by the PCE, the classifier just needs to accept the computation result returned by the PCE and then impose the SFP info on the selected packets. In other words, the classifier doesn't need that SFP computation component anymore. Furthermore, if the classifier is just allowed to impose the SFC info on the selected packet, it doesn't need the SFP computation component as well.

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

Since architecture allows three options, operators could make their own choices accordingly.

Best regards,.
Xiaohu

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