Re: [sfc] 答复: questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

["Joel M. Halpern" <[e-mail]>]

If the service chain splits, that is one case.
But it is also quite acceptable and within what has been discussed for 
the service chain (or more specifically the service path) not to split 
at all.  Rather, what hangs off of the SFF is a suitable load balancer 
(or balancers) and multiple service function instances.  That balancing 
is not visible to service chaining (although it is certainly visible to 
management.  The point of such a deployment is that there is no change 
to the service paths as that collective service function scales in or 
out as direct by management, or as caused by failures, or ...

If we insist that the service paths within such a deployment are 
different, we are requiring larger scale visiblity of such events.

Yours,
Joel

On 5/29/14, 4:06 PM, Andrew G. Malis wrote:
> Joel,
>
> I disagree, I really don't see it as confusing at all. We're all in
> agreement that there will be cases where a service function is split
> among multiple hardware and/or software entities that can work in
> parallel, or else there wouldn't be a section on load sharing. How else
> would one describe these entities if not as "Service Function Instances"?
>
> Cheers,
> Andy
>
> On Thu, May 29, 2014 at 3:57 PM, Joel M. Halpern <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     the problem I have with the definition you propose for Service
>     Function Instance is that what is an instance will depend upon where
>     you look.
>     What management, and particularly what virtual machine monitoring
>     and management, sees as an instance has to be a single image running
>     on a single VM.
>     But what Service Chaining sees as an instance may be one such thing,
>     or may be a cluster of such things organized in such a way as to
>     present a single view to the service chaining infrastructure.
>
>     Thus, trying to define Service Function Instance, and then talk
>     explicitly about such instances in service chaining, gets very
>     difficult.  We are likely to end up with a definition that says that
>     a service function instance may be made up of multiple software
>     instances.  Such a definition seems likely to cause more confusion
>     than it solves.
>
>     If we can come up with a definition that allows for the range of
>     deployments, and does not itself further confuse the readers, then I
>     am happy to add such a term definition and usage in the document.
>
>     Yours,
>     Joel
>
>
>     On 5/29/14, 2:25 PM, Linda Dunbar wrote:
>
>         It would be so much easier to formally introduce the concept of
>         "Service Function Instance" in SFC. For example:
>
>         "Service Function Instance: One instantiation of a service function.
>         One service function could have multiple identical instances.
>
>         For a service function with different functional instantiations,
>         e.g.
>         one instantiation applies policy-set-A (NAT44-A) and other applies
>         policy-set-B (NAT44-B), they are considered as two different service
>         functions."
>
>         Some Service Function Instances are visible to Service Chain Path.
>         Sometimes a collection of service function instances can appear as
>         one single entity to the Service Chain Path."
>
>
>         Linda
>
>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>