Subject: Re: [sfc] New Version Notification for draft-dolson-sfc-vlan-00.txt

From: "Songhaibin (A)" <[email-masked]>
Date: Tue, 25 Mar 2014 06:51:34 +0000

(Just want to catch up with the interesting drafts in this working group.)

I agree that the practice introduced in this draft is very simple and efficient. I think most of the nowadays service functions are transparent and they can understand the 802.1Q. And they will not change any layer 2 traffic. So mapping traffic to VLAN pairs and using VLAN to divert traffic apply to this normal use case.

A little concern is that, while service functions are moving from dedicated devices to commodity servers or virtual machines, challenges will emerge, as the host interface may not support VLAN, and the MAC address may also be changed. And other non-transparent service functions may not use the method either.

Best Regards!
-Haibin

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Jerome Moisand
> Sent: Saturday, February 15, 2014 4:18 AM
> To: [email-masked]
> Subject: Re: [sfc] New Version Notification for draft-dolson-sfc-vlan-00.txt
> 
> Dave,
> 
> Thanks for sharing.
> 
> So in essence, this is using preconfigured VLANs to assemble a service overlay.
> And a service classifier of sorts is used to steer traffic to the proper VLAN.
> 
> Generalizing a bit, one can that with various forms of preconfigured tunnels (IP,
> MPLS, VLAN, etc) as long as the SFs can use them as input and output 'logical'
> interfaces.
> 
> Yup, agreed, this has been deployed in various shapes or forms in the past
> decade. Nothing wrong with it as long as the use case stays simple. And we
> should not underestimate the fact that such simple use cases are rather
> commonplace, while more complex use cases are less common.
> 
> I wonder if we should not extend the scope of this draft to 'existing practices'?
> 
> Tx
> Jerome
> 
> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
> Sent: Friday, February 14, 2014 2:39 PM
> To: [email-masked]
> Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-vlan-00.txt
> 
> As requested by some of you, this draft details Sandvine's experience with
> service chaining using VLANs.
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 14, 2014 2:31 PM
> To: Dave Dolson; Dave Dolson
> Subject: New Version Notification for draft-dolson-sfc-vlan-00.txt
> 
> 
> A new version of I-D, draft-dolson-sfc-vlan-00.txt
> has been successfully submitted by David Dolson and posted to the
> IETF repository.
> 
> Name:		draft-dolson-sfc-vlan
> Revision:	00
> Title:		VLAN Service Function Chaining
> Document date:	2014-02-14
> Group:		Individual Submission
> Pages:		9
> URL:
> http://www.ietf.org/internet-drafts/draft-dolson-sfc-vlan-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dolson-sfc-vlan/
> Htmlized:       http://tools.ietf.org/html/draft-dolson-sfc-vlan-00
> 
> 
> Abstract:
>    This document describes an implementation of Service Function Chains
>    (SFC) utilizing standard VLAN switching, appropriate for bump-in-the-
>    wire Service Function nodes.
> 
> 
> 
> 
> 
> 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
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
> 
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc