Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt

From: Linda Dunbar <[email-masked]>
Date: Sat, 8 Feb 2014 15:48:11 +0000

This draft analyzes the issues associated with chaining existing Layer 4-7 service functions that are not aware of service encapsulation layers. This draft also examines the network architecture for chaining existing L4-L7 service functions. The goal of the draft is:

- To make SFC WG adopt the fact that there are many service functions deployed that don’t terminate the newly proposed SFC Header; Many of them don’t have L2/L3 switching/routing capability

- To make SFC WG adopt that Service Function Forwarder (that is defined by draft-quinn-nsc-arch-04) can be a separate entity from service functions. 

- To make SFC WG adopt that it is not necessary for every packet to carry the complete service chain forwarding information in its SFC header.  It should be acceptable to have variable length SFC Header. For example, for packets to be encoded with a Chain ID plus optional attributes and have separate messages (either in-band or out-of-band) to inform the detailed forwarding policies for the Chain ID and the Chain attributes in the packets  to the Service Function Forwarding nodes. 

- Recognize that from user’s perspective, the order of service functions, e.g. Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which instance of the Service Function “s1” is selected for the Chain #1 is not.  
	Among multiple instances of one service function, some could be in close proximity while others are far apart being connected by different network nodes.
	It should be acceptable for Service Chain classifier only identify the chaining at function level and have another entity managing the detailed service instance path.

Your comments and suggestions are greatly appreciated. 

Thanks, Linda

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, February 08, 2014 9:28 AM
To: Linda Dunbar; Ron Parker; Ning So; Ron Parker; So Ning; Donald Eastlake; Linda Dunbar; Donald E. Eastlake 3rd
Subject: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt

A new version of I-D, draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt
has been successfully submitted by Linda Dunbar and posted to the IETF repository.

Name:		draft-dunbar-sfc-legacy-l4-l7-chain-architecture
Revision:	02
Title:		Architecture for Chaining Legacy Layer 4-7 Service Functions
Document date:	2014-02-07
Group:		Individual Submission
Pages:		15
URL:            http://www.ietf.org/internet-drafts/draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/
Htmlized:       http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02

Abstract:
   This draft analyzes the issues associated with chaining existing
   Layer 4-7 service functions that are not aware of service
   encapsulation layers. This draft also examines the network
   architecture for chaining existing L4-L7 service functions. The
   intent is to identify optimal architecture for flexibly chaining
   existing Layer 4-7 functions to meet various service needs.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Dave Dolson <[email-masked]>
Date: Mon, 10 Feb 2014 17:10:24 +0000

Linda et al.,

I may not have understood everything you were saying, but I think the following perspective is useful and concise:

Legacy nodes must be wrapped with SFF nodes to make them look like proper SF nodes.

There are two choices for wrapping legacy SF nodes:

a. Each legacy node is wrapped such that it is exposed as a distinct SF instance, with one SF Map index per node. Then the Classifier chooses which nodes are to be used. This would be used when the legacy node has no mechanisms for separating traffic for different chains.

b. A cluster of legacy nodes can be wrapped such that the cluster is exposed as a single SF instance. Then the Classifier chooses the cluster but is agnostic about the path of traffic within the cluster. (This is where the challenges appear, but also provide great flexibility; use VLANs or MPLS or proprietary tagging to separate the chains.) More generally, a cluster could expose multiple SF instances for different policies.

It may not be necessary to say anything more. Provided the legacy nodes are wrapped to look like proper SFC nodes (namely, properly forwarding packets), why should the SFC standard say anything about what happens beneath the wrapping?

On a somewhat related note, I think it is also reasonable that SFC could be deployed hierarchically. I.e., a load-balancer could appear as a single SF node within a service chain, and utilize SFC to distribute traffic within its cluster, in a different SFC domain. When the inner chain ends, the packet returns to the original SF Chain. 

Hierarchies are architecturally powerful, allowing simplification by abstraction. This view allows a vendor to provide a solution appearing as a single SFC node, but internally utilizing multiple components with SFC technology.

David Dolson
Senior Software Architect, Sandvine Inc.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Saturday, February 08, 2014 10:48 AM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt

Thanks, Linda

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, February 08, 2014 9:28 AM
To: Linda Dunbar; Ron Parker; Ning So; Ron Parker; So Ning; Donald Eastlake; Linda Dunbar; Donald E. Eastlake 3rd
Subject: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt

Abstract:

The IETF Secretariat

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 10 Feb 2014 23:36:51 +0000

Dave, 

Thanks for the comments. Answers are inserted below:

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, February 10, 2014 11:10 AM
To: Linda Dunbar; [email-masked]
Subject: RE: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt

Linda et al.,

Legacy nodes must be wrapped with SFF nodes to make them look like proper SF nodes.
[Linda] Yes, even though "attached to SFF" is more accurate than "wrapped". 

b. A cluster of legacy nodes can be wrapped such that the cluster is exposed as a single SF instance. Then the Classifier chooses the cluster but is agnostic about the path of traffic within the cluster. 

[Linda] I don't think it will scale for Classifier to choose the whole cluster with multiple Service functions. You can have two chains going through one SFF to which 3 Service Functions are attached (SF#1, SF#2, SF#3).  Chain #1 only needs to go through SF #1, Chain #2 needs to go through SF#1 & SF#2. 

(This is where the challenges appear, but also provide great flexibility; use VLANs or MPLS or proprietary tagging to separate the chains.) More generally, a cluster could expose multiple SF instances for different policies.

[Linda] Agree here. That is described in Section 4 of the draft. 

[Linda] I don't think it is that simple. when SFF is on a separate box, the SFC-Architecture need to  address: 
- Various SF connection to SFF Nodes
- Traffic Steering at SFF Nodes 
	e.g. How steering policy is passed to a SFF node, and the need for SFF to re-classify traffic coming back from a port connected to a SF if the Chain ID is not passed by the SF nodes.

Those are described in the Section 4 of the draft. 

[Linda] Agree. That is described in the Section 5 of the draft. You can also have local load balancer and global load balancer (to address same function but multiple entities attached to different SFF nodes). 

David Dolson

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Saturday, February 08, 2014 10:48 AM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt

Thanks, Linda

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, February 08, 2014 9:28 AM
To: Linda Dunbar; Ron Parker; Ning So; Ron Parker; So Ning; Donald Eastlake; Linda Dunbar; Donald E. Eastlake 3rd
Subject: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt

Abstract:

The IETF Secretariat