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

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

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