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

Joel,

I think we're in violent agreement. There's no insistence that the multiple
instances need to be visible to the service chain path, indeed Linda's
definition includes "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." This part o the definition
might be better and more simply phrased as "A collection of Service
Function Instances may appear as one entity or as multiple entities in the
Service Chain Path."

Cheers,
Andy

On Thu, May 29, 2014 at 4:13 PM, Joel M. Halpern <jmh@joelhalpern.com>wrote:

> 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 <jmh@joelhalpern.com
>> <mailto:jmh@joelhalpern.com>> 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
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>