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

["Andrew G. Malis" <[e-mail]>]

Joel,

Again, we're in agreement. It would most likely be confined to sections 1.2
(initial definition) and 6 (load balancing).

Cheers,
Andy


On Thu, May 29, 2014 at 4:27 PM, Joel M. Halpern <[e-mail]>wrote:

> In that case, there would seem to be very few places, if any, in the
> document where we would use the term Service Function Instance.
>
> Yours,
> Joel
>
>
> On 5/29/14, 4:24 PM, Andrew G. Malis wrote:
>
>> 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 <[e-mail]
>> <mailto:[e-mail]>> 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
>>         <[e-mail] <mailto:[e-mail]>
>>         <mailto:[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] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/__listinfo/sfc
>>         <https://www.ietf.org/mailman/listinfo/sfc>
>>
>>
>>