Subject: [nsc] Problem statement draft: quinn-nsc-problem-statement

From: Thomas Narten <[email-masked]>
Date: Fri, 25 Oct 2013 12:09:56 -0400

Hi.

To date, one problem statement draft
(draft-quinn-nsc-problem-statement-03.txt) has been produced for the
SFC effort.

It has served as the basis for both the current and prior BOF, and my
read of the mailing list discussions suggests that folk seem generally
OK with it. I have not seen fundamental disagreements with its content
or calls for substantial additions.

Any disagreement with this assessment?

Assuming there is agreement with the above, and that a WG is formed, I
would expect that:

1) we would formally adopt the document as a WG document in fairly
short order and

2) close its contents in relatively short order and send to the IESG
for publication.

For most WGs, a problem statement is the highest priority work item to
complete, as it sets the stage for all followup work. Also, if there
are significant gaps or shortcomings in a problem statement, it tends
to spell trouble for the WG as it starts doing work (it's hard to get
agreement on solutions when there isn't really agreement on what the
solution needs to actually do). Thus, complete the problem
statement is a priority, and we want to get the contents right.

So with that in mind, are there still substantive issues we need to
work out in the problem statement? Or do people think it is in pretty
good shape? What still needs to be added to the document? (These
questions are aimed at both the list and the document authors...)

Thomas

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 25 Oct 2013 19:14:53 +0000

Tom,

I have few questions on this draft:

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

What does "specific instance of service function" means in this context? 

Section 3:

       "Service Overlay: Service chaining utilizes a service specific
       overlay that creates the service topology: the overlay creates a
       path between service nodes.  The service overlay is independent
       of the network topology and allows operators to use whatever
       overlay or underlay they prefer and to locate service functions
       in the network as needed."

This is not a clear definition of a "service overlay". It just refers to a "path" but does not define it.

Section 5:

       "L3VPN[L3VPN]: The L3VPN working group is responsible for
       defining, specifying and extending BGP/MPLS IP VPNs solutions.
       Although BGP/MPLS IP VPNs can be used as transport for service
       chaining deployments, the service chaining WG focuses on the
       service specific protocols, not the general case of VPNs.
       Furthermore, BGP/MPLS IP VPNs do not address the requirements for
       service chaining."

What are the "service specific protocols"?

draft-filsfils-rtgwg-segment-routing has a section on "Service Segments".  Is there any relation to this work? 

Maria

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Narten
> Sent: Friday, October 25, 2013 12:10 PM
> To: [email-masked]
> Subject: [nsc] Problem statement draft: quinn-nsc-problem-statement
> 
> Hi.
> 
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 25 Oct 2013 20:31:49 +0000

Quick clarification:

Draft-quinn-nsc-problem-statement-03 was replaced by
http://tools.ietf.org/html/draft-quinn-sfc-problem-statement-01 .. Please
refer to this version if commenting.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 25 Oct 2013 20:33:51 +0000

Thanks Jim.  One extra note: we'll post an "edited" version with editors and contributors (in lieu of the long author list) once submission open again.

Paul

---

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

Thomas, 

There is another Service Chaining problem statement draft:

"Layer 4-7 Service Chain problem statement" (https://datatracker.ietf.org/doc/draft-dunbar-l4-l7-sc-problem-statement/
 )

Linda

> Sent: Friday, October 25, 2013 11:10 AM
> To: [email-masked]

---

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

Hi Linda.

> "Layer 4-7 Service Chain problem statement"
>  (https://datatracker.ietf.org/doc/draft-dunbar-l4-l7-sc-problem-statement/
>  )

Right. But the contents of this draft deals with specific subset of
the overall problem space covered in draft-quinn-sfc-arch-02.txt. The
two documents are not in conflict with each other and draft-dunbar is
not an alternate problem statement formulation. I.e., the two
documents complement each other.

Agreed?

Thomas

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 28 Oct 2013 21:07:59 +0000

Hi Maria,

Please see inline.  I hope to see you in Vancouver :)

Paul

> What does "specific instance of service function" means in this context? 

A service function provides some kind of "functionality"; this functionality may be required at multiple points in the network. 

This by definition means that multiple "instances" of that service function are available for consumption (e.g. Firewall1 vs. Firewall1@locationX, Firewall1@locationY). Each service function is identifiable using a unique ID (noting that a service function instance that provides the *same* functionality as another service function instance may use the same ID).  We will update the definition to be more detailed and include a definition of a service function ID (SFID)".

> This is not a clear definition of a "service overlay". It just refers to a "path" but does not define it.

PQ> The reason we call it a service overlay is that the overlay topology is not needed to src --> dst traffic except for the fact that service
are being added. 

> What are the "service specific protocols"?

PQ>  Any protocol defined by the proposed WG.

> draft-filsfils-rtgwg-segment-routing has a section on "Service Segments".  Is there any relation to this work? 

PQ>  SR can be used as one of the _possible_ transports.  There are many
other we need to consider.

---

From: Jerome Moisand <[email-masked]>
Date: Mon, 28 Oct 2013 22:34:11 +0000

Hi Thomas,

Good question!

Given that:
1. the WG hasn't been formally formed yet
2. the list of documented use cases remain rather limited at the IETF level, and a work in progress in other industry forums (e.g. BBF, ETSI NFV)

It does seem a tad premature to conclude that the problem statement I-D is nearing completion. It certainly did make very good progress though, but I would think that it still deserves more rounds of reviews, notably fed by analysis of new use cases.

Now, to more directly answer your question, it seems to me that one important side of things is missing in the problem statement, in the context of broadband scenarios (fixed broadband ala BBF; mobile broadband ala 3GPP). How to create a proper linkage to existing subscriber management mechanisms (4 levels: database, decision/authorization, enforcement, accounting), so that service chaining can be used as an (hopefully fairly simple & natural) extension of such mechanisms, hence minimizing OSS disruption and speeding up deployment of new services. This is of course an issue specific to a given class of use cases and may or may not apply in other contexts.

In the same vein, the problem statement doesn't seem to touch very much on implications of network-hosted business services, notably VPN concepts and how to have service chaining co-exist and be compatible with such L2/L3 service mechanisms (e.g. running service chains in a VPN-contextualized manner).

Maybe the higher level point here is that the current problem statement is very generic (and doing a nice job of staying so!), while it would probably be beneficial to expand it with considerations which are more specific to a large class of use cases & applications.

Tx
Jerome

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, October 25, 2013 4:32 PM
To: Thomas Narten; [email-masked]
Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement

Quick clarification:

Draft-quinn-nsc-problem-statement-03 was replaced by
http://tools.ietf.org/html/draft-quinn-sfc-problem-statement-01 .. Please refer to this version if commenting.

On 10/25/13 12:09 PM, "Thomas Narten" <[email-masked]> wrote:

>solution needs to actually do). Thus, complete the problem statement is 
>a priority, and we want to get the contents right.
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 29 Oct 2013 13:07:18 +0000

Hi Jerome,

We deliberately wrote the problem statement to be generic. As you pointed
out there are many use cases with their own set of problems to solve.
Therefore it seemed more appropriate to have a high level problem
statement and then document the intricacies of individual use cases in
separate documents; for broadband scenarios I would envisage a use case
document with a more detailed description of the problem space, same thing
for VPN (whether shared services within a VPN or service chains that are
private to a given VPN).

On 10/28/13 6:34 PM, "Jerome Moisand" <[email-masked]> wrote:

>2. the list of documented use cases remain rather limited at the IETF
>level, and a work in progress in other industry forums (e.g. BBF, ETSI
>NFV)
>
>It does seem a tad premature to conclude that the problem statement I-D
>is nearing completion. It certainly did make very good progress though,
>but I would think that it still deserves more rounds of reviews, notably
>fed by analysis of new use cases.
>
>Now, to more directly answer your question, it seems to me that one
>important side of things is missing in the problem statement, in the
>context of broadband scenarios (fixed broadband ala BBF; mobile broadband
>ala 3GPP). How to create a proper linkage to existing subscriber
>management mechanisms (4 levels: database, decision/authorization,
>enforcement, accounting), so that service chaining can be used as an
>(hopefully fairly simple & natural) extension of such mechanisms, hence
>minimizing OSS disruption and speeding up deployment of new services.
>This is of course an issue specific to a given class of use cases and may
>or may not apply in other contexts.
>
>In the same vein, the problem statement doesn't seem to touch very much
>on implications of network-hosted business services, notably VPN concepts
>and how to have service chaining co-exist and be compatible with such
>L2/L3 service mechanisms (e.g. running service chains in a
>VPN-contextualized manner).
>
>Maybe the higher level point here is that the current problem statement
>is very generic (and doing a nice job of staying so!), while it would
>probably be beneficial to expand it with considerations which are more
>specific to a large class of use cases & applications.
>
>Tx
>Jerome
>