Re: [sfc] SFC Terminology / Concepts

["NAPIERALA, MARIA H" <[e-mail]>]

> > >> >-----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?
> > >>
> >
> > [Med] It seems you missed this one.
> 
> As I has mentioned before, once the SFP is determined by the classifier in
> advance, there is no need for subsequent SFFs to do complex path selection
> work anymore (e.g., no need to maintain the SF->SFF mapping table and no
> need to resolve the appropriate SFF for the next SF on basis on certain
> constraints). 

Why is this complex? It works today pretty well. 
And managing, e.g., 160K SFPs per chain is not complex? (4 hop chain with 20 instances/SFFs at each hop)

>Of course, in order to optimize the traffic forwarding path (i.e.,
> the SFP), a stateful PCE could be used to do the path computation work. By
> the way, in the distributed and dynamic SFP selection process (i.e., each SFF
> independently determine the appropriate SFF for the next SF), how to
> ensure that optimization of the traffic forwarding path?

Carrying the path information in the packet is not the only way to implement traffic engineering.
An SFC system can be instructed to choose a specific SF instance. This is still a service chain, which just happens to use a specific SF instance (among many) as opposed to a service chain where that choice is arbitrary.

> > >> >> 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.
> >
> > [Med] But still, for the sake of interoperability, the classifier need to be
> prepared
> > for such interface with an external PCE module, no?
> 
> Yes, the classifier should act as a PCC.
> 
> > >> >> 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.
> >
> > [Med] The problem is that packaging a lot of optional features will have
> an
> > impact on the overall complexity of the solution. This is why I'm
> questioning
> > having any possible feature as an optional part of the solution.
> 
> How about listing those three options in the architecture draft and saying
> that either is applicable in some cases.
> 
> Best regards,
> Xiaohu
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc