Subject: [sfc] Allowing SFF to serve multiple SF

From: Nicolas BOUTHORS <[email-masked]>
Date: Thu, 20 Mar 2014 09:03:33 +0000

Service function instance have to be identified to the full extent of their location.
A SF instance could be a VM and can be addressed in different ways by the SFF
that receives the traffic on the chain on its behalf.

Ron mentionned MAC or IP address as network locators for a Service
Function, true but other information will be required to locate a
specific application VM (e.g belonging to a VNFC in a VNF ) for
example.

In practice an SFF could use sockets, shared memory, ipcs to forward subscriber traffic
to local SF. It could be tricky for a central sfc configuration system to keep track of
this complexity. So for now an SFF configuration needs to keeps this additional information
and the SFF is responsible to route the traffic to the associated SF.

An approach could be to rely on contextual information in the chain
header to allow the SFF to locate the SF at all time. In this case the
SFF is not only responsible to route packet from hop to hop, but also
to select a "local" SF, based on say on combination of coarse grain/ fine grain
policy identifier transported in the header.

In this case a SFF could then act as a Load balancing service for a set of SF.

Come to think of it, if we choose  that SF should ignore the forwarding state, then
the SFF may have to embark this responsibility to this extent as well.

In an SDN world for example, the SFF could then be driven by an Openflow controller
application that could take care of Elasticity, OA&M SFC messages, LBS etc..

The advantage I see is that the configuration of a chain could then contain the path
as well as the policies to be used for a chain, letting some flexibility withing Service Node
on how to serve the traffic best based on local state.

Nicolas

>> I  agree, with a small caveat.The service chain identification should identify an instance as seen by
>> the service chain forwarding mechanisms.  As has been discussed, there
>> may be a load balancer and multiple pieces of software running on
>> multiple VMs hidden behind what appears to be one instance from the SFC
>> perspective.  As long as it interfaces properly, that should be fine.
>> Joel

> I agree.   The chain id in the packet should represent a fully specified
> set of located service function instances.    It could be thought of as
> representing a stack of network locators (typically MAC or IP addresses).
>
>      Ron

---

From: Ron Parker <[email-masked]>
Date: Thu, 20 Mar 2014 11:45:43 +0000

Hi, Nicolas.

I think local policy at the SFF is entirely appropriate for some implementations.  And inband or out of band metadata driven by the classifier could be used as part of the input into that policy engine.   The MAC or IP addresses that were referenced are network locators and therefore cause the packets to progress to the appropriate SFF, whose job is to invoke the SFs in a manner appropriate to the implementation.

   Ron

On Mar 20, 2014, at 5:04 AM, "Nicolas BOUTHORS" <[email-masked]<mailto:[email-masked]>> wrote:

Nicolas

> representing a stack of network locators (typically MAC or IP addresses).
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Changcheng Huang <[email-masked]>
Date: Thu, 20 Mar 2014 08:29:19 -0700

A service instance can be mapped to multiple VMs at different locations. For example, a web service today can be mapped to multiple VMs in different physical machines through DNS or load balancer. A Chain ID identifies a chain of service instances, not a chain of physical locations. Physical locations should be identified by IP and MAC addresses. Mapping Chain ID to physical locations can be done either centrally in SDN or distributedly.

Chang

------------
Changcheng Huang

> On Mar 20, 2014, at 4:45 AM, Ron Parker <[email-masked]> wrote:
> 
> Hi, Nicolas. 
> 
> On Mar 20, 2014, at 5:04 AM, "Nicolas BOUTHORS" <[email-masked]> wrote:
> 
>> [email-masked]
> [email-masked]

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 20 Mar 2014 15:40:21 +0000

Agreed. The role Nicolas proposes for the SFF sounds pretty reasonable, and interestingly compatible with all kind of SFs (SFC-aware or not)

What I think is important is to keep the distinction between identifier and locator described in draft-boucadair-service-chaining-framework. The mapping from the former (used in the chain definition) to the later (realizing a particular path, or path link, in a chain) corresponds to the  policy enforcement element, whether centralized or distributed.

Be goode,

On 20 Mar 2014, at 13:45 , Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Nicolas.

   Ron

Nicolas

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx