Subject: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture

From: Linda Dunbar <[email-masked]>
Date: Wed, 23 Jul 2014 16:03:38 +0000

I understand the concerns of authors of merged-arch not wanting to explicitly define the "Service Function Instance". However, the term "Service Function Instance" has been used extensively on mailing list and in many SFC drafts. Having a proper definition can make many drafts more clear.

Here is the Service function Instances defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture. Want to get feedback from the SFC WG.

"Service Function Instance: One instantiation of a service function. Some SF instances are visible to SFF. Sometimes a collection of service function instances can appear as one single entity to SFF.
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."

What do people think?

Linda

---

From: Dave Dolson <[email-masked]>
Date: Wed, 23 Jul 2014 16:15:36 +0000

If a vendor wishes to make hidden instances for scaling purposes, I think it would be simpler to call the set of instances a single SF. This avoids the "sometimes" in the definition.

"Service Function Instance: One instantiation of a service function. SF instances are visible to an SFF.
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."

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, July 23, 2014 12:04 PM
To: [email-masked]
Subject: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture

What do people think?

Linda

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 23 Jul 2014 16:24:10 +0000

I would resist the urge to compete with Merriam-Webster and attempt to create the largest dictionary in an RFC format. I sense we are going a bit overboard with adding definitions...

Why would we want to add more definitions, particularly for phrases that are not used in merged-sfc-arch?

Conversely, if there is a document that needs the term “Service Function Instance” it should, by all means, define it within that context. merged-sfc-arch should not have the goal of defining any potential SFC term that might be used in some context.

In other words, merged-sfc-arch should include the base set of terms (i.e., the ones are used within the architecture), and companion documents can augment as needed.

Just my view.

Thanks,

Carlos.

On Jul 23, 2014, at 12:03 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

I understand the concerns of authors of merged-arch not wanting to explicitly define the “Service Function Instance”. However, the term “Service Function Instance” has been used extensively on mailing list and in many SFC drafts. Having a proper definition can make many drafts more clear.

“Service Function Instance: One instantiation of a service function. Some SF instances are visible to SFF. Sometimes a collection of service function instances can appear as one single entity to SFF.
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."

What do people think?

Linda

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 23 Jul 2014 17:18:22 +0000

I fully support this. I was starting to have the same concerns Carlos has just expressed.

Be goode,

On 23 Jul 2014, at 12:24 , Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Just my view.

Thanks,

Carlos.

What do people think?

Linda

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"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 y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Jul 2014 13:44:31 -0400

I am concerned that in most discussions people expect service chaining 
to work in terms of what is being called service function instances.  If 
we define the instances to mean the real individual instance (which is 
the most understandable definition), then every time we talk about it we 
are going to have to say SFI or cluster.  This is because what appears 
as one entity to service chaining is what we need to refer to in most 
discussions.

If we want a term for this, we should have a term that actually 
corresponds to what we need to discuss.  I have not so far been able to 
think of a term that is not a mouthful that we could use.
As an example of an ugly term, we could use Service Function Realization 
(SFR?).  If we need to name this, presumably because we expect other 
documents to use it, then we need to give it a useable name that 
describes what we need to discuss.

Yours,
Joel

On 7/23/14, 12:03 PM, Linda Dunbar wrote:
> I understand the concerns of authors of merged-arch not wanting to
> explicitly define the “Service Function Instance”. However, the term
> “Service Function Instance” has been used extensively on mailing list
> and in many SFC drafts. Having a proper definition can make many drafts
> more clear.
>
> Here is the Service function Instances defined by
> draft-dunbar-sfc-legacy-l4-l7-chain-architecture. Want to get feedback
> from the SFC WG.
>
> “Service Function Instance: One instantiation of a service function.
> Some SF instances are visible to SFF. Sometimes a collection of service
> function instances can appear as one single entity to SFF.
>
> 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."
>
> What do people think?
>
> Linda
>
>
>
> [email-masked]