Re: [sfc] SFC Terminology / Concepts

[<[e-mail]>]

Hi Xiaohu,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Xuxiaohu [mailto:[e-mail]]
>Envoyé : mercredi 16 juillet 2014 12:15
>À : 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: 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?
>>

[Med] It seems you missed this one.

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

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