Subject: Re: [sfc] SFC using VLANs

From: Jerome Moisand <[email-masked]>
Date: Tue, 4 Feb 2014 15:33:52 +0000

Indeed, quite a few use cases can be addressed by a simple combination of policy-routing and tunnels (L2 or MPLS or L3) constructs – which isn’t exactly new!

More complex use cases could be addressed by programming or controlling some form of forwarding rules in an hypervisor or a switch or whatever device on the data path.

Maybe the broader point would be to formally identify & document what can be done with regular routing mechanisms, and to which extent this can address the problem statement, while separating what is truly not addressed.

From: sfc [mailto:[email-masked]] On Behalf Of Songhaibin (A)
Sent: Tuesday, January 28, 2014 10:45 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] SFC using VLANs

Would like to hear more about David’s implementation too.

Best Regards!
-Haibin

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, January 29, 2014 6:28 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC using VLANs

There are a number of ways to do this without SFC.  You could create your chain using DSCP markings and use OF in the underlay to forward traffic with markings set (defaulting to standard IP networking if not set).  Many router vendors support a form of Policy Based Routing (aka filter based forwarding) that can be used code in the chains per flow.  You could even run an overlay like VXLAN or Contrail or Nuage that support a chaining-like feature.  And, yes, you could build a GRE encapsulation overlay as well.

My hope is for SFC to provide a standard, simplified method of doing this.

I'm definitely interested to hear more about David's specific implementation, problems worked around, and features still not possible to implement with the current configuration.

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Dave Dolson<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 28, 2014
Subject: Re: [sfc] SFC using VLANs
Yes it would be interesting. There are other solution which also build a dynamic chain based of service characteristic. VLAN tag is the most obvious choice but is it not possible to use other encapsulation technology like GRE perhaps?

From: Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 28, 2014 at 10:35 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] SFC using VLANs

Greetings,
At Sandvine we have been deploying a form of Service Function Chaining (albeit under different nomenclature) for about 5 years now.
Our Policy Traffic Switch (PTS) platform can initiate and terminate chains, steering traffic to different chains based on a variety of traffic and subscriber conditions.
The encapsulation is VLAN tagging, and the requirement on the SF node is to transparently bridge an Ethernet trunk, forwarding or injecting traffic using the same Ethernet addresses and VLAN tag.
We have addressed issues of chain symmetry, health checking, failure, load balancing and sending different chains through the same node.
A benefit of this approach is that explicit chain configuration is not required in the SF node itself.
An obvious con is the limited number of VLAN tags (no more than 4095), and the complexity of the switch configuration may lower that further.
If this group is interested, I could elaborate, including the details and pros/cons, either on this mailing list or in a draft. Any interest?
David Dolson
Senior Software Architect, Sandvine Inc.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 6 Feb 2014 15:42:19 +0000

Hi, Jerome,

Please see inline.

> Indeed, quite a few use cases can be addressed by a simple combination of policy-routing and tunnels (L2 or MPLS or L3) constructs – which isn’t exactly new!

Indeed, but not without issues. And the issues associated with such approaches have been extensively discussed over the past few months on the mailing list as well as documented within the problem statement WG document (Please see, for example, items 1., 6., 8., and 9. from S2 of draft-ietf-sfc-problem-statement-00). While there is little disagreement that some form of service chaining can be applied using these current-state-of-the-art techniques, it is also true that a number of issues arise (even called out in the charter). We probably do not need to re-hash old discussions on this same list. 

> More complex use cases could be addressed by programming or controlling some form of forwarding rules in an hypervisor or a switch or whatever device on the data path.

Again the problem statement (items 9. and 12. more specifically) spells out the issues with current service insertion models and these issues are the focus of this WG's work. As a WG we need to produce an architecture with associated standards that is able to address all of the issues. 

> Maybe the broader point would be to formally identify & document what can be done with regular routing mechanisms, and to which extent this can address the problem statement, while separating what…

Asked a different way -- what gaps do you see in the problem statement document? We need to have a complete problem statement, which includes all things that are not resolved with legacy schemes.

Thanks,

-- Carlos.

> From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> From: [email-masked]<[email-masked]>
> To: Dave Dolson<[email-masked]>,[email-masked]<[email-masked]>
> From: Dave Dolson <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc