Subject: [nsc] Critical step of NSC: basic terminologies and necessary components

From: Linda Dunbar <[email-masked]>
Date: Sat, 3 Aug 2013 21:11:45 +0000

Through the discussions with people from different background at various forums/conferences and the NSC BoF, I have heard different interpretations of Service Chain:

*        Some people, especially from router/switch vendor background, may think Service chain as traffic steering based on something that is NOT the packets Layer 2-3 header. E.g. policies or Layer 4-7 fields based traffic steering.

*        Some people, especially from Network Appliance background, may think of Service Chain as "Middle Boxes" being overplayed over existing network infrastructure.

*        Application developers may think of "Service Chain" as connecting various application instances together, such as "Web Server' to "App Server" and to "DB Server".

To make everyone on the same page, I think that it is important to define some common terminologies. To make it more clear on what "services" are chained together and what components are involved, even though it is possible that all those services chained together could have common architecture & solutions.

Let's first break all "services" into pieces: (granted that multiple pieces can exist in one physical/virtual device and can be connected together to form a sellable service to clients).

There are:

                                                |---wires, or virtual links

-        Interconnections: |--

                                                                        |- steering based on L2-3 header
                                  |- Steering functions |-steering based on policies or L4-7 header

-        Functions |

                   |- L2-3 service functions {e.g. steering traffic to different gateway/domains based on dynamic policies to achieve special purposed forwarding}

                   |
                                  |- L4 Service function: {e.g. TCP Acceleration, NAT, Firewall,  caching, web }
                                 |
                                 |- L7 Service function {e.g. Web Proxy, content filtering, statistics collection, etc}

Functions are performed on a node (or a virtual node).

A Service is a combination of functions being interconnected.
>From user perspective, it is about a sequence of service functions interconnected.
Since each service function can have multiple instances, from network perspective, it is really the instances of service function being interconnected.

Hard Questions:

*       Many people whom I have talked to during IETF week have stated that NSC is about chaining L4-7 service functions.

*       But some people (and a presentation at the NSC BoF) mentioned that NSC also includes chaining L2-3 service functions based on various policies, does it?
For L2-3 functions chained together based on various policies, how is it different from I2RS?

*       Should NSC include chaining various "application" modules?
In general, most L7 services terminate TCP/UDP sessions. Proxy based L7  services regenerate new data flows. And packet based L7 services let the packets pass through with some level of header changes

I think the general NSC problem statement should start with those terminologies and state clearly of what components are included.

Thanks, Linda Dunbar

---

From: Ken Gray <[email-masked]>
Date: Sat, 3 Aug 2013 23:47:16 +0000

I respectfully disagree.

I don't think the IETF should be a replay of other SDO.  What I've seen proposed so far are the discussion around metadata and whether an additional header is required to accommodate it.  We've got some future work on how to locate and register a "service".   Gaps where standards don't exist or may not be defined enough to fit even generic use cases.

 I don't see how a definition of what the atom IS we're trying to stitch together matters.  As you indicate, in different scenarios that WILL be different.

I don't feel confused about the generic definitions of the words "service" or "chain", or what they mean when they're together.  If you can make a case for how/if the definition directly affects the work on the table- the metadata requirement or the registration of the "service", that may be interesting.

Sent from my iPhone

On Aug 3, 2013, at 5:12 PM, "Linda Dunbar" <[email-masked]<mailto:[email-masked]>> wrote:

There are:

-        Interconnections: |--

-        Functions |

                   |

Hard Questions:

Thanks, Linda Dunbar

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

---

From: Ron Parker <[email-masked]>
Date: Sun, 4 Aug 2013 15:09:27 +0000

Hi, Linda.

Clearly there are other SDO's wrestling with these same items.   I wonder if we can, with an IETF focus, reduce the problem to the protocol level even without concise definitions for the elements of the use cases that are envisioned.    This would allow us to work in parallel with other organizations, like NFV, where those definitions can be wrestled to the ground.

I would suggest that the problem can be reduced to the need for policy-based multihop source routing where a "classifier" node determines a set of must-visit nodes.  Additionally there has been discussion on metadata delivery between the classifier and the various nodes in the chain.

   Ron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Saturday, August 03, 2013 5:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: [nsc] Critical step of NSC: basic terminologies and necessary components

There are:

-          Interconnections: |--

-          Functions |

                   |

Hard Questions:

Thanks, Linda Dunbar

---

From: <[email-masked]>
Date: Mon, 5 Aug 2013 08:32:15 +0200

Hi Linda,

IMO, we should not go in that path. I would suggest we avoid making any assumption on the individual functions. For example, we should not care about the layer on which the function acts on. The exact definition of each function is specific to each domain: it is deployment-specific. Instead, I suggest we scope the work to a very specific problem which is: how to enforce policy-based forwarding in which a set of functions are invoked in a given order.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Linda Dunbar
Envoyé : samedi 3 août 2013 23:12
À : [email-masked]
Cc : [email-masked]
Objet : [nsc] Critical step of NSC: basic terminologies and necessary components

·         Some people, especially from router/switch vendor background, may think Service chain as traffic steering based on something that is NOT the packets Layer 2-3 header. E.g. policies or Layer 4-7 fields based traffic steering.

·         Some people, especially from Network Appliance background, may think of Service Chain as "Middle Boxes" being overplayed over existing network infrastructure.

·         Application developers may think of "Service Chain" as connecting various application instances together, such as "Web Server' to "App Server" and to "DB Server".

There are:

-          Interconnections: |--

-          Functions |

                   |

Hard Questions:

·         Many people whom I have talked to during IETF week have stated that NSC is about chaining L4-7 service functions.

·         But some people (and a presentation at the NSC BoF) mentioned that NSC also includes chaining L2-3 service functions based on various policies, does it?
For L2-3 functions chained together based on various policies, how is it different from I2RS?

·         Should NSC include chaining various "application" modules?
In general, most L7 services terminate TCP/UDP sessions. Proxy based L7  services regenerate new data flows. And packet based L7 services let the packets pass through with some level of header changes

Thanks, Linda Dunbar

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 5 Aug 2013 13:01:03 +0000

Hi Med,

I agree and do not see the necessity to spend oodles of time defining terminology; if specific terminology is necessary for a particular deployment scenario then it should be defined within use case ID's. Having said that I believe the scope of work is wider than just enforcing policy-based forwarding through a set of service functions. We also need to define the interface for presentation of metadata from/to the network and service functions, and between service functions.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 5, 2013 2:32 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] Critical step of NSC: basic terminologies and necessary components

Hi Linda,

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Linda Dunbar
Envoyé : samedi 3 août 2013 23:12
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : [nsc] Critical step of NSC: basic terminologies and necessary components

·         Some people, especially from Network Appliance background, may think of Service Chain as “Middle Boxes” being overplayed over existing network infrastructure.

·         Application developers may think of “Service Chain” as connecting various application instances together, such as “Web Server’ to “App Server” and to “DB Server”.

To make everyone on the same page, I think that it is important to define some common terminologies. To make it more clear on what “services” are chained together and what components are involved, even though it is possible that all those services chained together could have common architecture & solutions.

Let’s first break all “services” into pieces: (granted that multiple pieces can exist in one physical/virtual device and can be connected together to form a sellable service to clients).

There are:

-          Interconnections: |--

-          Functions |

                   |

Hard Questions:

·         Should NSC include chaining various “application” modules?
In general, most L7 services terminate TCP/UDP sessions. Proxy based L7  services regenerate new data flows. And packet based L7 services let the packets pass through with some level of header changes

Thanks, Linda Dunbar

---

From: <[email-masked]>
Date: Mon, 5 Aug 2013 15:32:49 +0200

Re-,

Yes, I agree. The interfaces are part of the global framework. In my mind, these are sub-items of the "how" mentioned in my initial message.

Cheers,
Med

De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : lundi 5 août 2013 15:01
À : BOUCADAIR Mohamed OLNC/OLN; Linda Dunbar; [email-masked]
Cc : [email-masked]
Objet : Re: [nsc] Critical step of NSC: basic terminologies and necessary components

Hi Med,

Hi Linda,

Cheers,
Med

There are:

-          Interconnections: |--

-          Functions |

                   |

Hard Questions:

Thanks, Linda Dunbar

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 Aug 2013 11:32:37 -0400

I think some degree of distinction is useful.

It seems to me that in order for Network service chaining to make sense, 
we have to have a network.  So L2 and L3 conventional forwarding (the 
base mechanisms) are not within the services being chained.  They are 
(part of) the supporting infrastructure.

Similarly, in order to keep our discussion focused, I had thought that 
the services under discussion were ones that interacted with the 
operator.  Thus, the aspects of SDN or other architectures related to 
placing and scaling the network control function (routing control logic, 
etc.) while interesting are not within what I had taken to be the scope 
of Network Service Chaining.

Even within network service chaining it seems to me important to keep 
track of the difference between control protocols and their support on 
the one hand, and operations which interact with the subscribers data 
packets on the other.  The tools we have and need for manipulating those 
two sets are very different.

Yours,
Joel M. Halpern

On 8/5/13 9:01 AM, Jim Guichard (jguichar) wrote:
> Hi Med,
>
> I agree and do not see the necessity to spend oodles of time defining
> terminology; if specific terminology is necessary for a particular
> deployment scenario then it should be defined within use case ID's.
> Having said that I believe the scope of work is wider than just
> enforcing policy-based forwarding through a set of service functions. We
> also need to define the interface for presentation of metadata from/to
> the network and service functions, and between service functions.
>
> From: "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> To: Linda Dunbar <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> IMO, we should not go in that path. I would suggest we avoid making any
> assumption on the individual functions. For example, we should not care
> about the layer on which the function acts on. The exact definition of
> each function is specific to each domain: it is deployment-specific.
> Instead, I suggest we scope the work to a very specific problem which
> is: how to enforce policy-based forwarding in which a set of functions
> are invoked in a given order.
>
> Cheers,
>
> Med
>
> *De :[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *De la part de* Linda Dunbar
> *Envoyé :* samedi 3 août 2013 23:12
> *À :* [email-masked] <mailto:[email-masked]>
> *Cc :* [email-masked] <mailto:[email-masked]>
> *Objet :* [nsc] Critical step of NSC: basic terminologies and necessary
> components
>
> Through the discussions with people from different background at various
> forums/conferences and the NSC BoF, I have heard different
> interpretations of Service Chain:
>
> ·Some people, especially from router/switch vendor background, may think
> Service chain as traffic steering based on something that is NOT the
> packets Layer 2-3 header. E.g. policies or Layer 4-7 fields based
> traffic steering.
>
> ·Some people, especially from Network Appliance background, may think of
> Service Chain as “Middle Boxes” being overplayed over existing network
> infrastructure.
>
> ·Application developers may think of “Service Chain” as connecting
> various application instances together, such as “Web Server’ to “App
> Server” and to “DB Server”.
>
> To make everyone on the same page, I think that it is important to
> define some common terminologies. To make it more clear on what
> “services” are chained together and what components are involved, even
> though it is possible that all those services chained together could
> have common architecture & solutions.
>
> Let’s first break all “services” into pieces: (granted that multiple
> pieces can exist in one physical/virtual device and can be connected
> together to form a sellable service to clients).
>
> There are:
>
> -Interconnections: |--
> -Functions |
>                     |- L2-3 service functions {e.g. steering traffic to
> different gateway/domains based on dynamic policies to achieve special
> purposed forwarding}
>
>                     |
>
>                                    |- L4 Service function: {e.g. TCP
> Acceleration, NAT, Firewall,  caching, web }
>
>                                   |
>
>                                   |- L7 Service function {e.g. Web
> Proxy, content filtering, statistics collection, etc}
>
> Since each service function can have multiple instances, from network
> perspective, it is really the instances of service function being
> interconnected.
>
> *_Hard Questions:_*
>
> ·Many people whom I have talked to during IETF week have stated that NSC
> is about chaining L4-7 service functions.
>
> ·But some people (and a presentation at the NSC BoF) mentioned that NSC
> also includes chaining L2-3 service functions based on various policies,
> does it?
>
> ·Should NSC include chaining various “application” modules?
>
> In general, most L7 services terminate TCP/UDP sessions. Proxy based L7
>   services regenerate new data flows. And packet based L7 services let
> the packets pass through with some level of header changes
>
> *_I think the general NSC problem statement should start with those
> terminologies and state clearly of what components are included. _*
>
> Thanks, Linda Dunbar
>
>
>
> [email-masked]

---

From: <[email-masked]>
Date: Tue, 6 Aug 2013 10:57:34 +0200

Hi,

That is also my view. The underlying network provides basic connectivity and forwarding based on Layer 2 and Layer 3 information. This connectivity is being used in order to connect the service bringing nodes to one (or more) service chains.

An SDN based approach can be seen as one solution for service chaining; packet goes to the controller/application, controller builds a path ("flow") based on packet analyses/classification through the network to connect service bringing nodes. But from my understanding this is not the major scope of the discussions we had until now.

It makes sense to have at least a clear understanding from what is in and out of scope and I think that definitions may help.

  Regards

    Nic

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Joel M. Halpern
Gesendet: Montag, 5. August 2013 17:33
An: Jim Guichard (jguichar)
Cc: [email-masked]; [email-masked]; [email-masked]; Linda Dunbar
Betreff: Re: [nsc] Critical step of NSC: basic terminologies and necessary components

Yours,
Joel M. Halpern

On 8/5/13 9:01 AM, Jim Guichard (jguichar) wrote:
> Service Chain as "Middle Boxes" being overplayed over existing network
> infrastructure.
>
> ·Application developers may think of "Service Chain" as connecting
> various application instances together, such as "Web Server' to "App
> Server" and to "DB Server".
>
> "services" are chained together and what components are involved, even
> Let's first break all "services" into pieces: (granted that multiple
> ·Should NSC include chaining various "application" modules?
>