Subject: [nsc] Representations of services

From: Thomas Narten <[email-masked]>
Date: Fri, 25 Oct 2013 11:15:57 -0400

The document draft-bitar-i2rs-service-chaining-00.txt gets into
describing services in a very concrete way. E.g., they have names,
they have properties/attributes, etc.

Something like this is presumably needed by SFC if one has service
functions scattered around the network that one wants to find
dynamically. And when creating a service chain, one needs to match
specific service function instances to specific flows. But that means
we need a language of some sort for describing services - so that
service requestors can be matched against service providers.  That can
only be done if services can be described in a machine readable way so
that a service can advertise itself (exact details of service
advertisement don't matter for this discussion) and that someone
wanting a service can choose from advertised services to find the one
they need.

E.g, it's not enough to say "firewall". A FW may need to support
particular rules or features -- and AFAICT, FWs are hardly standard,
and different FWs support different sets of feaures.

Question for this group: how much of the area of service
representation does NSC need to tackle? Seems to me if the answer
can't be "none" if we want interoperability, so something is
needed.

Note that this topic presumably overlaps with other work groups/areas,
like I2RS, network management, etc.

We presumably also want to leverage work done elsewhere where
possible. But if there is nothing we can leverage, is there specific
work that NSC (or some other group) will need to do regarding the
representation of service functions?

Thomas

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 25 Oct 2013 23:34:13 +0000

Hi Tom,

Cannot agree more. In my mind, service metadata and the mechanisms for his announcement have always been among the goals of the group...

Be goode,

On 25 Oct 2013, at 17:15 , Thomas Narten wrote:

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Oct 2013 06:04:43 -0400

Maybe I am naive, but this looks to be completely outside the scope of 
what I understand SFC to be working on.
Architecturally, naming or identification has to be assumed.  But that 
does not mean we have to define it.  In particular, the identification 
of services / service instances / servers / virtual instances ... would 
seem to be a control function.  Once we get to the data plane, SFC 
service delivery points have to be meaningful to the data plane.

Hence, the process of discovery and selection service entities seems to 
me to be outside of our problem domain.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 28 Oct 2013 01:44:31 +0000

Just want to add one more point to what Joel said: 

There are vast diverse types of service functions. Defining each individual service and its associated attributes for "Controller" to manage can quickly become a kitchen sink. The attributes for FW is completely different from Video Optimization, which is again different from content caching, TCP acceleration, NAT, or AntiDos scrubbing services. More importantly, there are new service functions popping up faster than ever. Their attributes are all different. 

It is a moving target to chase them and try to characterize attributes for them. 

My two cents. 

Linda

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel M. Halpern
> Sent: Saturday, October 26, 2013 5:05 AM
> To: Thomas Narten
> Cc: [email-masked]
> Subject: Re: [nsc] Representations of services
>

---

From: Thomas Narten <[email-masked]>
Date: Mon, 28 Oct 2013 14:03:36 -0400

Hi Joel.

> what I understand SFC to be working on.

To be clear, I mostly agree. IMO, this is mostly outside of the
current charter as I understand it.

However, the question really is what (if any) work in this space is
needed in order for SFC to be successful more generally. I.e., would
the lack of work/solutions just mean all that stuff gets done in a
proprietary manner? Is that what we want?

To me, SFC is part of a bigger picture that involves orchestration of
VMs and services. SFC is one piece of that, but not the only one.

> service delivery points have to be meaningful to the data plane.

The proposed charter isn't just  data plane/encap, there are hints of
control plane too.

Look at the following paragraph from the charter and the last
paragraph in particular:

    The Service Function Chaining (SFC) working group will develop new
    approaches to service delivery and deployment. It will produce a 
    framework for service function chaining that includes the necessary
    protocols or protocol extensions to convey the service path and service
    path information to nodes that implement service functions, as well as
    mechanisms for steering traffic through service functions. The working 
    group will also examine what information needs to be gathered from the
    network and service functions in support of service function chaining
    and how that information may be made available to nodes that implement
    the service functions. 

> me to be outside of our problem domain.

Let me ask again though:

1) Do we already have solutions/standards in place that do this today?
If so, what are they?

2) Is there work in this space that needs doing (somewhere)? If so,
what is that work and where should it be done?

Thomas

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 30 Oct 2013 23:06:46 +0000

Hi Thomas,

This topic at least needs to be considered from three aspects.

First is how a SFC is provisioned. Is it something like a routing next work that routers can connect them by negotiation among themselves, or provisioned by a somehow centralized dominant role, an orchestrator maybe. My view on this is the latter is what's demanded by operators. In other words, an SFC is first designed by operators according to business requirements and then mapped to a set of service functions that need to be chained together. In that sense, advertising of capabilities by SF itself is not really necessary, even though not cool at all.

Second aspect is Service Functions are so variant that if we are going to include details of these functions in our work, we are going to be either no ending of work by enumerate all of them, or loose flexibility of the solution by capable of supporting only limited functions.

The last aspect is related to the second one. As service functions may impact the way a packet is forwarded, e.g. NAT changes a packet, DPI may trigger different following processing of a packet, FW may drop certain packets, we need to abstract some features of service functions so that our solution is valid for all.

Cheers,
Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Tuesday, October 29, 2013 2:04 AM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [nsc] Representations of services

Hi Joel.

> what I understand SFC to be working on.

To be clear, I mostly agree. IMO, this is mostly outside of the current charter as I understand it.

However, the question really is what (if any) work in this space is needed in order for SFC to be successful more generally. I.e., would the lack of work/solutions just mean all that stuff gets done in a proprietary manner? Is that what we want?

To me, SFC is part of a bigger picture that involves orchestration of VMs and services. SFC is one piece of that, but not the only one.

> of services / service instances / servers / virtual instances ... 
> would seem to be a control function.  Once we get to the data plane, 
> SFC service delivery points have to be meaningful to the data plane.

The proposed charter isn't just  data plane/encap, there are hints of control plane too.

Look at the following paragraph from the charter and the last paragraph in particular:

> Hence, the process of discovery and selection service entities seems 
> to me to be outside of our problem domain.

Let me ask again though:

2) Is there work in this space that needs doing (somewhere)? If so, what is that work and where should it be done?

Thomas