Subject: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general

From: Martin Stiemerling <[email-masked]>
Date: Tue, 03 Dec 2013 10:35:13 +0100

Hi all,

I have read through draft-quinn-sfc-problem-statement and 
draft-quinn-sfc-arch and wonder about the slightly different definitions 
of service function chain in both documents though that they share a 
similar set of authors. I guess a much better terminology alignment is 
required. See below for the excerpts from the drafts about the definitions.

Anyhow, here is my real point:

The definitions of SFC below always read to me as they are describing 
the services functions and the order of them, but any further 
information about whether there is a *network* path between the 
functions is missing in the definition. Also some abstract information 
about the network path is missing, such as unidirectional, 
bi-directional, unicast, multicast, etc.

Is this intentionally?

Is this a hidden assumption that the network overlay(s) is already 
pre-configured between service nodes?

Here are the excerpts for your reference:

In draft-quinn-sfc-problem-statement, Section 1.1
      Service Chain:  A service chain defines the required functions and
       associated order (service-function1 --> service-function 2) that
       must be applied to packets and/or frames.  A service chain does
       not specify the network location or specific instance of service
       functions (e.g. firewall1 vs. firewall2).

In draft-quinn-sfc-arch, Section 1.2:
    Service Function Chain (SFC):  A set of service functions that are to
    be applied to selected traffic in a specific order.  The implied
    order may not be a linear progression as the architecture will
    allow for nodes that copy to more than one branch.  The term
    service chain is often used as a shorthand version of service
    function chain.

In draft-quinn-sfc-arch, Section 2.1
"service function chaining creates an abstracted view
    of a service and specifies the set of required service functions as
    well as the order in which they must be executed.

Thanks,

   Martin

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 03 Dec 2013 10:02:14 +0000

Hi Martin,

My understanding is that it is as you say: there is an implicit assumption of an existing overlay, and one of the more (if not the most) important tasks of SFC is precisely defining how metadata is transferred using the constructs provided by the overlay, and how these metadata control flows on the overlay. How the overlay is configured in terms of network paths should be out of scope.

Be goode,

On 3 Dec 2013, at 10:35 , Martin Stiemerling wrote:

> Hi all,
>
> I have read through draft-quinn-sfc-problem-statement and draft-quinn-sfc-arch and wonder about the slightly different definitions of service function chain in both documents though that they share a similar set of authors. I guess a much better terminology alignment is required. See below for the excerpts from the drafts about the definitions.
>
> The definitions of SFC below always read to me as they are describing the services functions and the order of them, but any further information about whether there is a *network* path between the functions is missing in the definition. Also some abstract information about the network path is missing, such as unidirectional, bi-directional, unicast, multicast, etc.
>
> Is this intentionally?
>
> Is this a hidden assumption that the network overlay(s) is already pre-configured between service nodes?
>
>
>
> _______________________________________________
> 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: Martin Stiemerling <[email-masked]>
Date: Tue, 03 Dec 2013 13:20:15 +0100

Hi Diego, all,

On 12/03/2013 11:02 AM, Diego R. Lopez wrote:
> Hi Martin,
>
> My understanding is that it is as you say: there is an implicit
> assumption of an existing overlay, and one of the more (if not the
> most) important tasks of SFC is precisely defining how metadata is
> transferred using the constructs provided by the overlay, and how

Ok, good to know and it is even better if this is documented in the 
architecture or wherever appropriate.

While I can see the operational reasons for this by today, I consider 
this as a unnecessary limitation for the future. Is this group only 
considering this or are there thoughts to go beyond this?

> these metadata control flows on the overlay. How the overlay is
> configured in terms of network paths should be out of scope.

Shouldn't this be mentioned in the charter?

Thanks,

   Martin

>> draft-quinn-sfc-arch and wonder about the slightly different
>> definitions of service function chain in both documents though that
>> they share a similar set of authors. I guess a much better
>> terminology alignment is required. See below for the excerpts from
>> the drafts about the definitions.
>>
>> The definitions of SFC below always read to me as they are
>> describing the services functions and the order of them, but any
>> further information about whether there is a *network* path between
>> the functions is missing in the definition. Also some abstract
>> information about the network path is missing, such as
>> unidirectional, bi-directional, unicast, multicast, etc.
>>
>> Is this intentionally?
>>
>> In draft-quinn-sfc-problem-statement, Section 1.1 Service Chain:  A
>> service chain defines the required functions and associated order
>> (service-function1 --> service-function 2) that must be applied to
>> packets and/or frames.  A service chain does not specify the
>> network location or specific instance of service functions (e.g.
>> firewall1 vs. firewall2).
>>
>> In draft-quinn-sfc-arch, Section 1.2: Service Function Chain (SFC):
>> A set of service functions that are to be applied to selected
>> traffic in a specific order.  The implied order may not be a linear
>> progression as the architecture will allow for nodes that copy to
>> more than one branch.  The term service chain is often used as a
>> shorthand version of service function chain.
>>
>> In draft-quinn-sfc-arch, Section 2.1 "service function chaining
>> creates an abstracted view of a service and specifies the set of
>> required service functions as well as the order in which they must
>> be executed.
>>
>>
>>
>> Thanks,
>>
>> Martin _______________________________________________ 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: "Diego R. Lopez" <[email-masked]>
Date: Tue, 03 Dec 2013 13:27:41 +0000

Hi Martin,

On 3 Dec 2013, at 13:20 , Martin Stiemerling wrote:
> Ok, good to know and it is even better if this is documented in the architecture or wherever appropriate.
>
> While I can see the operational reasons for this by today, I consider this as a unnecessary limitation for the future. Is this group only considering this or are there thoughts to go beyond this?

My take here is that there are a few other groups focused on this, and that the group should seek for collaboration with them.

> Shouldn't this be mentioned in the charter?

I think so, stating the above mentioned groups as those which SFC should be aligned to.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 3 Dec 2013 14:13:58 +0000

Martin,

You can forward packets between instances, but 
you cannot forward packets between logical concepts.

The last sentence of the first of these 
definitions makes it clear that this is a chain 
of logical concepts that may each be deployed as 
a collection of instances, NOT a chain of 
specific instances. The other definitions don't 
say this, but they contradict it either.

There can't be any assumptions about whether a 
pre-configured overlay is assumed, if a service 
chain is at least a level of indirection away from any actual routing.

However, you're right that uni/bi-directional, 
uni/multi-cast are as relevant for a chain of 
concepts as for a chain of real instances.

>>>       functions (e.g. firewall1 vs. firewall2).

HTH

Bob

At 13:27 03/12/2013, Diego R. Lopez wrote:
> > Ok, good to know and it is even better if 
> this is documented in the architecture or wherever appropriate.
> >
> > While I can see the operational reasons for 
> this by today, I consider this as a unnecessary 
> limitation for the future. Is this group only 
>My take here is that there are a few other 
>groups focused on this, and that the group 
>should seek for collaboration with them.
>
>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:

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Thomas Narten <[email-masked]>
Date: Tue, 03 Dec 2013 09:24:31 -0500

Martin,

> functions is missing in the definition.

It is assumed there is a path between service instances (what else
would make sense?). To the degree that a service function instance
needs to know details about that path (e.g, what type of tunnel - GRE,
IP, VXLAN, etc.) that information is assumed to be known to the
service function instances. How that information gets to the service
function instance is a matter for the control/management
protocols. The exact detail on how this is done is not really
understood/known/decided yet by the SFC effort, but we expect it to
become more clear over the next 6 months. The charter speaks to
reevaluating the details of this.

Where the service encap comes in is making sure that the data packets
include enough information in them so that when data packets arrive at
an SF instance, they can be processed correctly *and* can be forwarded
to the next SF instance. The encap will have fields that identify a
specific SF path for a given data packet that provides the "glue"
between the data packet and whatever state information on the SF
instance that is needed to process the packet correctly.

> Also some abstract information 

This information is a property of the specific SF path and will be
known by all the entities that are involved in the service
chain. Getting that info to those nodes is the job of the
control/management plane.

> Is this intentionally?

I wouldn't say intentional so much as that the charter can't contain
everything. This sort of detail would (IMO) go in the architecture document.

> pre-configured between service nodes?

Yes, if you mean pre-configured before data packets for a specific SF
path start flowing. But this will almost certainly be configured
"dynamically", i.e., when a "composite service" is instantiated.

Thomas (with concurrence from Jim)

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Dec 2013 16:02:39 +0000

Are the overlay connections between "Service Functions" similar to today's transport layer between "hosts or applications"? 

There are DA, SA, TCP or UDP ports&flags, and other header fields (to carry the metadata), and the payload to carry the original traffic to be treated by the "service functions"? 

Linda

> -----Original Message-----
> From: nsc [mailto:[email-masked]] On Behalf Of Diego R. Lopez
> Sent: Tuesday, December 03, 2013 4:02 AM
> To: Martin Stiemerling
> Cc: <[email-masked]>
> Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-
> {problem|arch} and in general
> 
> Hi Martin,
> 
> assumption of an existing overlay, and one of the more (if not the most)
> important tasks of SFC is precisely defining how metadata is
> transferred using the constructs provided by the overlay, and how these
> metadata control flows on the overlay. How the overlay is configured in
> terms of network paths should be out of scope.
> 
> Be goode,
> 
> > I have read through draft-quinn-sfc-problem-statement and draft-
> quinn-sfc-arch and wonder about the slightly different definitions of
> service function chain in both documents though that they share a
> about the network path is missing, such as unidirectional, bi-
> directional, unicast, multicast, etc.
> >
> > Is this intentionally?
> >
> 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:

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 04 Dec 2013 09:58:43 +0100

Bob,

On 12/03/2013 03:13 PM, Bob Briscoe wrote:
> Martin,
>
> You can forward packets between instances, but you cannot forward
> packets between logical concepts.

Indeed and that's clear to me just from the beginning.

>
> The last sentence of the first of these definitions makes it clear that
> this is a chain of logical concepts that may each be deployed as a
> collection of instances, NOT a chain of specific instances. The other
> definitions don't say this, but they contradict it either.

Right it is all about abstractions but abstractions need to be complete 
in themselves. And the incomplete definitions do not make the overall 
understanding better.

>
> There can't be any assumptions about whether a pre-configured overlay is
> assumed, if a service chain is at least a level of indirection away from
> any actual routing.

Right, but I got the impression when reading the drafts that the 
pre-configuration is implicitly assumed. My point is just that the 
actual solution/protocol should not rely on the assumption that the 
overlay is just there. It should should allow for it, but not exclude it.

>
> However, you're right that uni/bi-directional, uni/multi-cast are as
> relevant for a chain of concepts as for a chain of real instances.

Jep and hopefully to be added to the definition anytime soon.

>>>>       functions (e.g. firewall1 vs. firewall2).

It did -- thanks!

   Martin

>> > While I can see the operational reasons for this by today, I
>> consider this as a unnecessary limitation for the future. Is this
>> group only considering this or are there thoughts to go beyond this?
>>
>> My take here is that there are a few other groups focused on this, and
>> that the group should seek for collaboration with them.
>>
>> consultar nuestra política de envío y recepción de correo
>> electrónico en el enlace situado más abajo.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 04 Dec 2013 10:23:27 +0100

Thomas,

> service function instances. How that information gets to the service

I am with you on the 'need anyway to have a path between the instance'. 
However, as said in my response to Bob's email, I am fine if SFC is 
working SFC where the path is pre-configured ahead of time of any SFC 
configuration but SFC should also support the case where the path is 
configured on demand just before the SFC is instantiated.

> protocols. The exact detail on how this is done is not really

Ok, that's covered by the charter in item no. 4.

> reevaluating the details of this.

With respect to the reevaluation, are you referring to this sentence out 
of the charter:
"The working group will 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 the
components of the service function chaining architecture".

I'm not sure that this reads like reevaluate to me, but it is good to know.

> instance that is needed to process the packet correctly.

+1

> control/management plane.

I would say that those properties are already part of the abstract 
definition, i.e., the definition of the service chain.
The actual instantiation has to take care how to implement multicast, 
but the fact that a link in the SFC requires a certain network property 
is part of the abstraction.

> everything. This sort of detail would (IMO) go in the architecture document.

Agreed for the charter, I am just worried about the documents, but that 
can be worked out.

> "dynamically", i.e., when a "composite service" is instantiated.

Ok, looks we are on the same page.

Thank you,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 04 Dec 2013 10:28:57 +0100

On 12/03/2013 05:02 PM, Linda Dunbar wrote:
> Are the overlay connections between "Service Functions" similar to
> today's transport layer between "hosts or applications"?
>
> There are DA, SA, TCP or UDP ports&flags, and other header fields (to
> carry the metadata), and the payload to carry the original traffic to
> be treated by the "service functions"?

I can see, for instance, UDP as one way of interconnecting functions, 
but I don't see that reusing the transport protocol headers for carrying 
meta-data is the right thing.

   Martin

>
> Linda
>
>
>
>> -----Original Message----- From: nsc [mailto:[email-masked]]
>> On Behalf Of Diego R. Lopez Sent: Tuesday, December 03, 2013 4:02
>> AM To: Martin Stiemerling Cc: <[email-masked]> Subject: Re: [nsc]
>> Definition of Service Chains in draft-quinn-sfc- {problem|arch} and
>> in general
>>
>> Hi Martin,
>>
>> quinn-sfc-arch and wonder about the slightly different definitions
>> of service function chain in both documents though that they share
>> a similar set of authors. I guess a much better terminology
>> alignment is required. See below for the excerpts from the drafts
>> about the definitions.
>>>
>>> describing
>> functions is missing in the definition. Also some abstract
>> unidirectional, bi- directional, unicast, multicast, etc.
>>>
>>> Is this intentionally?
>>>
>>> In draft-quinn-sfc-problem-statement, Section 1.1 Service Chain:
>>> A service chain defines the required functions
>> and
>>> In draft-quinn-sfc-arch, Section 1.2: Service Function Chain
>>> (SFC):  A set of service functions that are
>> to
>>> required service functions as well as the order in which they
>>> must be executed.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Martin _______________________________________________ nsc
>>> mailing list [email-masked]
>> e-mail: [email-masked] Tel:    +34 913 129 041 Mobile: +34 682 051
>> 091 -----------------------------------------
>>
>>
>> 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:
>> _______________________________________________ nsc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/nsc

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 4 Dec 2013 09:41:35 +0000

For the part "path between instance", my understanding is that SFC is trying to define an overlay where path or reachability of instance should be provided by underlay layer. In other words, instances of Service Functions between hops on a Chain should be reachable on the underlay network of a Service Function Chain.

Hongyu

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, December 04, 2013 5:23 PM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general

Thomas,

On 12/03/2013 03:24 PM, Thomas Narten wrote:
>> terminology alignment is required. See below for the excerpts from the drafts about the definitions.
>

I am with you on the 'need anyway to have a path between the instance'. 
However, as said in my response to Bob's email, I am fine if SFC is working SFC where the path is pre-configured ahead of time of any SFC configuration but SFC should also support the case where the path is configured on demand just before the SFC is instantiated.

> function instance is a matter for the control/management protocols. 
> The exact detail on how this is done is not really

> reevaluating the details of this.

With respect to the reevaluation, are you referring to this sentence out of the charter:
"The working group will 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 the components of the service function chaining architecture".

+1

> known by all the entities that are involved in the service chain. 
> Getting that info to those nodes is the job of the control/management 
> plane.

I would say that those properties are already part of the abstract definition, i.e., the definition of the service chain.
The actual instantiation has to take care how to implement multicast, but the fact that a link in the SFC requires a certain network property is part of the abstraction.

> everything. This sort of detail would (IMO) go in the architecture document.

Agreed for the charter, I am just worried about the documents, but that can be worked out.

Thank you,

   Martin

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Dec 2013 12:33:41 +0000

Hi Martin,

Sent from my iPhone

> On Dec 4, 2013, at 3:29 AM, "Martin Stiemerling" <[email-masked]> wrote:
> 
> I can see, for instance, UDP as one way of interconnecting functions, but I don't see that reusing the transport protocol headers for carrying meta-data is the right thing.
> 
>  Martin

Jim> exactly and that is absolutely not the intent of the SFC work.

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Dec 2013 13:00:21 +0000

If the service function locators are IP addresses , then the "underlay" must support the transport of IP --  this can be an IP routed network, a MAC switched network, an SDN network, or some combination.  

   Ron

> On Dec 4, 2013, at 4:41 AM, "Hongyu Li (Julio)" <[email-masked]> wrote:
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Dec 2013 16:05:03 +0000

Martin, 

> I can see, for instance, UDP as one way of interconnecting functions,

[Linda] We have been using UDP (VxLAN) to interconnect service functions in our GiLAN environment.

Is there any reason that TCP can't be used or not appropriate for interconnecting service functions?

> meta-data is the right thing.

[Linda] Fully Agree with what you stated here. However, just out of curiosity, what harm it can cause by using some un-defined UDP or TCP port number to carry some values between "Service Functions" if those service functions agree upon the meaning of the value? 

Linda

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Dec 2013 16:13:03 +0000

Linda,

That type of ad-hoc usage of existing protocols (i.e., let's assign some semantic meaning to the value of the source UDP port) is what makes multi-vendor interoperability as problematic as it is.   The charter is quite explicit that a common service header be used to convey any information necessary to make the service function chain operational.

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, December 04, 2013 11:05 AM
To: Martin Stiemerling; Diego R. Lopez
Cc: <[email-masked]>
Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general

Martin, 

> but I don't see that reusing the transport protocol headers for 
> carrying meta-data is the right thing.

Linda