Subject: [sfc] Proposed redefinition of SFP

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Jul 2014 11:22:53 -0400

In an earlier email I said:

The way the draft uses the terms, and the way most discussions outside 
the IETF SFC working group use the term, a service function chain is 
something that you would discuss a policy about.  Certain traffic from 
certain users is supposed to receive a certain sequence of services, the 
service chain.

At the policy level, that does not care where in the network that is 
delivered.  So as to allow control a level of influence, and to have 
flexibility to have multiple representations in the network of that 
policy construct, we have the intermediate notion of service function 
path.  If the control system does not need to apply any influence, then 
it uses one service path for the service chain.  If it needs a level of 
control, it instantiates a suitable number of service paths in the 
control system, and rules for how those are used.

Then, the mapping in the SFF is based on that path, so as to enable the 
influence of the control system.  While still allowing several other 
layers of traffic management as discussed.

Yours,
Joel

To rephrase this a bit (and then if folks agree on the concept, we can 
pick the wording):

The SFP provides a level of indirection between the fully abstract 
notion of service path as a sequence of functions to be delivered, and 
the fully specified notion of exactly what instances of SFFs the packet 
will visit when it actually traverses the network.

By allowing the control components to specify the use of this level of 
indirection, the deployment may choose the degree of SFF instance 
selection authority that is delegated to the network.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 17:23:55 +0000

Hi, Joel.

I agree that policy may be used to affect the SFI selection.   But I don't view "path" as the appropriate way to express that.   It has a connotation, to me, that it is end-to-end.   Perhaps the policy is concerned with affecting the selection of only one SF instance on the chain and is 'don't care' regarding selection of the other SF instances on the chain.   Expressing this type of partial policy requirement doesn't map very well to the path concept, IMO.   In this regard, I actually think it better to leave to implementation.   Specifically, that instance selection is made SFC-hop by SFC-hop, but MAY be influenced by policy.   Furthermore, that a policy identifier MAY be conveyed amongst the SFC nodes (i.e., classifier and SFF's) to facilitate policy-driven instance selection.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, July 14, 2014 11:23 AM
To: [email-masked]
Subject: [sfc] Proposed redefinition of SFP

The way the draft uses the terms, and the way most discussions outside the IETF SFC working group use the term, a service function chain is something that you would discuss a policy about.  Certain traffic from certain users is supposed to receive a certain sequence of services, the service chain.

At the policy level, that does not care where in the network that is delivered.  So as to allow control a level of influence, and to have flexibility to have multiple representations in the network of that policy construct, we have the intermediate notion of service function path.  If the control system does not need to apply any influence, then it uses one service path for the service chain.  If it needs a level of control, it instantiates a suitable number of service paths in the control system, and rules for how those are used.

Then, the mapping in the SFF is based on that path, so as to enable the influence of the control system.  While still allowing several other layers of traffic management as discussed.

Yours,
Joel

To rephrase this a bit (and then if folks agree on the concept, we can pick the wording):

The SFP provides a level of indirection between the fully abstract notion of service path as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network.

By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF instance selection authority that is delegated to the network.

Yours,
Joel

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

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 Jul 2014 02:04:30 +0000

Hi Joel,

> The SFP provides a level of indirection between the fully abstract notion of
> service path as a sequence of functions to be delivered, and the fully specified
> notion of exactly what instances of SFFs the packet will visit when it actually
> traverses the network.

Instances of SFFs or instances of SF?

> By allowing the control components to specify the use of this level of indirection,
> the deployment may choose the degree of SFF instance selection authority that
> is delegated to the network.

SFF instance or SF instance?

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 Jul 2014 03:07:33 +0000

Specially speaking, for a given SFF along the SPF, should it just be capable of flexibly choosing one of the local SF instances of the current SF, or should it further be capable of flexibly choose one of the SFFs to which at least one instance of the next SF is attached?

Best regards,
Xiaohu

> From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Tuesday, July 15, 2014 10:05 AM
> To: Joel M. Halpern; [email-masked]
> Subject: Re: [sfc] Proposed redefinition of SFP
> 
> Hi Joel,
> 
> > pick the
> > wording):
> > the fully specified notion of exactly what instances of SFFs the
> > packet will visit when it actually traverses the network.
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jul 2014 03:52:16 +0000

Joel's proposal is very close to what I thought,
But why not use or add definition proposed by Maria as well
http://www.ietf.org/mail-archive/web/sfc/current/msg02444.html

Service function path can be either pre-determined or determined dynamically, i.e., choosing the locators of service explicit SF instances.
This will both allow flexibility in the selection of next-SFF within the path(i.e., next hop paradigm) and allow central system to decide the path.

Regards!
-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Joel M. Halpern
发送时间: 2014年7月14日 23:23
收件人: [email-masked]
主题: [sfc] Proposed redefinition of SFP

Yours,
Joel

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 15 Jul 2014 09:45:20 -0400

Since folks have requested that SFF have discretion on selecting 
next-SFF, it is important that the SFP scoping be able to restrict the 
set of SFFs which will be used for the traffic.
At the same time, it is also true that the scoping can provide 
restriction on which instances (among those available to the SFF that 
could be used for the service chain) will be used.

Net: It is important that the scoping allow for selecting SFFs.  it is 
reasonable to also allow restriction on service function instantiations.

I want to be careful because if there is a load balancer hanging off of 
the SFF, then I do not see how this scoping can affect the load balancer 
instance selection.  When the SFF has an integral load balancer, then 
such restriction can take effect.

Yours,
Joel

---

From: "He, Peng" <[email-masked]>
Date: Tue, 15 Jul 2014 10:06:20 -0400

I have the same question, will that still be SFF or re-classification?

Regards,
Peng

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Monday, July 14, 2014 11:08 PM
To: Xuxiaohu; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Proposed redefinition of SFP

Best regards,
Xiaohu

> > To rephrase this a bit (and then if folks agree on the concept, we 
> > can pick the
> > wording):
> >
> > notion of service path as a sequence of functions to be delivered, 
> > and the fully specified notion of exactly what instances of SFFs the 
> > By allowing the control components to specify the use of this level 
> > of indirection, the deployment may choose the degree of SFF instance

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 15 Jul 2014 10:28:58 -0400

Folks asked for this (SFF seelction in data plane) capability.
 From earlier discussion, I think that there is an intention to allow 
this in a semi-static fashion that does not require examination, or in 
conjunction with a suitable packet hash mechanism to enable stability of 
choice.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 15 Jul 2014 15:28:14 +0000

Giving SFFs forwarding discretion troubles me, considering multiple vendors and bidirectional traffic, and this is why:

When an SFF has some freedom to choose the next-SFF, this amounts to an implicit (possibly opaque) forwarding rule.
Consider implicit rules in the context of bidirectional traffic, when a stateful SF needs to see both directions of any given flow.

For the bidirectional case, a stateful SF would need to be book-ended with SFFs having compatible implicit forwarding rules.

In this picture, SFF1 and SFF2 would need to have compatible implicit forwarding rules so that stateful SFFA and SFFB receive the same flows. 
("Compatible" may mean anti-symmetric, such as balancing by source IP in one case and destination IP in the other case. If the balancing is load-aware, SFF1 and SFF2 would have to communicate about load-balancing choices.)

     +----+         +----+         +----+
-----|SFF1|----+----|SFFA|----+----|SFF2|----
     +----+    |    +----+    |    +----+
               |              |
               |    +----+    |
               +----|SFFB|----+
                    +----+

I suspect the above might make sense for a single-vendor solution, but I would hope that the standard allows the 4 SFFs to be from different vendors.

If SFF1 and SFF2 are from different vendors, we shouldn't rely on implicit forwarding rules; they should be explicitly configured; one method is to create explicit paths; another method would be standardizing the classification rules used for load-balancing.

If the above figure *is* a single-vendor solution (perhaps a server farm with load-balancing), then the above figure can appear as a single SFF from the protocol point of view.

Vendor load-balancing solution, presenting the scalable system as a single SFF:

 +-----------------------------------------+
 |                                         |
 |   +----+         +----+         +----+  |
-----|LB1 |----+----|SF  |----+----| LB2|----
 |   +----+    |    +----+    |    +----+  |
 |             |              |            |
 |             |    +----+    |            |
 |             +----|SF  |----+            |
 |                  +----+                 |
 |SFF                                      |
 +-----------------------------------------+

In summary, I have trouble with allowing "discretion" in forwarding between SFFs. It should all be explicit.

One could argue that it is useful for the unidirectional chaining cases, I suppose. But explicit always works.

David Dolson
Senior Software Architect, Sandvine Inc.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Tuesday, July 15, 2014 9:45 AM
To: Xuxiaohu; [email-masked]
Subject: Re: [sfc] Proposed redefinition of SFP

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Tue, 15 Jul 2014 15:36:49 +0000

Hi, Dave.

I agree that symmetrical is the more typical case.   In order to do their jobs, many SFF implementations will be stateful at the flow level.   When learning a flow in the "forward" direction, it should be possible to discern and retain the previous hop instance (i.e., an SFF or an ingress border node/classifier) for purposes of managing the "reverse" flow in a symmetrical manner.   Whether this recognition of previous hop is solely at the transport layer or whether some protocol fields need to be introduced to NSH/SCH is for further consideration.   Also, the architecture spec can call out this mode of behavior explicitly in terms of SFF functional requirements.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Tuesday, July 15, 2014 11:28 AM
To: Joel Halpern Direct; Xuxiaohu; [email-masked]
Subject: Re: [sfc] Proposed redefinition of SFP

     +----+         +----+         +----+

David Dolson

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Tuesday, July 15, 2014 9:45 AM
To: Xuxiaohu; [email-masked]
Subject: Re: [sfc] Proposed redefinition of SFP

Since folks have requested that SFF have discretion on selecting next-SFF, it is important that the SFP scoping be able to restrict the set of SFFs which will be used for the traffic.
At the same time, it is also true that the scoping can provide restriction on which instances (among those available to the SFF that could be used for the service chain) will be used.

Net: It is important that the scoping allow for selecting SFFs.  it is reasonable to also allow restriction on service function instantiations.

I want to be careful because if there is a load balancer hanging off of the SFF, then I do not see how this scoping can affect the load balancer instance selection.  When the SFF has an integral load balancer, then such restriction can take effect.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 15 Jul 2014 15:56:37 +0000

Ron,
To clarify, are you suggesting SFFs remember flow state so as to be able to make the correct decision in the opposite direction?  (Like Ethernet MAC learning?)  

-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2014 11:37 AM
To: Dave Dolson; Joel Halpern Direct; Xuxiaohu; [email-masked]
Subject: RE: [sfc] Proposed redefinition of SFP

Hi, Dave.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Tuesday, July 15, 2014 11:28 AM
To: Joel Halpern Direct; Xuxiaohu; [email-masked]
Subject: Re: [sfc] Proposed redefinition of SFP

     +----+         +----+         +----+

David Dolson

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Tuesday, July 15, 2014 9:45 AM
To: Xuxiaohu; [email-masked]
Subject: Re: [sfc] Proposed redefinition of SFP

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Tue, 15 Jul 2014 15:58:04 +0000

Yes.   Also, learning of flow state will facilitate next SFF selection in the forward direction. 

   Ron

> On Jul 15, 2014, at 11:56 AM, "Dave Dolson" <[email-masked]> wrote:
> 
> Ron,

---

From: Ron Parker <[email-masked]>
Date: Tue, 15 Jul 2014 16:00:23 +0000

And, I might also add, local SFI selection. 

   Ron

> On Jul 15, 2014, at 11:58 AM, "Ron Parker" <[email-masked]> wrote:
>

---

From: Sharon <[email-masked]>
Date: Tue, 15 Jul 2014 10:00:24 -0700

Sound right. Most SFFs will latch to various flow fields as consistent balancing invariants per protocol and as a fast-path forwarding. SFFs can leverage also the chaining headers to help manage the context, workflow and reentrancy, and as additional local classification.

--szb

> On Jul 15, 2014, at 8:36 AM, Ron Parker <[email-masked]> wrote:
> 
> Hi, Dave.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Jul 2014 13:02:51 -0400

I was trying not to require that SFF be stateful load balancers.
They certainly can be.  But I had hoped tha tthe architecture would not 
mandate that.
Yours,
Joel

---

From: Sharon <[email-masked]>
Date: Tue, 15 Jul 2014 10:44:15 -0700

Right Joel, understood that and it may be a good goal in terms of standard structure. However in most use-case analysis of virtualized environment folks will fast forward to a state-full session managing SFF discussion to clarify and educate themselves on how the standard copes with fluid-elastic resource situation. So might as well incorporate Ron's language as optional guidance. 

--szb

> On Jul 15, 2014, at 10:02 AM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> They certainly can be.  But I had hoped tha tthe architecture would not mandate that.
> Yours,
> Joel
>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 16 Jul 2014 01:21:41 +0000

Agreed.  

In fact, I would argue that one of the functions of the SFP would be to
minimize required state - particularly a widespread need to be a "speaker"
(in the forwarder) in some quasi-routing or NH resolution protocol - as
much as possible.  Granted, some of the transport-based forwarding (not
ruled out) may require and even deploy such a speaker.

This goes back to our original (I mean MONTHS ago) discussion on the
benefits of NOT classifying on every node if you can avoid it.

Sure, you can DO these things Š they are not explicitly ruled out either.

ON a separate note, regarding the discussion of stateful load balancing
and/or load balancing into stateful functions (I'm so happy that we've
moved away from flattening elasticity into a million chains, that I can
barely contain myself).

For the most part, I simplify the load balancing function (in my small rat
brain) and it's forwarder as conjoined and with a single network axis Š
the instances get and return traffic via the LB entity (even if it's on
different logical ports) Š thus, it knows what instance it sent flow X to,
and when the return path is traversed it does more of the same.  That is,
the path takes me to the SFF of the LB and between it and it's conjoined
function, it picks an instance and in the return path is pretty much going
to do the same in the same fashion (HA with a stateful pair is just a
further abstraction.  Granted, that's a simple picture.

In Dave's admittedly more complex scenario, where the instances have a
separate SFF which in turn does not have a simple path that returns via
the LB (and it's conjoined SFF), at the very least SFF1 could indicate the
flow rule (hash) and instance (local IP or MAC) selected to SFF2 (I think
that's as close to standardizing loadbalancers as you're going to get).

In the same way, I think you can use metadata at classification to help
globally synchronize load balancing (and other path related goo that might
rely on local decision making).

On 7/15/14 1:02 PM, "Joel M. Halpern" <[email-masked]> wrote:

>> Sound right. Most SFFs will latch to various flow fields as consistent
>>balancing invariants per protocol and as a fast-path forwarding. SFFs
>>can leverage also the chaining headers to help manage the context,
>>workflow and reentrancy, and as additional local classification.
>>
>> --szb
>>
>>> I agree that symmetrical is the more typical case.   In order to do
>>>their jobs, many SFF implementations will be stateful at the flow
>>>level.   When learning a flow in the "forward" direction, it should be
>>>possible to discern and retain the previous hop instance (i.e., an SFF
>>>or an ingress border node/classifier) for purposes of managing the
>>>"reverse" flow in a symmetrical manner.   Whether this recognition of
>>>previous hop is solely at the transport layer or whether some protocol
>>>fields need to be introduced to NSH/SCH is for further consideration.
>>>Also, the architecture spec can call out this mode of behavior
>>>explicitly in terms of SFF functional requirements.
>>>
>>>    Ron
>>>
>>>
>>> Giving SFFs forwarding discretion troubles me, considering multiple
>>>vendors and bidirectional traffic, and this is why:
>>>
>>> When an SFF has some freedom to choose the next-SFF, this amounts to
>>>an implicit (possibly opaque) forwarding rule.
>>> Consider implicit rules in the context of bidirectional traffic, when
>>>a stateful SF needs to see both directions of any given flow.
>>>
>>> For the bidirectional case, a stateful SF would need to be book-ended
>>>with SFFs having compatible implicit forwarding rules.
>>>
>>> In this picture, SFF1 and SFF2 would need to have compatible implicit
>>>forwarding rules so that stateful SFFA and SFFB receive the same flows.
>>> ("Compatible" may mean anti-symmetric, such as balancing by source IP
>>>in one case and destination IP in the other case. If the balancing is
>>>load-aware, SFF1 and SFF2 would have to communicate about
>>>load-balancing choices.)
>>>
>>>      +----+         +----+         +----+
>>> I suspect the above might make sense for a single-vendor solution, but
>>>I would hope that the standard allows the 4 SFFs to be from different
>>>vendors.
>>>
>>> If SFF1 and SFF2 are from different vendors, we shouldn't rely on
>>>implicit forwarding rules; they should be explicitly configured; one
>>>method is to create explicit paths; another method would be
>>>standardizing the classification rules used for load-balancing.
>>>
>>> If the above figure *is* a single-vendor solution (perhaps a server
>>>farm with load-balancing), then the above figure can appear as a single
>>>SFF from the protocol point of view.
>>>
>>> One could argue that it is useful for the unidirectional chaining
>>>cases, I suppose. But explicit always works.
>>>
>>>
>>> David Dolson
>>> I want to be careful because if there is a load balancer hanging off
>>>of the SFF, then I do not see how this scoping can affect the load
>>>balancer instance selection.  When the SFF has an integral load
>>>balancer, then such restriction can take effect.
>>>
>>> Yours,
>>> Joel
>>>

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 16 Jul 2014 07:59:54 +0000

I do have concerns on this learning behavior, especially when it may influence SFC forwarding paths. SFC by nature is a customized, service-oriented forwarding, which is different from normal L2 forwarding or L3 routing. SFFs learn some states and decide reverse path accordingly may result in unexpected forwarding path. It would be much more persuasive to prove such action is totally safe and under control with a complete solution.

Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, July 16, 2014 12:00 AM
To: Dave Dolson
Cc: Joel Halpern Direct; Xuxiaohu; [email-masked]
Subject: Re: [sfc] Proposed redefinition of SFP

   Ron

>> To clarify, are you suggesting SFFs remember flow state so as to be 
>> able to make the correct decision in the opposite direction?  (Like 
>> Ethernet MAC learning?)
>> 
>> -Dave
>> 
>> 
>>>> and the fully specified notion of exactly what instances of SFFs 
>>>> the packet will visit when it actually traverses the network.
>>> 
>>>> of indirection, the deployment may choose the degree of SFF 
>>>> instance selection authority that is delegated to the network.
>>>