Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.txt

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Feb 2014 20:51:56 +0000

Paul, et al, 

What is the difference between "network locators for SFs" and the "Service Function Forwarder (SFF)"? 

The first bullet of 3.2 stated that SF is not longer viewed as a bump in the wire. Then how do you describe the topology between SFs and their network locators or Service Function Forwarders?  Isn't it either "bump in a wire" or "one armed"?

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Wednesday, January 29, 2014 8:58 AM
To: [email-masked]
Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi folks,

The only change to this version is that we moved to two editors, and listed the other co-authors in a contributors section.

As always, your comments and feedback is appreciated!
Paul

> 
> A new version of I-D, draft-quinn-sfc-arch-04.txt has been 
> successfully submitted by Paul Quinn and posted to the IETF 
> repository.
> 
> Name:		draft-quinn-sfc-arch
> Revision:	04
> Title:		Service Function Chaining (SFC) Architecture
> Document date:	2014-01-28
> Group:		Individual Submission
> Pages:		21
> URL:            http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/
> Htmlized:       http://tools.ietf.org/html/draft-quinn-sfc-arch-04
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-quinn-sfc-arch-04
> 
> Abstract:
>   This document describes an architecture used for the creation of
>   Service Function Chains (SFC).  It includes architectural concepts,
>   principles, and components used in the construction of composite
>   services through deployment of SFCs in a network.  This document does
>   not propose solutions, protocols, or extensions to existing
>   protocols.
> 
> 
> 
> 
> 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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Feb 2014 21:46:36 +0000

Paul, et al, 

The  "SFC Network Forwarder (SNF)" introduced is to "forward traffic based on the information contained in the SFC encapsulation". 

If SFC encapsulation is to carry Metadata/context data (Bullet 4 of Section 1) to be shared, is it possible that the network forwarding nodes could forward traffic based on policies that are not in the SFC encapsulation?

Linda  

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Wednesday, January 29, 2014 8:58 AM
To: [email-masked]
Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi folks,

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 6 Feb 2014 14:58:51 +0000

Linda,

> What is the difference between "network locators for SFs" and the "Service Function Forwarder (SFF)"? 

The SFF is a logical entity that performs actually forwarding of packets to service functions.  The term network locator is used in the traditional sense, that is a data plane address (i.e. where it is connected to the network).

> The first bullet of 3.2 stated that SF is not longer viewed as a bump in the wire. Then how do you describe the topology between SFs and their network locators or Service Function Forwarders?  Isn'…

It's not a matter of topology, rather, instead of the SF being "inserted" as a bump, it is "consumed", regardless of placement in the network.  The term Overlay Service Topology is used in the doc to describes the service chaining topology.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 6 Feb 2014 15:02:19 +0000

Hi Linda,

> If SFC encapsulation is to carry Metadata/context data (Bullet 4 of Section 1) to be shared, is it possible that the network forwarding nodes could forward traffic based on policies that are not in…

I'm not sure exactly what you mean, can you give me a bit more context (no pun intended!), or even better, an example?

Thanks
Paul

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 6 Feb 2014 15:29:21 +0000

For example, a possible policy could be "ingress port #", or even an event. Just to emphasize that SNF might not use bits/fields in SFC header to forward traffic to the next Service Function Node. 

Another question, your ServiceFunctionForwarder (SFF) forwards traffic to service functions, so SFF has to be SF header aware. Is it necessary for SNF to be SF header aware?

Linda 

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Thursday, February 06, 2014 9:02 AM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: New Version Notification for draft-quinn-sfc-arch-04.txt

Hi Linda,

Thanks
Paul

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 6 Feb 2014 15:36:32 +0000

Paul, 

See my suggestion below:

-----Original Message-----

[Linda] Even with Service Functions being "consumed", it is still very important to SFF or/and SNF on "Where to steer traffic to consume the "service function"", correct? 

When the "to be consumed" service functions are placed as "One Armed", the SFF is in full control of where the next hop is. If the "to be consumed service functions" are placed as "bump in the wire", the SF has to be informed of the next hop after the treatment. 

Linda

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 10 Feb 2014 14:24:44 +0000

Linda,

> [Linda] Even with Service Functions being "consumed", it is still very important to SFF or/and SNF on "Where to steer traffic to consume the "service function"", correct? 

Traffic is steered to the "right" function, as opposed to having that function simply be inline because of topology.  More interestingly, a subset of traffic might go to one SF, whereas other traffic might be steered to another.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 10 Feb 2014 17:13:21 +0000

Paul, 

Thanks for the reply, See the comments inserted below:

-----Original Message-----

[Linda] Absolutely agree with your statement here. Can you use this statement in the draft instead of saying the functions being consumed?

It is still very important to SFF or/and SNF on "Where to steer traffic". 
To the particular subset of traffic, the path from SFF/SNF to SF can be "one armed" or "bump in the wire". 

Linda