Subject: [nsc] Current Proposed SFC charter

From: Thomas Narten <[email-masked]>
Date: Wed, 06 Nov 2013 11:07:27 -0800

Hi.

Current charter can be found at https://datatracker.ietf.org/doc/charter-ietf-sfc/.

It contains the revised management text as well as updated milestones.

All known issues have been addressed. If there are any remaining
issues, please speak up!

Charter charter-ietf-sfc-00-04

Networks, servers, storage technologies, and applications, have all
undergone significant change in recent years with the introduction of
virtualization, network overlays, and orchestration. Service delivery
is currently both a technical and organizational challenge that 
involves significant modification to the network configuration. 
Services are typically implemented by the ordered combination of a 
number of service functions that are deployed at different points
within the network. Today, a common deployment model has service
functions physically inserted on the data forwarding path between
communicating peers. Going forward, however, there is a desire to
move to a different model, where service functions are not required to 
reside on the default data path and traffic is instead steered through
services, wherever they are deployed. 

For a given service, the abstracted view of the required service functions
and the order in which they are to be applied is called a Service Function
Chain (SFC). Since a given service function may be available on more
than one node within a network, a Service Function Chain is instantiated
via the selection of specific service function instances and the network
nodes on which they are provided, thereby forming a service topology: 
this is called a Service Function Path. The service functions may be
applied at a specific layer within the network protocol stack (network 
layer, application layer, etc.). 

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. 

Specifically, the SFC WG is chartered to deliver the following: 

1) Problem Statement: This document will provide a summary of the
    problem space to be addressed by the WG including example high-
    level use cases. Additionally, the WG will normalize nomenclature
    and definitions for service function chaining. 

2) Architecture: This document will provide a description of the
    architectural building blocks and their relationships including
    interconnection, placement of capabilities, management,
    diagnostics, design analysis, and security models, as well as 
    requirements on the protocol mechanisms. 

3) Generic Service Function Chaining Encapsulation: A document will
    describe the single service-level data plane encapsulation format for
    conveying the service function chain and the service function path,
    and for communicating context information between nodes that
    implement service functions. It is intended that the encapsulation 
    be agnostic to the layer at which it is applied and the service that is
    being constructed. That is, the same encapsulation may be used on
    a service function path realized at the network layer or at any other
    layer, and the same encapsulation will apply for the construction of
    service function paths regardless of the actual service. 

4) Control Plane Mechanisms: A set of documents will be developed to
    describe requirements and protocols necessary to convey information
    to service function implementation points. Where possible, existing
    IETF protocols will be used and extended. All protocol extensions
    work should be carried out in the working groups responsible for the 
    protocols being modified in coordination with this working group, but
    may be done in this working group after agreement with all the
    relevant WG chairs and responsible ADs. 

5) Manageability: Work on the management and configuration of service
    functions in support of SFC components will certainly be needed,
    but first needs to be better understood and scoped.
    
Proposed Milestones

Apr 2014 Submit to IESG Informational document(s) defining the problem
statement and core use cases for Service Function Chaining

May 2014 Consult with OPS Area on possible charter modifications for
management and configuration of SFC components

Jan 2015 Submit to IESG Informational document defining the
architecture for SFC

Jan 2015 Submit to IESG requirements for a generic service function
chaining encapsulation protocol

Aug 2015 Submit to IESG Standards Track document specifying the
generic service function chaining header encapsulation

Thomas

---

From: <[email-masked]>
Date: Thu, 7 Nov 2013 10:29:03 +0100

Hi,

A few comments inline.

[snip] 

Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, wherever they are deployed. 
[CJ] This last sentence reads strange to me. I don't think there is a desire to move to a different model per se, but rather the need to enforce differentiated traffic forwarding policies that best accommodate the very nature of the different yet complex services, for the sake of optimized service delivery and operation. Such services are designed as the (ordered) combination and invocation of several elementary functions that are located in various regions of the network or devices connected to that network. The above sentence seems to suggest that function chaining has no value if the said functions are located on the default data path, which I think is wrong.

For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a Service Function Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a service topology: 
this is called a Service Function Path.
[CJ] The above causality effect (introduced by the "since") is slightly misleading, as there is need to instantiate functions anyway, that is whether the said function is unique or not. I would therefore suggest something in the following spirit: "A service function chain is structured by the selection of specific service functions that may reside in different network nodes, thereby forming a service function path. A given service function may be supported by different network nodes and the service function chains that include such function are structured so that such function is unequivocally identified."

The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). 

The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment.
[CJ] rather "service delivery and operation".
 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. 
[CJ] Such framework document should be explicitly mentioned in the milestones below.
The working group will also examine what information needs to be gathered from the network
[CJ] "...from the network nodes"
 and service functions in support of service function chaining and how that information may be made available to nodes that implement the service functions. 

2) Architecture: This document will provide a description of the
    architectural building blocks and their relationships including
    interconnection, placement of capabilities,
[CJ] What does "placement of capabilities" mean exactly? It sounds like an organic approach (rather than a functional approach introduced by the inventory of the various building blocks) which I don't think belongs to an architecture document. For example, whether a NAT64 function is embedded in a GGSN or elsewhere is clearly not the kind of consideration that should be taken into account at this stage, because it's rather implementation-specific.
 management,
    diagnostics, design analysis, and security models, as well as 
    requirements on the protocol mechanisms. 

    layer,
[CJ] What does "service function path realization" mean? Does this suggest considerations about how a SFC is structured, picking network functions, upper layer functions or a combination thereof? If so, I would elaborate accordingly.
 and the same encapsulation will apply for the construction of

5) Manageability: Work on the management and configuration of service
    functions in support of SFC components will certainly be needed,
    but first needs to be better understood and scoped.
[CJ] And yet, the "architecture" milestone explicitly identifies management considerations (which I fully support). If manageability strictly refers to SF configuration and management, I would agree this is not in the scope of the WG. But I would then elaborate on what management means in the context of the architecture document above: I think this would relate to the ability for the PDP to dynamically discover the service functions that are supported by the network nodes, the actual structuring of the different chains, how the corresponding SFC-derived policy provisioning information is provided to the classifier nodes, how chains are managed as a function of the events that may occur in the network (e.g., a node becomes unavailable) and how such events affect SFC operation or design.
    
Proposed Milestones
[CJ] Please add a milestone about the framework, as mentioned above.

Apr 2014 Submit to IESG Informational document(s) defining the problem statement and core use cases for Service Function Chaining

May 2014 Consult with OPS Area on possible charter modifications for management and configuration of SFC components

Jan 2015 Submit to IESG Informational document defining the architecture for SFC

Jan 2015 Submit to IESG requirements for a generic service function chaining encapsulation protocol

Aug 2015 Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation

[CJ] Cheers,
[CJ] Christian.

Thomas

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ken Gray <[email-masked]>
Date: Thu, 7 Nov 2013 15:37:42 +0000

A few of my own comments in line.
________________________________________
From: [email-masked] <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, November 07, 2013 4:29 AM
To: Thomas Narten; [email-masked]
Subject: Re: [nsc] Current Proposed SFC charter

Hi,

A few comments inline.

[snip]

[KG] So cut the sentence after "data path" and nobody will be offended?

[KG] OR, you could just snip the word "Since" from the beginning of the original sentence.

[snip] Cheers.

---

From: Sumandra Majee <[email-masked]>
Date: Mon, 11 Nov 2013 23:45:41 +0000

Generic Service Function Chaining Encapsulation: A document will

[SM] What does it mean by a single service-level encapsulation,  a new encapsulation format
            or an ability to select one encapsulation format that fits the need for a given service chain?
           The ability to select a specific encapsulation  would be a management plane decision.
          There are quite a few existing encapsulation methods that can possibly be reused to provide
          context information between   service nodes. I have seen mention of GRE, for HTTP based
          applications contexts are transferred via headers.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

All known issues have been addressed. If there are any remaining issues, please speak up!

Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. Service delivery is currently both a technical and organizational challenge that involves significant modification to the network configuration. 
Services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within the network. Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, wherever they are deployed. 

For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a Service Function Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a service topology: 
this is called a Service Function Path. The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). 

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. 

    
Proposed Milestones

Thomas

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 00:36:11 +0000

Sumandra,

As I understand it, an SFC packet traversing from PDP to SF or from SF to SF will look like:

+------------------------+
|        "transport"         |
+------------------------+
|      service header    |
+------------------------+
|   original IP header  |
+------------------------+
|                                         |
|  original IP payload  |
|                                         |
+------------------------+

Where service header contains, at a minimum, enough information to allow the packet to be propagated along the full length of the chain, and optionally, other metadata that enhances the operation of one or more service functions.

 And where "transport" could conceivably be any of, but not limited to:

* Ethernet
* Ethernet + LLC2
* Ethernet + MPLS
* Ethernet + IP + GRE
* Ethernet + IP +UDP

Also, "original" in the diagram above is not meant to imply immutability, but rather to specify the packet that is propagated from preceding entity to succeeding entity, prior to encapsulation.

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

    
Proposed Milestones

Thomas

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 11 Nov 2013 20:01:53 -0500

It appears that within service (chain) header, individual service member would need either,
offset to original packet or total size of the service chain header so that service delivery
component can locate the original packet to perform the service.

Alternately, service proxy function (mentioned by you) at the doorstep,
perform some push/pop action during entry/exit of the service point.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 11, 2013 7:36 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: Re: [nsc] Current Proposed SFC charter

Sumandra,

+------------------------+
|        "transport"         |
+------------------------+
|      service header    |
+------------------------+
|   original IP header  |
+------------------------+
|                                         |  original IP payload  |
|                                         |
+------------------------+

* Ethernet
* Ethernet + LLC2
* Ethernet + MPLS
* Ethernet + IP + GRE
* Ethernet + IP +UDP

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

    
Proposed Milestones

Thomas

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 02:35:24 +0000

Himanshu,

The service chain header does, indeed, need to be self-descriptive with respect to its size in one manner or another. 

While the service header could be designed as a stack of per-service-function entries, there is sensitivity to packet growth and in particular, unbounded packet growth.    Most discussion, so far, has been around a single chain ID that is commonly understood along the entire service chain (via coordinated provisioning or an as-yet unspecified control plane protocol).

See http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ for one proposal on design of the service chain header.

   Ron

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 8:02 PM
To: Ron Parker; Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

It appears that within service (chain) header, individual service member would need either, offset to original packet or total size of the service chain header so that service delivery component can locate the original packet to perform the service.

Alternately, service proxy function (mentioned by you) at the doorstep, perform some push/pop action during entry/exit of the service point.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 11, 2013 7:36 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: Re: [nsc] Current Proposed SFC charter

Sumandra,

* Ethernet
* Ethernet + LLC2
* Ethernet + MPLS
* Ethernet + IP + GRE
* Ethernet + IP +UDP

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

    
Proposed Milestones

Thomas

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 12 Nov 2013 02:55:53 +0000

Ron,

The service header is meant to carry the context which can *also* be derived (for example use source ip and vlan to identify chainID and position) or encapsulated as part of another tunnel header. So this could be optional IMHO.   

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 4:36 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Sumandra,

* Ethernet
* Ethernet + LLC2
* Ethernet + MPLS
* Ethernet + IP + GRE
* Ethernet + IP +UDP

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

    
Proposed Milestones

Thomas

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 03:01:53 +0000

Sumandra,

The intention of service function chaining is to allow for operation at the fully qualified flow level, or even finer grained at the transaction level (this is an implementation matter for the PDP).     All flows from the same source IP do not necessarily follow the same chain.   Source IP, therefore,  does not identify the chain ID.    Another intention of service function chaining is to operate over any network topology and not be limited to a single LAN.   Thus, while VLAN may be part of the transport, it does not adequately identify the service chain, either.

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 9:56 PM
To: Ron Parker; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 4:36 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Sumandra,

* Ethernet
* Ethernet + LLC2
* Ethernet + MPLS
* Ethernet + IP + GRE
* Ethernet + IP +UDP

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

    
Proposed Milestones

Thomas

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 12 Nov 2013 03:09:33 +0000

Ron,

Absolutely, that was an example of one type of derivation. However this could be augmented with classification result, again one more example. 

>>All flows from the same source IP do not necessarily follow the same chain.   
Correct. It is also not necessary that all transaction of the same flow follow the same chain either. So why stop at flow itself.

Again the point here is that do we always need SFC header or Not.

Sumandra

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 7:02 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Sumandra,

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 9:56 PM
To: Ron Parker; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 4:36 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Sumandra,

* Ethernet
* Ethernet + LLC2
* Ethernet + MPLS
* Ethernet + IP + GRE
* Ethernet + IP +UDP

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

    
Proposed Milestones

Thomas

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 03:15:50 +0000

Sumandra,

As was discussed in Vancouver, there are already many existing ways to accomplish service chaining.     But none of them provide a sufficient combination of interoperability, flexibility, and resiliency.   A single service chain encapsulation will go a long way to ensuring these goals.   It  may not be the absolutely most efficient approach for every single network topology and every single use case, but its ubiquitous nature should improve its adoption. 

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 10:10 PM
To: Ron Parker; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Ron,

Sumandra

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 7:02 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Sumandra,

   Ron

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 9:56 PM
To: Ron Parker; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Ron,

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 4:36 PM
To: Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Sumandra,

* Ethernet
* Ethernet + LLC2
* Ethernet + MPLS
* Ethernet + IP + GRE
* Ethernet + IP +UDP

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, November 06, 2013 11:07 AM
To: [email-masked]
Subject: [nsc] Current Proposed SFC charter

Hi.

    
Proposed Milestones

Thomas

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 11 Nov 2013 22:33:21 -0500

Hi Ron,

  I was unable to make the SFC BoF due to a conflict with CDNI, but I
  had a similar question wrt bullet 11 in section 2 of the problem statement:

    11.  Per-Service (re)Classification: Classification occurs at each
         service, independent from previously applied service functions.
         These unrelated classification events consume resources per
         service.  More importantly, the classification functionality
         often differs per service function and service function cannot
         leverage the results from other deployed network or service.

  as it relates to section 5.2 of the framework document:

    The SFC Classifier classifies packets based on (some of) the contents
    of the packet header.  Concretely, it classifies packets based on the
    possible combination of one or more header fields, such as source
    address, destination address, DS field, protocol ID, source port and
    destination port numbers, and any other information.

  A packet-based classifier as described in the framework document would
  seem to be limited in what it can classify?  The service function 
  identifier lookup does not seem to be a significant optimization over
  a packet-based 5-tuple lookup?  There seems to be some missing detail
  wrt how classification information is determined and reused?

  When thinking about higher level services, e.g., HTTP and TLS encrypted
  flows, a packet-based classifier seems inadequate?  I was also wondering
  how independent HLS segment requests might be classified and associated?
  Were these types of use cases discussed in the BoF?

thanx.

--  Kevin J. Ma

> Sent: Monday, November 11, 2013 10:16 PM
> As was discussed in Vancouver, there are already many existing ways to
> accomplish service chaining.     But none of them provide a sufficient
> combination of interoperability, flexibility, and resiliency.   A single
> service chain encapsulation will go a long way to ensuring these goals.
> It  may not be the absolutely most efficient approach for every single
> network topology and every single use case, but its ubiquitous nature
> should improve its adoption.
> 
>    Ron
> 
> 
> Absolutely, that was an example of one type of derivation. However this
> could be augmented with classification result, again one more example.
> 
> Correct. It is also not necessary that all transaction of the same flow
> follow the same chain either. So why stop at flow itself.
> 
> The intention of service function chaining is to allow for operation at
> the fully qualified flow level, or even finer grained at the transaction
> level (this is an implementation matter for the PDP).     All flows from
> the same source IP do not necessarily follow the same chain.   Source IP,
> therefore,  does not identify the chain ID.    Another intention of
> service function chaining is to operate over any network topology and not
> be limited to a single LAN.   Thus, while VLAN may be part of the
> transport, it does not adequately identify the service chain, either.
> 
>    Ron
> 
> 
> The service header is meant to carry the context which can *also* be
> derived (for example use source ip and vlan to identify chainID and
> position) or encapsulated as part of another tunnel header. So this could
> be optional IMHO.
> 
> Where service header contains, at a minimum, enough information to allow
> the packet to be propagated along the full length of the chain, and
> optionally, other metadata that enhances the operation of one or more
> service functions.
> 
> Also, "original" in the diagram above is not meant to imply immutability,
> but rather to specify the packet that is propagated from preceding entity
> to succeeding entity, prior to encapsulation.
> 
>    Ron
> 
> 
> virtualization, network overlays, and orchestration. Service delivery is
> currently both a technical and organizational challenge that involves
> significant modification to the network configuration.
> Services are typically implemented by the ordered combination of a number
> of service functions that are deployed at different points within the
> network. Today, a common deployment model has service functions physically
> inserted on the data forwarding path between communicating peers. Going
> forward, however, there is a desire to move to a different model, where
> service functions are not required to reside on the default data path and
> traffic is instead steered through services, wherever they are deployed.
> 
> Chain (SFC). Since a given service function may be available on more than
> one node within a network, a Service Function Chain is instantiated via
> the selection of specific service function instances and the network nodes
> on which they are provided, thereby forming a service topology:
> 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
> 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.
> 
> Aug 2015 Submit to IESG Standards Track document specifying the generic
> service function chaining header encapsulation
> 
> 
> 
> 
> 
> Thomas
>

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 03:40:55 +0000

Hi, Kevin.

I agree that the classifier should not be constrained.   While a full specification of the classifier seems beyond scope to me, a discussion of the overall design implications of the classifier supporting the protocols and techniques you describe below could make for an interesting I-D :).

   Ron

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 10:33 PM
To: Ron Parker; Sumandra Majee; Thomas Narten; [email-masked]
Subject: RE: [nsc] Current Proposed SFC charter

Hi Ron,

thanx.

--  Kevin J. Ma

> Absolutely, that was an example of one type of derivation. However 
> this could be augmented with classification result, again one more example.
> 
> Correct. It is also not necessary that all transaction of the same 
> flow follow the same chain either. So why stop at flow itself.
> 
> The intention of service function chaining is to allow for operation 
> at the fully qualified flow level, or even finer grained at the transaction
> position) or encapsulated as part of another tunnel header. So this 
> could be optional IMHO.
> 
> Where service header contains, at a minimum, enough information to 
> allow the packet to be propagated along the full length of the chain, 
> and optionally, other metadata that enhances the operation of one or 
> more service functions.
> 
> Also, "original" in the diagram above is not meant to imply 
> immutability, but rather to specify the packet that is propagated from 
> preceding entity to succeeding entity, prior to encapsulation.
> 
>    Ron
> 
> 
> Current charter can be found at 
> https://datatracker.ietf.org/doc/charter-
> ietf-sfc/.
> 
> communicating peers. Going forward, however, there is a desire to move 
> to a different model, where service functions are not required to 
> reside on the default data path and traffic is instead steered through services, wherever they are deployed.
> 
> For a given service, the abstracted view of the required service 
> functions and the order in which they are to be applied is called a 
> Service Function Chain (SFC). Since a given service function may be 
> available on more than one node within a network, a Service Function 
> Chain is instantiated via the selection of specific service function 
> instances and the network nodes on which they are provided, thereby forming a service topology:
> 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.
>

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 11 Nov 2013 22:57:19 -0500

> the overall design implications of the classifier supporting the protocols
> and techniques you describe below could make for an interesting I-D :).

I agree, but I guess I'll take that as a no, on whether it was discussed?

It's hard to evaluate the utility of the service function identifier without
a better understanding of how the classification works, how the servicce chains
are defined, and what the overhead is in doing lookups based on the service
function identifier, as opposed to reuseable classification info, especially
where TCP/HTTP/TLS level termination is involved.

Note: I did not see any minutes posted yet from the BoF?  Were hums taken?
      I'd be interested in knowing the outcome before thinking about I-Ds.  ;-P

thanx.

--  Kevin J. Ma

> Sent: Monday, November 11, 2013 10:41 PM
> To: Kevin J Ma; Sumandra Majee; Thomas Narten; [email-masked]
> I agree that the classifier should not be constrained.   While a full
> specification of the classifier seems beyond scope to me, a discussion of
> the overall design implications of the classifier supporting the protocols
> and techniques you describe below could make for an interesting I-D :).
>
>    Ron
>
>
> >           context information between   service nodes. I have seen
> mention
> > of GRE, for HTTP based

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 05:08:27 +0000

Kevin,

Classification mechanism is outside the scope of SFC. It can be based on
the packet or information not in the packet(environmental attributes for
instance) or a combination thereof. What is important is that such
classification aids in traffic selection and service path identification.
It is no different from a policy in this regard except that the policy now
specifies the service path.
Further, classification is not limited to the network elements but the
service functions as well. Some of this is described in the architecture
drafts as well - "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/".

Surendra.

On 11/11/13 7:33 PM, "Kevin J Ma" <[email-masked]> wrote:

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>Ron
>> Parker
>>could
>> As I understand it, an SFC packet traversing from PDP to SF or from SF
>>to
>> SF will look like:
>> 
>>immutability,
>>             or an ability to select one encapsulation format that fits
>>the
>> need for a given service chain?
>>number
>>functions
>>than
>>framework
>>and

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 05:29:11 +0000

Sumandra,

There is need for two kinds of information.
a) that identifies the forwarding path the traffic (packets) requiring
service(s) must be forwarded along - the service path
b) that is produced at one point on the service path for consumption at
one or more points down the service path

(b) may or may not be derivable at the point it is being consumed. (b) may
help (a) or (b) may be a pre-requisite for service delivery at one or more
points along the service path.

Given that a variety of hardware/software entities have to implement/parse
such a service header, it would be reasonable to impose constraints on
such a service header, including whether it should be optional or not;
primarily to ease implementation and enable interoperability.

Surendra.

On 11/11/13 6:55 PM, "Sumandra Majee" <[email-masked]> wrote:

>Sumandra Majee
>the need for a given service chain?
>mention of GRE, for HTTP based
>Thomas Narten
>https://datatracker.ietf.org/doc/charter-ietf-sfc/.
>
>network. Today, a common deployment model has service functions
>physically inserted on the data forwarding path between communicating
>peers. Going forward, however, there is a desire to move to a different
>model, where service functions are not required to reside on the default
>data path and traffic is instead steered through services, wherever they
>are deployed. 
>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 12 Nov 2013 00:46:21 -0500

Hi Surendra,

  Classification may be out of scope, but the level of service that is
  applicable is dependent upon the level of classification that can be
  performed.  An assumption of packet level encapsulation has implications
  on the level of classification being performed?  If the stated goals are
  for firewall and load balancer functionality, then the application level
  nature of those functions needs to be taken into account?  If, on the
  other hand, the service function scope is limited due to limitations in
  classification, that would be and important piece of information?

  Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork points
  of the service paths seem like re-classification points?  Is that the
  interpretation from the architecture perspective?  Or is the service
  function chain classification exclusive of DPI functionality?

thanx.

--  Kevin J. Ma

> From: Surendra Kumar (smkumar) [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2013 12:08 AM
> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; [email-masked]
> allow
> >>     be agnostic to the layer at which it is applied and the service
> that
> >> is
> issues,
> >> please speak up!
> is
> >>physically
> >>     be agnostic to the layer at which it is applied and the service
> that
> >> is
> architecture
> >> for SFC

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 06:00:35 +0000

>  function chain classification exclusive of DPI functionality?
<SK> I have not fully read that draft yet. But in general, as described in
the arch draft, the collection of services form a graph, segments of which
are service paths. Yes, reclassification can change the service path and
re-classification may happen at any node along a service path.

Surendra.
>> drafts as well -
>>"https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/".
>>
>> Surendra.
>>
>>this
>> >> >>All flows from the same source IP do not necessarily follow the
>>same
>> >> chain.
>>flow
>>at
>> >> [SM] What does it mean by a single service-level encapsulation,  a
>>new
>> >> encapsulation format
>> >>           There are quite a few existing encapsulation methods that
>>can
>> >> possibly be reused to provide
>>generic

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 12 Nov 2013 01:52:29 -0500

> Yes, reclassification can change the service path and

Just to expand on that, going back to the original question about
service header encapsulation, is it intended that a chain that
is re-classified will get a new chain ID which fully describes
a chain that is a superset of the original chain ID, prior to
DPI-based re-classification?  (assuming the goal is "a single
chain ID that is commonly understood along the entire service chain"
http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html)

And the applicable subset of the permutative list of service
paths would be configured at each appropriate service node?
e.g., ID 1: NAT + firewall + DPI
      ID 2: NAT + firewall + DPI + AV
      ID 3: NAT + firewall + DPI + AV + NAT
      ID 4: NAT + firewall + DPI + NAT
      ID 5: NAT + firewall + DPI + AV + LB
      ID 6: NAT + firewall + DPI + LB
      ID 7: NAT + firewall + DPI + LB + CACHE
      ID 8: NAT + firewall + DPI + CACHE
      ID 9: NAT + firewall + DPI + optimizer + LB
      ID 10: NAT + firewall + DPI + optimizer + LB + CACHE
      ID 11: NAT + firewall + DPI + optimizer + CACHE
Would every flow then be initially classified as ID 1, but
eventually get re-classified to ID 2-11, after the DPI phase?

thanx.

--  Kevin J. Ma

> Sent: Tuesday, November 12, 2013 1:01 AM
> >> >> the same source IP do not necessarily follow the same chain.
> Source
> >> >>IP,
> >> >> service function chaining is to operate over any network topology
> and
> >> >>not
> >> >>     describe the single service-level data plane encapsulation
> format
> >> >>for
> >> >>     layer, and the same encapsulation will apply for the
> construction
> >> of
> >> >>            The ability to select a specific encapsulation  would be
> a
> >> >> management plane decision.
> >> >> service functions are not required to reside on the default data
> path
> >> >>and
> >> >>     describe the single service-level data plane encapsulation
> format
> >> >>for
> >> >>     layer, and the same encapsulation will apply for the
> construction
> >> of
> >> >>     protocols being modified in coordination with this working
> group,
> >> >>but

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 11:44:40 +0000

Hi, Kevin

You ask a great question about branching the graph.  The details around how to convey the selection of the subtree/subgraph are still to be defined.   Is it one chain id for the whole graph?   Does each branch have its own chain id?   Some combination?

   Ron

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Tue, 12 Nov 2013 11:57:01 +0000

Branching/forking is a very interesting topic of SFC. About the re-classification point, probably we shall not limit it to DPI. It is also possible that packets go to different branches after been processed by a certain service function, decision of which branches to go is made based on the result of service function's process, i.e. not just re-classification by DPI.

Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, November 12, 2013 7:45 PM
To: Kevin J Ma
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Hi, Kevin

   Ron

On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" <[email-masked]> wrote:

> service header encapsulation, is it intended that a chain that is 
> re-classified will get a new chain ID which fully describes a chain 
> that is a superset of the original chain ID, prior to DPI-based 
> re-classification?  (assuming the goal is "a single chain ID that is 
> commonly understood along the entire service chain"
> And the applicable subset of the permutative list of service paths 
> would be configured at each appropriate service node?
>      ID 11: NAT + firewall + DPI + optimizer + CACHE Would every flow 
> then be initially classified as ID 1, but eventually get re-classified 
> to ID 2-11, after the DPI phase?
> 
> thanx.
> 
> --  Kevin J. Ma
> 
>>> nature of those functions needs to be taken into account?  If, on 
>>> the other hand, the service function scope is limited due to 
>>> limitations in classification, that would be and important piece of information?
>>> 
>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork 
>>> points of the service paths seem like re-classification points?  Is 
>>> that the interpretation from the architecture perspective?  Or is 
>>> the service function chain classification exclusive of DPI functionality?
>> <SK> I have not fully read that draft yet. But in general, as 
>> described in the arch draft, the collection of services form a graph, 
>> segments of which are service paths. Yes, reclassification can change 
>> the service path and re-classification may happen at any node along a service path.
>> 
>> Surendra.
>>> 
>>> thanx.
>>> 
>>> --  Kevin J. Ma
>>> 
>>>> Classification mechanism is outside the scope of SFC. It can be 
>>>> based
>> on
>>>> the packet or information not in the packet(environmental 
>>>> attributes
>> for
>>>> It is no different from a policy in this regard except that the 
>>>> policy now specifies the service path.
>>>> Further, classification is not limited to the network elements but 
>>>> the service functions as well. Some of this is described in the
>> architecture
>>>> drafts as well -
>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but 
>>>>> I had a similar question wrt bullet 11 in section 2 of the problem
>>>>> statement:
>>>>> 
>>>>>   of the packet header.  Concretely, it classifies packets based 
>>>>> on
>>>> the
>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>> Behalf
>> Of
>>>>>> Ron
>>>>>> Parker
>>>>>> As was discussed in Vancouver, there are already many existing 
>>>>>> ways
>>>> to
>>>>>> The service header is meant to carry the context which can *also* 
>>>>>> be derived (for example use source ip and vlan to identify 
>>>>>> chainID and
>>>>>> position) or encapsulated as part of another tunnel header. So 
>>>>>> this could be optional IMHO.
>>>>>> 
>>>>>> As I understand it, an SFC packet traversing from PDP to SF or 
>>>>>> from
>>>> SF
>>>>>> to
>>>>>> SF will look like:
>>>>>> 
>>>>>> the packet to be propagated along the full length of the chain, 
>> more
>>>>>> And where "transport" could conceivably be any of, but not 
>>>>>> limited
>>>> to:
>>>>>> 
>>>>>> * Ethernet
>>>>>> * Ethernet + LLC2
>>>>>> * Ethernet + MPLS
>>>>>> * Ethernet + IP + GRE
>>>>>> * Ethernet + IP +UDP
>>>>>> 
>>>>>> 
>>>>>> immutability, but rather to specify the packet that is propagated 
>>>>>> from preceding entity to succeeding entity, prior to 
>>>>>> encapsulation.
>>>>>> 
>>>>>>   Ron
>>>>>> 
>>>>>> 
>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>> Behalf
>> Of
>>>>>> Sumandra Majee
>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>> Behalf
>> Of
>>>>>> Thomas Narten
>>>>>> Networks, servers, storage technologies, and applications, have 
>>>>>> all undergone significant change in recent years with the 
>>>>>> introduction
>> of
>>>>>> Services are typically implemented by the ordered combination of 
>>>>>> a number of service functions that are deployed at different 
>>>>>> points within
>> the
>>>>>> physically inserted on the data forwarding path between 
>>>>>> communicating peers.
>>>> Going
>>>>>> functions and the order in which they are to be applied is called 
>>>>>> a Service Function Chain (SFC). Since a given service function 
>>>>>> may be available on more than one node within a network, a 
>>>>>> Service Function Chain is instantiated
>>>> via
>>>>>> the selection of specific service function instances and the 
>>>>>> network nodes on which they are provided, thereby forming a 
>>>>>> service topology:
>>>>>> this is called a Service Function Path. The service functions may 
>>>>>> be applied at a specific layer within the network protocol stack
>>>> (network
>>>>>> 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
>>>>>> group will also examine what information needs to be gathered 
>>>>>> from
>>>> the
>>>>>> how that information may be made available to nodes that 
>>>>>> implement
>>>> the
>>>>>> service functions.
>>>>>> 
>>>>>>    work should be carried out in the working groups responsible 
>>>>>> for
>>>> the
>>>>>> May 2014 Consult with OPS Area on possible charter modifications 
>>>>>> for management and configuration of SFC components
>>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 13:36:44 +0000

Hi Himanshu,

There are actually two things needed for this encapsulation stack to work:

1. Indication in the transport encapsulation that a service header is
present. There are several drafts that provide suggested solutions for
this.
2. An understanding of the size of the service header; draft-quinn-sfc-nsh
proposes a fixed length header.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 13:52:47 +0000

Hi Sumandra,

>Again the point here is that do we always need SFC header or Not.

Jim> we are perhaps getting a little ahead of ourselves as part of the
WG's job will be to define the SFC header and its applicability to service
chaining. As has been pointed out several times there are existing methods
for applying service chains and if those satisfy your requirements then
that¹s fine. Having said that, I believe there are many use cases being
presented that are either extremely difficult, if not impossible, to
realize using existing methods and that is why SFC was spawned to try and
address those.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 13:57:50 +0000

Hi Kevin,

Classification was not discussed in detail during the BOF.

Minutes were taken and will be posted soon (I am waiting on one of the
scribes to send their inputs before correlating into a single set of
minutes). 

On 11/11/13 10:57 PM, "Kevin J Ma" <[email-masked]> wrote:

>> > Ron Parker
>> > to SF will look like:
>> > that is
>> > can possibly be reused to provide
>> > that is

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 14:07:08 +0000

Hi Kevin,

Let me try and provide a concrete example to see if this answers your
specific question:

Use case: P-GW -> PCRF -> services applied to traffic based on
applicationID and subscriberID.

Instantiated as:

SFC1: P-GW -> DPI -> PCRF
SFC2: PCRF -> video-optimization -> metering -> FW
SFC3: PCRF -> parental-control -> metering -> FW

In this case DPI is performed on SFC1 and identifies applicationID. The
applicationID is carried in the service encapsulation to PCRF. PCRF uses
solution specific logic (identifies subscriber, applies policies, etc) and
uses the result along with the applicationID received from DPI to select
an outbound service chain, SFC2 or SFC3. Note that in this case branching
occurs from SFC1 to either SFC2 or SFC3.

On 11/12/13 1:52 AM, "Kevin J Ma" <[email-masked]> wrote:

>>points
>>policy
>> >>now
>>I
>> >> >> level (this is an implementation matter for the PDP).     All
>>flows
>> >> from
>>be
>> >> >> |                                         |  original IP payload
>>|
>> >> >>     a service function path realized at the network layer or at
>>any
>> >> >>other
>>all
>> >> >> one node within a network, a Service Function Chain is
>>instantiated
>> >>via
>>network
>> >> >>nodes
>>be
>> >> >> for service function chaining that includes the necessary
>>protocols
>> >>or
>> >> >>     a service function path realized at the network layer or at
>>any
>> >> >>other

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 14:08:13 +0000

Yes, completely agree Hongyu.

On 11/12/13 6:57 AM, "Hongyu Li (Julio)" <[email-masked]> wrote:

>Branching/forking is a very interesting topic of SFC. About the
>re-classification point, probably we shall not limit it to DPI. It is
>also possible that packets go to different branches after been processed
>by a certain service function, decision of which branches to go is made
>based on the result of service function's process, i.e. not just
>re-classification by DPI.
>
>Hongyu
>
>You ask a great question about branching the graph.  The details around
>how to convey the selection of the subtree/subgraph are still to be
>defined.   Is it one chain id for the whole graph?   Does each branch
>have its own chain id?   Some combination?
>
>   Ron
>
>>>>>>> any other
>>>>>>> any other

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 14:15:57 +0000

Hongyu, 

I agree completely that re-classification is not limited to DPI.

And also, that an area for us to explore as a group is how to represent the service graph.   Do we want to represent it as a proper graph with an adjacency list or other representational model?   Or, do we want to represent it as a set of linear segments and if so, how are the segments connected into a graph?   Other ideas?

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hongyu Li (Julio)
Sent: Tuesday, November 12, 2013 6:57 AM
To: Ron Parker; Kevin J Ma
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, November 12, 2013 7:45 PM
To: Kevin J Ma
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Hi, Kevin

   Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Nov 2013 09:40:54 -0500

Jim, thank you for a concrete example.
I would suggest that in the usual cases, there is a better way to handle 
this than branching and rewriting at the PCRF.

If the DPI engine or PCRF logic (whichever makes the decision) notifies 
the control logic about the decision for the flow, then the ingress can 
direct subsequent packets to the correct place, avoiding needless 
processing of further packets in the DPI and PCRF logic.
Further, the needed control information can be passed to the 
optimization or parental control so that it does not matter where the 
first packet is sent, avoiding the need for the PCRF to understand how 
to direct packets to service paths.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 14:52:51 +0000

Yes optimization can certainly be built into this but I wanted to show an
example of the types of things we mean when we talk about branching. Once
the concept is better understood I think we will see some more exciting
examples. Note also that the control logic could also utilize the service
encapsulation as a mechanism to push notifications back up the original
chain to inform the ingress to bypass the original chain for all
subsequent packets for this flow.

On 11/12/13 9:40 AM, "Joel M. Halpern" <[email-masked]> wrote:

>>>>>   on the level of classification being performed?  If the stated
>>>>>goals
>>>> are
>>>>>   other hand, the service function scope is limited due to
>>>>>limitations
>>>> in
>>>>described
>>>> in
>>>>>>>     address, destination address, DS field, protocol ID, source
>>>>>>>port
>>>>>> and
>>>>>>>>      being constructed. That is, the same encapsulation may be
>>>>>>>>used
>>>> on
>>>>>>>>      being constructed. That is, the same encapsulation may be
>>>>>>>>used
>>>> on

---

From: Jerome Moisand <[email-masked]>
Date: Tue, 12 Nov 2013 15:09:24 +0000

No clue what you guys are discussing. 

PCRF (when relevant for a given type of domain, e.g. mobile broadband) has a role to play in service chaining for sure, but... A PCRF is a control plane element, not a data plane element. It is not part of a service chain, it would control (part of) it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, November 12, 2013 9:41 AM
To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Sumandra Majee; Thomas Narten; [email-masked]
Subject: Re: [nsc] Current Proposed SFC charter

Jim, thank you for a concrete example.
I would suggest that in the usual cases, there is a better way to handle this than branching and rewriting at the PCRF.

If the DPI engine or PCRF logic (whichever makes the decision) notifies the control logic about the decision for the flow, then the ingress can direct subsequent packets to the correct place, avoiding needless processing of further packets in the DPI and PCRF logic.
Further, the needed control information can be passed to the optimization or parental control so that it does not matter where the first packet is sent, avoiding the need for the PCRF to understand how to direct packets to service paths.

Yours,
Joel

On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote:
> In this case DPI is performed on SFC1 and identifies applicationID. 
> The applicationID is carried in the service encapsulation to PCRF. 
> PCRF uses solution specific logic (identifies subscriber, applies 
> policies, etc) and uses the result along with the applicationID 
> received from DPI to select an outbound service chain, SFC2 or SFC3. 
> Note that in this case branching occurs from SFC1 to either SFC2 or SFC3.
>
>
>
>
>>       ID 11: NAT + firewall + DPI + optimizer + CACHE Would every 
>> flow then be initially classified as ID 1, but eventually get 
>> re-classified to ID 2-11, after the DPI phase?
>>
>> thanx.
>>
>> --  Kevin J. Ma
>>
>>>>   for firewall and load balancer functionality, then the 
>>>> application
>>> level
>>> described in the arch draft, the collection of services form a 
>>> graph, segments of which are service paths. Yes, reclassification 
>>> can change the service path and re-classification may happen at any 
>>> node along a service path.
>>>
>>> Surendra.
>>>>
>>>> thanx.
>>>>
>>>> --  Kevin J. Ma
>>>>
>>>>>>   had a similar question wrt bullet 11 in section 2 of the 
>>>>>> problem
>>>>>> statement:
>>>>>>
>>>>>>   A packet-based classifier as described in the framework 
>>>>>> document
>>>>> would
>>>>>>   identifier lookup does not seem to be a significant 
>>>>>> optimization
>>> over
>>>>>>> immutability, but rather to specify the packet that is 
>>>>>>> propagated from preceding entity to succeeding entity, prior to 
>>>>>>> encapsulation.
>>>>>>>
>>>>>>>     Ron
>>>>>>>
>>>>>>>
>>>>>>>      conveying the service function chain and the service 
>>>>>>> function
>>>>> path,
>>>>>>>              or an ability to select one encapsulation format 
>>>>>>> that
>>>>> fits
>>>>>>> the
>>>>>>>             The ability to select a specific encapsulation  
>>>>>>> would
>>> be
>>> a
>>>>>>> undergone significant change in recent years with the 
>>>>>>> introduction
>>> of
>>>>>>> forward, however, there is a desire to move to a different 
>>>>>>> model,
>>>>> where
>>>>>>> functions and the order in which they are to be applied is 
>>>>>>> called a Service Function Chain (SFC). Since a given service 
>>>>>>> function may be available on
>>> more
>>>>>>> than
>>>>>>> the necessary
>>>>>>> information to nodes that implement service functions, as well 
>>>>>>> as mechanisms for steering traffic through service functions. 
>>>>>>> The
>>>>> working
>>>>>>>      conveying the service function chain and the service 
>>>>>>> function
>>>>> path,
>>>>>>> 4) Control Plane Mechanisms: A set of documents will be 
>>>>>>> developed
>>> to

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Nov 2013 15:28:07 +0000

Maybe a better example for branching is at the DPI service function. Depending on the content, the flow can to go to video optimization function or web optimization function. 

Linda 

> Jim Guichard (jguichar)
> Sent: Tuesday, November 12, 2013 8:53 AM
> To: Joel M. Halpern; Kevin J Ma; Surendra Kumar (smkumar); Ron Parker;
> Sumandra Majee; Thomas Narten; [email-masked]
> >> solution specific logic (identifies subscriber, applies policies,
> etc)
> >>and
> >>>>>   Classification may be out of scope, but the level of service
> that
> >>>>>is
> >>>>>   applicable is dependent upon the level of classification that
> can
> >>>>>be
> >>>>>   of the service paths seem like re-classification points?  Is
> that
> >>>>>the
> >>>> the arch draft, the collection of services form a graph, segments
> of
> >>>> which
> >>>> are service paths. Yes, reclassification can change the service
> path
> >>>>and
> >>>>>>>     11.  Per-Service (re)Classification: Classification occurs
> at
> >>>> each
> >>>>>>>          These unrelated classification events consume
> resources
> >>>>>>>per
> >>>>>>>          often differs per service function and service
> function
> >>>> cannot
> >>>>>>>     The SFC Classifier classifies packets based on (some of)
> the
> >>>>>> contents
> >>>>>>>   a packet-based 5-tuple lookup?  There seems to be some
> missing
> >>>> detail
> >>>>>>>   flows, a packet-based classifier seems inadequate?  I was
> also
> >>>>>> wondering
> >>>>>>>> combination of interoperability, flexibility, and resiliency.
> A
> >>>>>> single
> >>>>>>>> service chain encapsulation will go a long way to ensuring
> these
> >>>>>> goals.
> >>>>>>>> It  may not be the absolutely most efficient approach for
> every
> >>>>>> single
> >>>>>>>> therefore,  does not identify the chain ID.    Another
> intention
> >>>> of
> >>>>>>>> derived (for example use source ip and vlan to identify
> chainID
> >>>> and
> >>>>>>>> |                                         |  original IP
> payload
> >>>>>>>> optionally, other metadata that enhances the operation of one
> or
> >>>> more
> >>>>>>>> service functions.
> >>>>>>>>
> >>>>>>>> but rather to specify the packet that is propagated from
> preceding
> >>>>>>>> entity
> >>>>>>>>            There are quite a few existing encapsulation
> methods
> >>>> that
> >>>>>> can
> >>>>>>>> of service functions that are deployed at different points
> within
> >>>> the
> >>>>>>>> inserted on the data forwarding path between communicating
> peers.
> >>>>>> Going
> >>>>>>>> and the order in which they are to be applied is called a
> Service
> >>>>>>>> Function
> >>>>>>>> Chain (SFC). Since a given service function may be available
> on
> >>>> more
> >>>>>>>> than
> as
> >>>>>>>>      may be done in this working group after agreement with
> all
> >>>>>>>>the

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Nov 2013 15:33:48 +0000

Ron, 

First, want to make it clear that "branching" != reclassification, agree?

Second, the representation of branching (or service graph) can be in a form of logic on a service function. Some service functions, especially L7 based, can use value in a Database to determine what is the next service function. 

Linda

> Sent: Tuesday, November 12, 2013 8:16 AM
> To: Hongyu Li (Julio); Kevin J Ma
> And also, that an area for us to explore as a group is how to represent
> the service graph.   Do we want to represent it as a proper graph with
> an adjacency list or other representational model?   Or, do we want to
> represent it as a set of linear segments and if so, how are the
> segments connected into a graph?   Other ideas?
> 
>    Ron
> 
> 
> Hongyu Li (Julio)
> Branching/forking is a very interesting topic of SFC. About the re-
> classification point, probably we shall not limit it to DPI. It is also
> possible that packets go to different branches after been processed by
> a certain service function, decision of which branches to go is made
> based on the result of service function's process, i.e. not just re-
> classification by DPI.
> 
> Hongyu
> 
> >>>>>> and optionally, other metadata that enhances the operation of
> one
> >>>>>> or
> >> more
> >>>>>> service functions.
> >>>>>>
> propagated
> called
> developed to

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 12 Nov 2013 15:46:11 +0000

Let me add for the record that this is the kind of management aspects I had in mind when we were talking about service metadata and how to exchange them...

Be goode,

--
"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: Kevin J Ma <[email-masked]>
Date: Tue, 12 Nov 2013 10:48:34 -0500

Hi Linda,

  Are you saying that a branching point is "never" a reclassification
  point, or are you saying that a branching point "does not have to be"
  a reclassification point?

  I think this is an important distinction that needs to be clarified.
  If branching is never reclassification, then the meaning of a chain
  is different than I originally inferred.  If the chain is a tree with
  other "branching" points in it, then that limits the scope of the
  problem statement goals.

  While this could be a degenerate case, and any implementation could
  define bad service chains, is it the intent of SFC to only look at
  the simpler packet-level classification cases, or is it the intent
  to consider the case where a branching point is viewed as a
  re-classification point?

thanx.

--  Kevin J. Ma

> From: Linda Dunbar [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2013 10:34 AM
> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma
> Second, the representation of branching (or service graph) can be in a
> form of logic on a service function. Some service functions, especially L7
> based, can use value in a Database to determine what is the next service
> function.
>
> Linda
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 12 Nov 2013 15:52:58 +0000

Hi,

> First, want to make it clear that "branching" != reclassification, agree?

DRL> At least, I do agree. Reclassification can lead to branching or not, depending on the paths available at the reclassifying node...

> Second, the representation of branching (or service graph) can be in a form of logic on a service function. Some service functions, especially L7 based, can use value in a Database to determine wha…

DRL> Anyway, a graph is what I see as the best concept, covering all possible cases I can think of. If reclassification or branching happens, we would be talking of different node types and/or labelled links between nodes. Once we agree in the graph as the conceptual model, I'd go for agreeing in the information model (the node and link attributes) and one or even several data models for it.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 15:53:44 +0000

I think the lack of definition of "reclassification" may be causing some misunderstandings here.    A branch would occur for some policy-driven reason based on the behavior and conclusions of the service function, itself.   The graph would represent the fact that there is a branch point, but the service function, itself, being aware that it is a branching point would contain the policy and logic to decide on which branch to take.   Specifying that policy and logic is out of scope, IMO.

   Ron

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 10:49 AM
To: Linda Dunbar; Ron Parker; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: RE: [nsc] Current Proposed SFC charter

Hi Linda,

thanx.

--  Kevin J. Ma

> form of logic on a service function. Some service functions, 
> especially L7 based, can use value in a Database to determine what is 
> the next service function.
>
> Linda
>
> > classification point, probably we shall not limit it to DPI. It is 
> > also possible that packets go to different branches after been 
> > processed by a certain service function, decision of which branches 
> > to go is made based on the result of service function's process, 
> > i.e. not just re- classification by DPI.
> >
> > Hongyu
> >
> > You ask a great question about branching the graph.  The details 
> > around how to convey the selection of the subtree/subgraph are still to be
> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" 
> > <[email-masked]>
> > wrote:
> >
> > > re-classified will get a new chain ID which fully describes a 
> > > chain that is a superset of the original chain ID, prior to 
> > > flow then be initially classified as ID 1, but eventually get re-
> > classified
> > >>> nature of those functions needs to be taken into account?  If, 
> > >>> on the other hand, the service function scope is limited due to 
> > >>> limitations in classification, that would be and important piece 
> > >>> of
> > information?
> > >>>
> > >>> points of the service paths seem like re-classification points?  
> > >>> Is that the interpretation from the architecture perspective?  
> > >>> Or is the service function chain classification exclusive of DPI
> > functionality?
> > change
> > >> the service path and re-classification may happen at any node 
> > >> along
> > a service path.
> > >>
> > >> Surendra.
> > >>>
> > >>> thanx.
> > >>>
> > >>> --  Kevin J. Ma
> > >>>
> > >>>> instance) or a combination thereof. What is important is that 
> > >>>> such classification aids in traffic selection and service path 
> > >>>> identification.
> > >>>> Further, classification is not limited to the network elements 
> > >>>> but the service functions as well. Some of this is described in 
> > >>>> the
> > >> architecture
> > >>>> drafts as well -
> > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, 
> > >>>>> but I had a similar question wrt bullet 11 in section 2 of the
> > problem
> > >>>>> statement:
> > >>>>>
> > >>>>>   of the packet header.  Concretely, it classifies packets 
> > >>>>> based on
> > >>>> the
> > >>>>> seem to be limited in what it can classify?  The service 
> > >>>>> function identifier lookup does not seem to be a significant 
> > >>>>> optimization
> > >> over
> > >>>>>> As was discussed in Vancouver, there are already many 
> > >>>>>> existing ways
> > >>>> to
> > >>>>>> network topology and every single use case, but its 
> > >>>>>> ubiquitous
> > >> nature
> > >>>>>> position) or encapsulated as part of another tunnel header. 
> > >>>>>> So this could be optional IMHO.
> > >>>>>>
> > >>>>>> As I understand it, an SFC packet traversing from PDP to SF 
> > >>>>>> or from
> > >>>> SF
> > >>>>>> to
> > >>>>>> SF will look like:
> > >>>>>>
> > >>>>>> | payload
> > >>>>>> the packet to be propagated along the full length of the 
> > >>>>>> chain, and optionally, other metadata that enhances the 
> > >>>>>> operation of
> > one
> > >>>>>> or
> > >> more
> > >>>>>> service functions.
> > >>>>>>
> > >>>>>> [SM] What does it mean by a single service-level 
> > >>>>>> encapsulation,
> > a
> > >>>> new
> > >>>>>> encapsulation format
> > >>>>>> would be
> > >>>>>> Networks, servers, storage technologies, and applications, 
> > >>>>>> have all undergone significant change in recent years with 
> > >>>>>> the introduction
> > >> of
> > >>>>>> Services are typically implemented by the ordered combination 
> > >>>>>> of a number of service functions that are deployed at 
> > >>>>>> different points within
> > >> the
> > >>>>>> network. Today, a common deployment model has service 
> > >>>>>> functions physically inserted on the data forwarding path 
> > >>>>>> between communicating peers.
> > >>>> Going
> > >>>>>> traffic is instead steered through services, wherever they 
> > >>>>>> are
> > >>>> deployed.
> > >>>>>>
> > >>>>>> For a given service, the abstracted view of the required 
> > >>>>>> service functions and the order in which they are to be 
> > >>>>>> applied is
> > called
> > >>>>>> a Service Function Chain (SFC). Since a given service 
> > >>>>>> function may be available on more than one node within a 
> > >>>>>> network, a Service Function Chain is instantiated
> > >>>> via
> > >>>>>> 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
> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A 
> > >>>>>> document
> > will
> > >>>>>>    work should be carried out in the working groups 
> > >>>>>> responsible for
> > >>>> the
> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining 
> > >>>>>> the
> > >>>> problem
> > >>>>>> May 2014 Consult with OPS Area on possible charter 
> > >>>>>> modifications for management and configuration of SFC 
> > >>>>>> components
> > >>>>>>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 12 Nov 2013 11:02:36 -0500

Hi Ron,

  In that case, it would seem to me that a lot of application layer flows
  would get thrown into the same bucket.  I'm thinking about HTTP/1.1+TLS
  (or worse yet, HTTP/2.0).  I am trying to figure out if these cases are
  really covered by SFC.  The problem statement and the use cases seem to
  imply that they are, but the classification implies that they are not?
  Are they only included by virtue of low level packet-based classification,
  and after that are only subject to "branching" points after demuxing,
  decryption, and DPI?  That is what is unclear to me.

thanx.

--  Kevin J. Ma

> Sent: Tuesday, November 12, 2013 10:54 AM
> To: Kevin J Ma; Linda Dunbar; Hongyu Li (Julio)
> I think the lack of definition of "reclassification" may be causing some
> misunderstandings here.    A branch would occur for some policy-driven
> reason based on the behavior and conclusions of the service function,
> itself.   The graph would represent the fact that there is a branch point,
> but the service function, itself, being aware that it is a branching point
> would contain the policy and logic to decide on which branch to take.
> Specifying that policy and logic is out of scope, IMO.
>
>    Ron
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Nov 2013 16:03:44 +0000

I just want to point out that branching and reclassification are two separate functions. Yes, sometimes, those two functions can be collocated on same device. But they don't have to be.

IMHO, "re-classification" should be associated with assigning a different  Chain-ID or mega data to a flow, whereas, "branching" is about one service function directing traffic to different service functions depending on some conditions. 

Linda

> Sent: Tuesday, November 12, 2013 9:49 AM

>   is different than I originally inferred.  

>If the chain is a tree with
> especially L7
> around
> chain
> paths
> > > >>> limitations in classification, that would be and important
> piece of
> > > information?
> > > >>>
> Is
> graph,
> such
> existing
> > > >>>>>> could be augmented with classification result, again one
> more
> > > >>>> example.
> > > >>>>>>
> > > >>>>>>>> All flows from the same source IP do not necessarily
> follow
> > > the
> > > >>>> same
> > > >>>>>> chain.
> > > >>>>>> Correct. It is also not necessary that all transaction of
> the
> > > >>>>>> same
> > > >>>> flow
> > > >>>>>> be limited to a single LAN.   Thus, while VLAN may be part
> of
> > > the
> > > >>>>>> Where service header contains, at a minimum, enough
> information
> > > >>>>>> to
> > > >>>> allow
> chain,
> have
> service
> > > >>>>>> this is called a Service Function Path. The service
> functions
> > > may
> develop
> > > >>>>>> 1) Problem Statement: This document will provide a summary
> of
> > > the
> responsible
> > > >>>>>> 5) Manageability: Work on the management and configuration
> of
> > > >> service
> modifications

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 16:22:07 +0000

Hi, Kevin.

There are no assumptions regarding the type and effectiveness of classification (stateful or otherwise).   SFC allows for the creation of a graph of service functions but does not dictate what those service functions are and how they operate.    

   Ron

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 11:03 AM
To: Ron Parker; Linda Dunbar; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: RE: [nsc] Current Proposed SFC charter

Hi Ron,

thanx.

--  Kevin J. Ma

> but the service function, itself, being aware that it is a branching 
> point would contain the policy and logic to decide on which branch to take.
> > Second, the representation of branching (or service graph) can be in 
> > a form of logic on a service function. Some service functions, 
> > especially L7 based, can use value in a Database to determine what 
> > is the next service function.
> >
> > Linda
> >
> > > re- classification point, probably we shall not limit it to DPI. 
> > > It is also possible that packets go to different branches after 
> > > been processed by a certain service function, decision of which 
> > > branches to go is made based on the result of service function's 
> > > process, i.e. not just re- classification by DPI.
> > >
> > > Hongyu
> > >
> > > around how to convey the selection of the subtree/subgraph are 
> > > still
> to be
> > > > Just to expand on that, going back to the original question 
> > > > about service header encapsulation, is it intended that a chain 
> > > > that is re-classified will get a new chain ID which fully 
> > > > describes a chain that is a superset of the original chain ID, 
> > > > prior to DPI-based re-classification?  (assuming the goal is "a 
> > > > single chain ID that is commonly understood along the entire service chain"
> > > > re-
> > > >>> on the other hand, the service function scope is limited due 
> > > >>> to limitations in classification, that would be and important 
> > > >>> piece of
> > > information?
> > > >>>
> > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the 
> > > >>> fork points of the service paths seem like re-classification points?
> > > >> graph, segments of which are service paths. Yes, 
> > > >> reclassification can
> > > change
> > > >>>> Classification mechanism is outside the scope of SFC. It can 
> > > >>>> be based
> > > >> on
> > > >>>> such classification aids in traffic selection and service 
> > > >>>> path identification.
> > > >>>> It is no different from a policy in this regard except that 
> > > >>>> the policy now specifies the service path.
> > > >>>> Further, classification is not limited to the network 
> > > >>>> elements but the service functions as well. Some of this is 
> > > >>>> described in the
> > > >> architecture
> > > >>>> drafts as well -
> > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" 
> > > >>>>> I was unable to make the SFC BoF due to a conflict with 
> > > >>>>> CDNI, but I had a similar question wrt bullet 11 in section 
> > > >>>>> 2 of the
> > > problem
> > > >>>>> statement:
> > > >>>>>
> > > >>>>> When thinking about higher level services, e.g., HTTP and 
> > > >>>>> TLS
> > > >>>> encrypted
> > > >>>>>> the same
> > > >>>>>> Again the point here is that do we always need SFC header 
> > > >>>>>> or
> Not.
> > > >>>>>>
> > > >>>>>> Sumandra
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> the fully qualified flow level, or even finer grained at 
> > > >>>>>> the
> > > >>>> transaction
> > > >>>>>> transport, it does not adequately identify the service 
> > > >>>>>> chain,
> > > >> either.
> > > >>>>>>
> > > >>>>>>   Ron
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> information to
> > > >>>>>> methods that
> > > >>>>>> virtualization, network overlays, and orchestration. 
> > > >>>>>> Service
> > > >> delivery
> > > >>>> is
> > > >>>>>> currently both a technical and organizational challenge 
> > > >>>>>> that
> > > >> involves
> > > >>>>>> Services are typically implemented by the ordered 
> > > >>>>>> combination of a number of service functions that are 
> > > >>>>>> deployed at different points within
> > > >> the
> > > >>>>>> the selection of specific service function instances and 
> > > >>>>>> the network nodes on which they are provided, thereby 
> > > >>>>>> forming a service topology:
> > > >>>>>> develop new approaches to service delivery and deployment. 
> > > >>>>>> It will produce a framework for service function chaining 
> > > >>>>>> that includes the necessary protocols
> > > >>>> or
> > > >>>>>> group will also examine what information needs to be 
> > > >>>>>> gathered from
> > > >>>> the
> > > >>>>>> network and service functions in support of service 
> > > >>>>>> function
> > > >> chaining
> > > >>>>>> and
> > > >>>>>>    problem space to be addressed by the WG including 
> > > >>>>>> example
> > > high-
> > > >>>>>> 2) Architecture: This document will provide a description 
> > > >>>>>> of
> the
> > > >>>>>>    diagnostics, design analysis, and security models, as 
> > > >>>>>> well
> as
> > > >>>>>>    to service function implementation points. Where 
> > > >>>>>> possible,
> > > >>>> existing

---

From: Ron Parker <[email-masked]>
Date: Tue, 12 Nov 2013 16:28:51 +0000

Linda,

In general, I agree that the service function and reclassification are distinct.   I could conceive of a chain that has a service function F1 followed by a classifier C that branches to service functions F2 and F3.   Let's assume that C is placed in the chain because F1 will come to some useful conclusion regarding the flow or transaction.    In this case, metadata would need to be transferred from F1 to C in the SFC service header.   Also, that metadata would have to be standardized in some way that F1 and C agree  (i.e., defined by SFC).    There are possibly some common use cases that lend themselves to this type of approach.

If, on the other hand, F1 and C are integrated, then the metadata handoff is private and need not be specified by SFC.   This approach allows for faster innovation by service function developers since there is no need to standardize the metadata (or perhaps we revert to vendor-specific metadata which has its own set of problems).

I think both scenarios are valid.

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, November 12, 2013 11:04 AM
To: Kevin J Ma; Ron Parker; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Linda

> > > It is
> > > possible that packets go to different branches after been 
> > > processed
> by
> > > > describes a
> > > > re-classification?  (assuming the goal is "a single chain ID 
> > > > that
> is
> fork
> > > >>>> elements
> > > >>>>> CDNI,
> combination of
> > > >>>>>> a number of service functions that are deployed at 
> > > >>>>>> different points within
> > > >> the
> gathered
> well as

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 16:43:57 +0000

Linda,
Could you explain in detail why you believe branching and reclassification
are two different things as to me they are one of the same?

On 11/12/13 11:03 AM, "Linda Dunbar" <[email-masked]> wrote:

>
>
>I just want to point out that branching and reclassification are two
>separate functions. Yes, sometimes, those two functions can be collocated
>on same device. But they don't have to be.
>
>IMHO, "re-classification" should be associated with assigning a different
> Chain-ID or mega data to a flow, whereas, "branching" is about one
>service function directing traffic to different service functions
>depending on some conditions.
>
>Linda
> 
>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 12 Nov 2013 11:46:58 -0500

Hi Jim,

  In the example you have below, does the PCRF have to be concerned
  about reverse-mapping on the return path?  Or would the return path
  be handled independently, classifying to a different set of chains?

  In the example below, branching does equate to re-classification?

thanx.

--  Kevin J. Ma

> From: Jim Guichard (jguichar) [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2013 9:07 AM
> To: Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Sumandra Majee;
> Thomas Narten; [email-masked]

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:02:33 +0000

Hi Kevin,

It is implementation specific. For instance PCRF can be stateful and hence
does not have to reclassify on the return path. However, as an
architecture we should not prevent a different chain to be applied in the
reverse path for those exceptional use cases. The example I used does
indeed equate to a re-classification at the branching point as traffic is
forwarded into a *new* chain.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:02:55 +0000

Jerome,

It is at a high level and not a specific implementation. I'm sure there
are many of achieving what Jim said.

Surendra. 

On 11/12/13 7:09 AM, "Jerome Moisand" <[email-masked]> wrote:

>PCRF (when relevant for a given type of domain, e.g. mobile broadband)
>has a role to play in service chaining for sure, but... A PCRF is a
>control plane element, not a data plane element. It is not part of a
>service chain, it would control (part of) it.
>
>Joel M. Halpern
>To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron
>Parker; Sumandra Majee; Thomas Narten; [email-masked]
>Further, the needed control information can be passed to the optimization
>or parental control so that it does not matter where the first packet is
>sent, avoiding the need for the PCRF to understand how to direct packets
>to service paths.
>
>Yours,
>Joel
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:09:25 +0000

>First, want to make it clear that "branching" != reclassification, agree?
<SK> branching is a result of reclassification.

>form of logic on a service function. Some service functions, especially
>L7 based, can use value in a Database to determine what is the next
>service function.
<SK> that is reclassification, no matter how you do it. Your
classification may be as simple as "all traffic coming in service path x
-> service path-y".

Surendra.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:20:25 +0000

Diego,

On 11/12/13 7:52 AM, "Diego R. Lopez" <[email-masked]> wrote:

>DRL> At least, I do agree. Reclassification can lead to branching or not,
>depending on the paths available at the reclassifying node...
<SK> You are right about branching or not: branching is a consequence of
reclassification. In theory, reclassification is not required to lead to
branching. Further, there could be reclassification within the SF that
does not impact the service path, only the service function.

Surendra.

>DRL> Anyway, a graph is what I see as the best concept, covering all
>possible cases I can think of. If reclassification or branching happens,
>we would be talking of different node types and/or labelled links between
>nodes. Once we agree in the graph as the conceptual model, I'd go for
>agreeing in the information model (the node and link attributes) and one
>or even several data models for it.
>
>Be goode,
>
>--
>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:

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:25:39 +0000

Ron,

Classification of traffic is well understood and we do not have to
redefine it - it's been around for all the time middle boxes have been or
for that matter the L2/L3 devices. All we are talking about is the
applicability of the classification to branching in SFC.

You are right, it is all about policy which is outside the scope of SFC.

Surendra.

On 11/12/13 7:53 AM, "Ron Parker" <[email-masked]> wrote:

>itself.   The graph would represent the fact that there is a branch
>point, but the service function, itself, being aware that it is a
>branching point would contain the policy and logic to decide on which
>branch to take.   Specifying that policy and logic is out of scope, IMO.
>
>   Ron
>
>

---

From: "David Lake (dlake)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:59:45 +0000

Policy may be outside of the scope of SFC, but without strong mapping between Policy and the inserted Service Header(s), we run-the-risk of limiting the efficacy of the protocol IMO.

For example, in a world where the network has "gone dark," (as per the IETF Technical Plenary ?:-) ) what is our ability to determine policy based on DPI of packets-in-flight ?

In those circumstances, only the end applications themselves or a reasonably broad-brushed classification (really traffic steering based on what we can see at ingress) is going to be useful - is THAT what we're aiming for here ?

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: 12 November 2013 09:26
To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Ron,

Classification of traffic is well understood and we do not have to redefine it - it's been around for all the time middle boxes have been or for that matter the L2/L3 devices. All we are talking about is the applicability of the classification to branching in SFC.

Surendra.

On 11/12/13 7:53 AM, "Ron Parker" <[email-masked]> wrote:

> the simpler packet-level classification cases, or is it the intent  to 
> consider the case where a branching point is viewed as a  
> re-classification point?
>
>thanx.
>
>--  Kevin J. Ma
>
>> > >>>> but the service functions as well. Some of this is described 
>> > >>>> in the
>> > >> architecture
>> > >>>> drafts as well -

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 12 Nov 2013 13:16:09 -0500

> for that matter the L2/L3 devices.

Hi Surrendra,

  An overly large focus on L2/L3 is a red flag for me.
  Can we assume your statement was just an exercise in hyperbole?

  The services being discussed are L5-7 services and
  it's not clear that L2/L3/L4 classification is sufficient
  to define chains for some of these application layer services?

thanx.

--  Kevin J. Ma

> Sent: Tuesday, November 12, 2013 12:26 PM

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:22:07 +0000

I was just commenting on the classification definition.

Surendra.

On 11/12/13 10:16 AM, "Kevin J Ma" <[email-masked]> wrote:

>>piece
>>reclassification
>>combination
>>It

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 12 Nov 2013 13:27:24 -0500

> In those circumstances, only the end applications themselves or a
> reasonably broad-brushed classification (really traffic steering based on
> what we can see at ingress) is going to be useful - is THAT what we're
> aiming for here ?

I would certainly hope not, but that has been my concern as well.
Application layer termination and re-classification seems a must?

--  Kevin J. Ma

> From: David Lake (dlake) [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2013 1:00 PM
> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu
> Li (Julio)
> Policy may be outside of the scope of SFC, but without strong mapping
> between Policy and the inserted Service Header(s), we run-the-risk of
> limiting the efficacy of the protocol IMO.
>
> For example, in a world where the network has "gone dark," (as per the
> IETF Technical Plenary ?:-) ) what is our ability to determine policy
> based on DPI of packets-in-flight ?
>
> In those circumstances, only the end applications themselves or a
> reasonably broad-brushed classification (really traffic steering based on
> what we can see at ingress) is going to be useful - is THAT what we're
> aiming for here ?
>
> David
>
> Surendra Kumar (smkumar)

---

From: "David Lake (dlake)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:36:30 +0000

Exactly.  But how can network-components "terminate" an application ????

I think we need a good understanding of a recursive policy mechanism (recursive because a user-land application will ride with a specific policy across potentially different sets of carrier policies).

I hate to bring this up now, but we also need to think about this multi-domain issue - if I set a policy as a user, chances are I will be crossing several domain boundaries.  Are we expecting the service headers to define the service chaining for the duration of the entire flow across all domains, or just across a single one ?

In which case, do I have to re-set policy as I traverse domains  and where does that policy get set ?   It would be much better to set policy once based on L5-7 needs, and have that instantiated across the multiple domains.

Again, this appears to be outside the scope of SFC, but pretty relevant to how it would operate in the real world.

David

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: 12 November 2013 10:27
To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Sumandra Majee
Subject: RE: [nsc] Current Proposed SFC charter

> reasonably broad-brushed classification (really traffic steering based 
> on what we can see at ingress) is going to be useful - is THAT what 
> we're aiming for here ?

--  Kevin J. Ma

> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; 
> Hongyu Li (Julio)
> reasonably broad-brushed classification (really traffic steering based 
> on what we can see at ingress) is going to be useful - is THAT what 
> we're aiming for here ?
>
> David
>
> redefine it - it's been around for all the time middle boxes have been 
> or for that matter the L2/L3 devices. All we are talking about is the 
> > is different than I originally inferred.  If the chain is a tree 
> > with other "branching" points in it, then that limits the scope of 
> > the problem statement goals.
> >
> >> Second, the representation of branching (or service graph) can be 
> >> in a form of logic on a service function. Some service functions, 
> >> > Behalf Of Ron Parker
> >> > Behalf Of Hongyu Li (Julio)
> >> > Behalf Of Ron Parker
> >> > > single chain ID that is commonly understood along the entire 
> >> > > service
> chain"
> >> > >      ID 11: NAT + firewall + DPI + optimizer + CACHE Would 
> >> > > every flow then be initially classified as ID 1, but eventually 
> >> > > get re-
> >> > classified
> >> > >>> nature of those functions needs to be taken into account?  
> >> > >>> If, on the other hand, the service function scope is limited 
> >> > >>> due to limitations in classification, that would be and 
> >> > >>> important piece of
> >> > information?
> >> > >>>
> >> > >>>> instance) or a combination thereof. What is important is 
> >> > >>>> that such classification aids in traffic selection and 
> >> > >>>> service path identification.
> >> > >>>>>   11.  Per-Service (re)Classification: Classification 
> >> > >>>>> occurs at
> >> > each
> >> > >>>>>   possible combination of one or more header fields, such 
> >> > >>>>> as
> >> > source
> >> > >>>>> function identifier lookup does not seem to be a 
> >> > >>>>> significant optimization
> >> > >> over
> >> > >>>>> how independent HLS segment requests might be classified 
> >> > >>>>> and
> >> > >>>> associated?
> >> > >>>>>> From: [email-masked] [mailto:[email-masked]] 
> >> > >>>>>> On Behalf
> >> > >> Of
> >> > >>>>>> Ron
> >> > >>>>>> Parker
> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to 
> >> > >>>>>> SF or from
> >> > >>>> SF
> >> > >>>>>> to
> >> > >>>>>> SF will look like:
> >> > >>>>>>
> >> > >>>>>> Also, "original" in the diagram above is not meant to 
> >> > >>>>>> imply immutability, but rather to specify the packet that 
> >> > >>>>>> is
> >> > propagated
> >> > >>>>>> From: [email-masked] [mailto:[email-masked]] 
> >> > >>>>>> On Behalf
> >> > >> Of
> >> > >>>>>> Sumandra Majee
> >> > >>>>>> Generic Service Function Chaining Encapsulation: A 
> >> > >>>>>> document
> >>will
> >> > >>>>>>            or an ability to select one encapsulation 
> >> > >>>>>> format that
> >> > >>>> fits
> >> > >>>>>> the
> >> > >>>>>> From: [email-masked] [mailto:[email-masked]] 
> >> > >>>>>> On Behalf
> >> > >> Of
> >> > >>>>>> Thomas Narten
> >> > >>>>>> path information to nodes that implement service 
> >> > >>>>>> functions, as well
> >> > as
> >> > >>>>>>    functions in support of SFC components will certainly 
> >> > >>>>>> be
> >> > needed,

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:44:29 +0000

As discussed during the BOF our initial work is single administrative
domain for some of the very reasons you point out. We need to keep focused
without trying to boil the ocean right off the bat.

On 11/12/13 1:36 PM, "David Lake (dlake)" <[email-masked]> wrote:

>I think we need a good understanding of a recursive policy mechanism
>(recursive because a user-land application will ride with a specific
>policy across potentially different sets of carrier policies).
>
>I hate to bring this up now, but we also need to think about this
>multi-domain issue - if I set a policy as a user, chances are I will be
>crossing several domain boundaries.  Are we expecting the service headers
>to define the service chaining for the duration of the entire flow across
>all domains, or just across a single one ?
>
>In which case, do I have to re-set policy as I traverse domains  and
>where does that policy get set ?   It would be much better to set policy
>once based on L5-7 needs, and have that instantiated across the multiple
>domains.
>
>Again, this appears to be outside the scope of SFC, but pretty relevant
>to how it would operate in the real world.
>
>David
>

---

From: "David Lake (dlake)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:51:03 +0000

Understood - maybe just a little localised warming of the sea then ?   But I still think we need to consider where and how policy is defined/set even for the single-domain instance.

I don't think we can assume that any L1-3 device will be able to determine much useful information from the data-plane.

-----Original Message-----
From: Jim Guichard (jguichar) 
Sent: 12 November 2013 10:44
To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

As discussed during the BOF our initial work is single administrative domain for some of the very reasons you point out. We need to keep focused without trying to boil the ocean right off the bat.

On 11/12/13 1:36 PM, "David Lake (dlake)" <[email-masked]> wrote:

>crossing several domain boundaries.  Are we expecting the service 
>headers to define the service chaining for the duration of the entire 
>flow across all domains, or just across a single one ?
>
>once based on L5-7 needs, and have that instantiated across the 
>multiple domains.
>
>> reasonably broad-brushed classification (really traffic steering 
>> based on what we can see at ingress) is going to be useful - is THAT 
>> what we're aiming for here ?
>
>> For example, in a world where the network has "gone dark," (as per 
>> the IETF Technical Plenary ?:-) ) what is our ability to determine 
>> policy based on DPI of packets-in-flight ?
>>
>> reasonably broad-brushed classification (really traffic steering 
>> based on what we can see at ingress) is going to be useful - is THAT 
>> what we're aiming for here ?
>>
>> David
>>
>> redefine it - it's been around for all the time middle boxes have 
>> been or for that matter the L2/L3 devices. All we are talking about 
>> is the applicability of the classification to branching in SFC.
>>
>> >  Are you saying that a branching point is "never" a 
>> > reclassification point, or are you saying that a branching point "does not have to be"
>> >  If branching is never reclassification, then the meaning of a 
>> > chain is different than I originally inferred.  If the chain is a 
>> > tree with other "branching" points in it, then that limits the 
>> > scope of the problem statement goals.
>> >
>> >  While this could be a degenerate case, and any implementation 
>> > could define bad service chains, is it the intent of SFC to only 
>> > look at the simpler packet-level classification cases, or is it the 
>> > intent to consider the case where a branching point is viewed as a 
>> > re-classification point?
>> >
>> >thanx.
>> >
>> >--  Kevin J. Ma
>> >
>> >> > > about service header encapsulation, is it intended that a 
>> >> > > chain that is re-classified will get a new chain ID which 
>> >> > > fully describes a chain that is a superset of the original 
>> >> > > chain ID, prior to DPI-based re-classification?  (assuming the 
>> >> > > goal is "a single chain ID that is commonly understood along 
>> >> > > the entire service
>> chain"
>> >> > > every flow then be initially classified as ID 1, but 
>> >> > > eventually get re-
>> >> > classified
>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" 
>> >> > >>> applicable is dependent upon the level of classification 
>> >> > >>> that can
>> >> > be
>> >> > >> described in the arch draft, the collection of services form 
>> >> > >> a graph, segments of which are service paths. Yes, 
>> >> > >> reclassification can
>> >> > change
>> >> > >>>> Classification mechanism is outside the scope of SFC. It 
>> >> > >>>> can be based
>> >> > >> on
>> >> > >>>>>        service, independent from previously applied 
>> >> > >>>>> service
>> >> > >>>> functions.
>> >> > >>>>>> service chain encapsulation will go a long way to 
>> >> > >>>>>> ensuring these
>> >> > >>>> goals.
>> >> > >>>>>> The service header is meant to carry the context which 
>> >> > >>>>>> can
>> >> > *also*
>> >> > >>>>>> be derived (for example use source ip and vlan to 
>> >> > >>>>>> identify chainID and
>> >> > >>>>>> And where "transport" could conceivably be any of, but 
>> >> > >>>>>> not limited
>> >> > >>>> to:
>> >> > >>>>>>
>> >> > >>>>>> * Ethernet
>> >> > >>>>>> * Ethernet + LLC2
>> >> > >>>>>> * Ethernet + MPLS
>> >> > >>>>>> * Ethernet + IP + GRE
>> >> > >>>>>> * Ethernet + IP +UDP
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>    and for communicating context information between 
>> >> > >>>>>> nodes
>> that
>> >> > >>>>>> It contains the revised management text as well as 
>> >> > >>>>>> updated
>> >> > >>>> milestones.
>> >> > >>>>>>
>> >> > >>>>>> Networks, servers, storage technologies, and 
>> >> > >>>>>> applications, have all undergone significant change in 
>> >> > >>>>>> recent years with the introduction
>> >> > >> of
>> >> > >>>>>> forward, however, there is a desire to move to a 
>> >> > >>>>>> different model,
>> >> > >>>> where
>> >> > >>>>>> traffic is instead steered through services, wherever 
>> >> > >>>>>> they are
>> >> > >>>> deployed.
>> >> > >>>>>>
>> >> > >>>>>> protocol extensions to convey the service path and 
>> >> > >>>>>> service path information to nodes that implement service 
>> >> > >>>>>> functions, as well
>> >> > as
>> >> > >>>>>> 1) Problem Statement: This document will provide a 
>> >> > >>>>>> summary of
>> >> > the
>> >> > >>>>>>    and for communicating context information between 
>> >> > >>>>>> nodes
>> that
>> >> > >>>>>>    describe requirements and protocols necessary to 
>> >> > >>>>>> convey
>> >> > >>>> information
>> >> > >>>>>> 5) Manageability: Work on the management and 
>> >> > >>>>>> configuration of
>> >> > >> service
>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) 
>> >> > >>>>>> defining the
>> >> > >>>> problem
>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic 
>> >> > >>>>>> service function chaining encapsulation protocol
>> >> > >>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 19:00:54 +0000

The assumption is that classification may be performed at the network
and/or application layer and that classification will be based on policy
of some description. When we work through control plane aspects of the SFC
charter presumably what policy needs to be generated and by what to where
is part of the work item. Further, branching will occur because of a
reclassification but reclassification may or may not force a branch from
one chain to another.

On 11/12/13 1:51 PM, "David Lake (dlake)" <[email-masked]> wrote:

>Understood - maybe just a little localised warming of the sea then ?
>But I still think we need to consider where and how policy is defined/set
>even for the single-domain instance.
>
>I don't think we can assume that any L1-3 device will be able to
>determine much useful information from the data-plane.
>
>domain for some of the very reasons you point out. We need to keep
>focused without trying to boil the ocean right off the bat.
>
>>> >> > an adjacency list or other representational model?   Or, do we
>>>want
>>> to
>>> >> > >>>>>>          context information between   service nodes. I
>>>have
>>> >> > seen
>>> >> > >>>>>> mention
>>> >> > >>>>>> of GRE, for HTTP based

---

From: "Pham, Chuong D" <[email-masked]>
Date: Wed, 13 Nov 2013 10:15:05 +1100

Hi all,

In the example below, PCRF is a control plane element. It is not in the path of user plane traffic (traversing the service functions). I am not sure if the example is valid. However, if the example is meant to say in SFC1, the DPI informs the PCRF of the ApplicationID (aka via Sd interface of the "TDF") so that the PCRF then informs the ingress node (a PCEF) to start steering traffic to SFC2 or SFC3 instead SFC1 then it is valid. In this case, the DPI acts as an intelligence node supplying information to the PCRF so that the PCRF can make a decision on which service chain will be used for a subscriber's flow.

The issue here is once the traffic is no longer passing the DPI (SFC1 is no longer used), no further decision based on DPI can be made.
Another issue is by the time the DPI "understands" the ApplicationID and inform the PCRF, the user has already established TCP (and perhaps application layer) connection with the server. SCF2 and SFC3 will then be a case of steering mid-flow which will break TCP and application layer sessions.

Also, I could consider SFC1 is a case of pre-steering mediation (to decide whether SFC2 or SFC3 is to be used) rather than a case of reclassification and branching.

My example of a reclassification and branching would be a case where an DDoS inspection node diverts a flow to a DDoS clearing node once DDoS attacks have been detected.

Regards,
Chuong

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, 13 November 2013 1:41 AM
To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Sumandra Majee; Thomas Narten; [email-masked]
Subject: Re: [nsc] Current Proposed SFC charter

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 12 Nov 2013 23:36:13 +0000

Yes, the example was not meant to be an exhaustive technical
representation; rather than saying "something" can detect "something" and
tell "someone" to send traffic to chain "a" or "b" I thought a high level
example might be more helpful.

On 11/12/13 6:15 PM, "Pham, Chuong D" <[email-masked]>
wrote:

>Hi all,
>
>In the example below, PCRF is a control plane element. It is not in the
>path of user plane traffic (traversing the service functions). I am not
>sure if the example is valid. However, if the example is meant to say in
>SFC1, the DPI informs the PCRF of the ApplicationID (aka via Sd interface
>of the "TDF") so that the PCRF then informs the ingress node (a PCEF) to
>start steering traffic to SFC2 or SFC3 instead SFC1 then it is valid. In
>this case, the DPI acts as an intelligence node supplying information to
>the PCRF so that the PCRF can make a decision on which service chain will
>be used for a subscriber's flow.
>
>The issue here is once the traffic is no longer passing the DPI (SFC1 is
>no longer used), no further decision based on DPI can be made.
>Another issue is by the time the DPI "understands" the ApplicationID and
>inform the PCRF, the user has already established TCP (and perhaps
>application layer) connection with the server. SCF2 and SFC3 will then be
>a case of steering mid-flow which will break TCP and application layer
>sessions.
>
>Also, I could consider SFC1 is a case of pre-steering mediation (to
>decide whether SFC2 or SFC3 is to be used) rather than a case of
>reclassification and branching.
>
>My example of a reclassification and branching would be a case where an
>DDoS inspection node diverts a flow to a DDoS clearing node once DDoS
>attacks have been detected.
>
>Regards,
>Chuong
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 Nov 2013 01:19:34 +0000

Jerome is right, the actual data path do not go through the PCRF. PCRF is responsible for giving policies to the P-GW. 
The example given by Jim showing that PCRF is one of the service functions, is confusing. 

Linda

> Jerome Moisand
> Sent: Tuesday, November 12, 2013 9:09 AM
> To: Joel M. Halpern; Jim Guichard (jguichar); Kevin J Ma; Surendra
> Kumar (smkumar); Ron Parker; Sumandra Majee; Thomas Narten;
> [email-masked]
> I would suggest that in the usual cases, there is a better way to
> handle this than branching and rewriting at the PCRF.
> 
> can be
> on the
> that the

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 13 Nov 2013 09:28:19 +0000

Ron,

I agree with Jim's example in another email that SFC1 is stitched to SFC2 and SFC3. Using different chain for branches is easier for protocol. The provisioning is complex for a branching case anyway.

Hongyu

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 10:16 PM
To: Hongyu Li (Julio); Kevin J Ma
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: RE: [nsc] Current Proposed SFC charter

Hongyu, 

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hongyu Li (Julio)
Sent: Tuesday, November 12, 2013 6:57 AM
To: Ron Parker; Kevin J Ma
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, November 12, 2013 7:45 PM
To: Kevin J Ma
Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Hi, Kevin

   Ron

---

From: Dave Dolson <[email-masked]>
Date: Tue, 12 Nov 2013 19:48:09 +0000

I think there is great simplicity to be had by limiting the path selection to the ingress node (i.e., the one who first puts the SFC header on).

I believe this because of the requirement of many layer4-7 devices to see symmetric paths. (e.g., {DPI2, NAT7, ContentControl11} on the way out and {ContentControll11, NAT7, DPI2} on the way back)

I think it will be really hard to manage this if each device in the chain can select an arbitrary (policy-selected) next-hop. I think each packet's next hop and ID needs to determined by the received ID.

Otherwise, I'm curious how others see the symmetric path problem being managed?

(Apologies if I'm mangling the terminology)

David Dolson
Software Architect, Sandvine Inc.

---

From: Dave Dolson <[email-masked]>
Date: Tue, 12 Nov 2013 19:53:25 +0000

It might be helpful to associate each chain ID at a particular node with a "realm" of some sort.
Then the receiving node can map the ID to a realm and provide appropriate behaviour.

This could at least assist with different domains of overlapping private IPv4, which can occur within the same operator.

If you don't have need of different realms, just use the default for all of your IDs.

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 13 Nov 2013 05:36:07 +0000

[SM] I would tend to agree that initial path selection should begin at ingress. However an application classification is a continuous process. It could take a few packets on the response side to classify if this is a video, the type, coded rate and tie this with device screen size which could then select a proper video optimizer. Such device would also hold on to the response as opposed streaming, to make this content available to the optimizer. It could use the HTTP redirect method but that does waste RAN bandwidth. Minor implementation detail not really important for WG

I think there is a general confusion or may be it is mine only,
  a) What are the classification point and by classification I don't mean DPI and signatures. It could be dst port or dst_ip address. Say a service is aware of IP pools used by a popular music streaming service and it could then add this extra classification result. This could be encap modification or could trigger a new tunnel to some other service endpoint. 

 b) Is SFC inline network element? The question around Sd interface to PCRF suggests that it is. However there would be less control over data when it is out of band, that is simply the unfortunate truth about network real estate.

 c) Chain. How do we create these chain, graphs that are pre created. I can argue that with increasing number of nodes that will be messy. Another option is to create a few useful chains and allow nodes to branch off to a different node forward or JMP to a new chainID. This could limit the number of configs object. This also implies that policy is distributed around ... what?

Regards.

Sumandra

________________________________________
From: Dave Dolson [[email-masked]]
Sent: Tuesday, November 12, 2013 11:48 AM
To: Jim Guichard (jguichar); David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Sumandra Majee
Subject: RE: [nsc] Current Proposed SFC charter

David Dolson

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 17 Nov 2013 14:07:20 +0000

Dear SFC Chairs, All,

AFAIK the management of SFC or service graphs in general needs to address:

- the orchestration of a service graph based on the information in a model used as input,
- lifecycle management of network services and possibly of single VNFs,
- FCAPS as well as management of virtualization related events (e.g. monitoring and correlation of virtualization events)
- specification of relevant information models and the standardization of necessary data models.

AFAIU it is not easy to address all of these management aspects in the future SFC WG and a parallel work in OPS area might be useful if started early.

Please elaborate and argue otherwise.

Cheers, 
Mehmet 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Diego R.
> Lopez
> Sent: Tuesday, November 12, 2013 4:46 PM
> To: Jim Guichard (jguichar)
> Cc: Thomas Narten; [email-masked]; Sumandra Majee; Kevin J Ma; Ron Parker; Joel M.
> Halpern; Surendra Kumar (smkumar)
> Let me add for the record that this is the kind of management aspects I had in mind
> when we were talking about service metadata and how to exchange them...
> 
> Be goode,
> 
> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 17 Nov 2013 09:27:34 -0500

You list a number of very useful items that are needed for the full 
utilization of service chaining in a network.

That does not mean that all those items should be in scope for this 
working group.  As far as I can tell, our goal is to make a useful 
contribution to solving the problem, rather than to attempt to 
simultaneously address all known or expected issues.

The remaining topics may be dealt with in other working groups, in other 
fora, or by vendors and operators individually.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Sun, 17 Nov 2013 15:27:19 +0000

> - the orchestration of a service graph based on the information in a 
Ron>> with the caveat that "orchestration" is a broadly used term and will ultimately require more specificity. 

> - specification of relevant information models and the standardization of necessary data models.
Ron>> There is an expectation that YANG or other data models will be published.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Sunday, November 17, 2013 9:28 AM
To: Ersue, Mehmet (NSN - DE/Munich); Jim Guichard (jguichar); Thomas Narten
Cc: [email-masked]; ext Benoit Claise; ext Diego R. Lopez; [email-masked]; ext Melinda Shore
Subject: Re: [nsc] Current Proposed SFC charter

You list a number of very useful items that are needed for the full utilization of service chaining in a network.

That does not mean that all those items should be in scope for this working group.  As far as I can tell, our goal is to make a useful contribution to solving the problem, rather than to attempt to simultaneously address all known or expected issues.

The remaining topics may be dealt with in other working groups, in other fora, or by vendors and operators individually.

Yours,
Joel

On 11/17/13 9:07 AM, Ersue, Mehmet (NSN - DE/Munich) wrote:
> - FCAPS as well as management of virtualization related events (e.g. 
> monitoring and correlation of virtualization events)
>> Let me add for the record that this is the kind of management aspects 
>> I had in mind when we were talking about service metadata and how to exchange them...
>>
>> Be goode,
>>
>>> Yes optimization can certainly be built into this but I wanted to 
>>> show an example of the types of things we mean when we talk about 
>>> branching. Once the concept is better understood I think we will see 
>>> some more exciting examples. Note also that the control logic could 
>>> also utilize the service encapsulation as a mechanism to push 
>>> notifications back up the original chain to inform the ingress to 
>>> bypass the original chain for all subsequent packets for this flow.
>>>
>>>> If the DPI engine or PCRF logic (whichever makes the decision) 
>>>> notifies the control logic about the decision for the flow, then 
>>>> the ingress can direct subsequent packets to the correct place, 
>>>> avoiding needless processing of further packets in the DPI and PCRF logic.
>>>> optimization or parental control so that it does not matter where 
>>>> the first packet is sent, avoiding the need for the PCRF to 
>>>> understand how to direct packets to service paths.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>>> Let me try and provide a concrete example to see if this answers 
>>>>> your specific question:
>>>>>
>>>>> In this case DPI is performed on SFC1 and identifies 
>>>>> applicationID. The applicationID is carried in the service 
>>>>> encapsulation to PCRF. PCRF uses solution specific logic 
>>>>> (identifies subscriber, applies policies, etc) and uses the result 
>>>>> along with the applicationID received from DPI to select an 
>>>>> outbound service chain, SFC2 or SFC3. Note that in this case 
>>>>> branching occurs from SFC1 to either SFC2 or SFC3.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>   on the level of classification being performed?  If the 
>>>>>>>> stated goals
>>>>>>> are
>>>>>>>> If, on the
>>>>>>> reclassification can change the service path and 
>>>>>>>>>> CDNI, but
>>>>>>>>>> resources per
>>>>>>>>>>     address, destination address, DS field, protocol ID, 
>>>>>>>>>> source port
>>>>>>>>> and
>>>>>>>>>>>>> follow the
>>>>>>>>>>> So
>>>>>>>>>>> optionally, other metadata that enhances the operation of 
>>>>>>>>>>> one or
>>>>>>> more
>>>>>>>>>>> service functions.
>>>>>>>>>>>
>>>>>>>>>>> propagated from preceding entity to succeeding entity, prior 
>>>>>>>>>>> to encapsulation.
>>>>>>>>>>>
>>>>>>>>>>>     Ron
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      being constructed. That is, the same encapsulation may 
>>>>>>>>>>> be used
>>>>>>> on
>>>>>>>>>>> encapsulation,  a
>>>>>>>>>>> applied is called a Service Function Chain (SFC). Since a 
>>>>>>>>>>> given service function may be available on
>>>>>>> more
>>>>>>>>>>> than
>>>>>>>>>>> functions may
>>>>>>>>>>> applied at a specific layer within the network protocol 
>>>>>>>>>>> stack
>>>>>>>>> (network
>>>>>>>>>>> as well as mechanisms for steering traffic through service 
>>>>>>>>>>> functions. The
>>>>>>>>> working
>>>>>>>>>>>      being constructed. That is, the same encapsulation may 
>>>>>>>>>>> be used
>>>>>>> on
>>>>>>>>>>> all the
>> 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:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 17 Nov 2013 16:20:56 +0000

Mehmet,

I think it is important for SFC to deliver chartered items with focus. All these are good elements supporting a broader problem around SFC, and I'd cautious SFC to focus -- it does not mean SFC (or even the IETF) should work on the items you list.

From the charter, item 5, SFC need to better understand and scope what these things mean. And in this, one of the things to avoid is:
http://tools.ietf.org/html/rfc1925
   (5)  It is always possible to aglutenate multiple separate problems
        into a single complex interdependent solution. In most cases
        this is a bad idea.
Thanks,

-- Carlos.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Sun, 17 Nov 2013 18:50:58 +0000

The current charter text calls for more study into the requirements in
this area and we have a specific milestone to consult with OPS. While the
approach we have taken may result in some rechartering in the future we
felt that was the right thing to do at this stage while we figure out what
should be in and out of scope for the SFC WG.

On 11/17/13 11:20 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

>Mehmet,
>
>I think it is important for SFC to deliver chartered items with focus.
>All these are good elements supporting a broader problem around SFC, and
>I'd cautious SFC to focus -- it does not mean SFC (or even the IETF)
>should work on the items you list.
>
>From the charter, item 5, SFC need to better understand and scope what
>these things mean. And in this, one of the things to avoid is:
>> AFAIU it is not easy to address all of these management aspects in the
>>future SFC WG and a parallel work in OPS area might be useful if started
>>early.
>> 
>>>ext Diego R.
>>>I had in mind
>>>>show an
>>>>>handle
>>>>>notifies
>>>>>>your
>>>>>>>>>>>>of a
>>>>>>>>>>>>develop new
>>>consultar nuestra

---

From: Melinda Shore <[email-masked]>
Date: Sun, 17 Nov 2013 09:57:16 -0900

On 11/17/13 9:50 AM, Jim Guichard (jguichar) wrote:
> The current charter text calls for more study into the requirements
> in this area and we have a specific milestone to consult with OPS.
> While the approach we have taken may result in some rechartering in
> the future we felt that was the right thing to do at this stage while
> we figure out what should be in and out of scope for the SFC WG.

One of the reasons that the question appears pressing is that
we're already seeing some drafts.  However, some of those drafts
specifically reference NFV rather than nsc so wouldn't end up
in an nsc working group, anyway (I think).

Melinda